Knex: Knex cli sollte es6 für Konfiguration und Migrationen unterstützen

Erstellt am 26. Feb. 2016  ·  42Kommentare  ·  Quelle: knex/knex

Es wäre schön, wenn die Knex-Cli es6 für Konfiguration und Migrationen unterstützen würde. Vielleicht könnte dies hinter einem Flag sein oder nur, wenn sich eine .babelrc Datei im aktuellen Arbeitsverzeichnis befindet.

PR please feature request

Hilfreichster Kommentar

@jeremejevs gute Idee... mit

{
  "scripts": {
    "knex": "babel-node node_modules/.bin/knex"
  }
}

du könntest es so gebrauchen

npm run knex migrate:latest

ohne für alle Knex-Befehle ein separates Skript erstellen zu müssen.

Alle 42 Kommentare

Das wäre auf jeden Fall toll. Gerne nehme ich hierfür eine PR an.

Es tut uns leid. Dieser vorherige Kommentar sollte für Ausgabe 1220 gelten, aber ich habe ihn fälschlicherweise hier eingefügt.

@rhys-vdw weißt du aus der Hand, was es dauern würde?

@rhys-vdw @jmfurlott . Ich bin auch daran interessiert, dies zu verfolgen, da ich finde, dass dies ein wirklich cooles Feature wäre. Glauben Sie, Sie können uns auf die Komponenten hinweisen, die wir untersuchen sollten, um dies zu ermöglichen. Ein paar Einblicke würden helfen

Das Hinzufügen von require("babel-register") zum CLI-Einstiegspunkt könnte funktionieren.

Bestätigt - das zu meiner Seed-Datei hinzugefügt und ES2015 ausgeführt! Vielleicht sollte es eine Option in knexfile.js , um compiler festzulegen, wie es Mocha mit seiner CLI macht?

Ich habe meine endlich zum Laufen gebracht:

db.config.js

export default {
    devDB: {
        client: 'sqlite3',
        connection: {
            filename: './db.sqlite3',
        },
        pool: {
            min: 1,
            max: 1,
        },
    },
    migrations: {
        directory: './migrations',
        tableName: '_migrations',
    },
    seeds: {
        directory: './seeds/dev'
    },
    pool: {
        min: 1,
        max: 1,
    }
}

knexfile.js

require('babel-register')
const config = require('./db.config').default // <- this -.-

module.exports = config

.babelrc

{
    "env": {
        "devDB": {
            "plugins": ["transform-es2015-modules-commonjs"]
        }
    }
}

Allerdings kann ich den Seed-Pfad nicht ändern, wenn sie sich nicht in ./seeds befinden, bekomme ich immer

No seed files exist

Gleiches gilt auch für Migrationen..

Eine andere Möglichkeit besteht darin, Knex mit babel-node auszuführen, verfügbar in babel-cli , wie folgt:

{
  "scripts": {
    "db:migrate:latest": "babel-node node_modules/.bin/knex migrate:latest"
  }
}

Sie können dies tun, wenn Ihre App knexfile.js importiert, während sie bereits von Babel verarbeitet wird, wodurch die Option require('babel-register') unbrauchbar wird.

@jeremejevs gute Idee... mit

{
  "scripts": {
    "knex": "babel-node node_modules/.bin/knex"
  }
}

du könntest es so gebrauchen

npm run knex migrate:latest

ohne für alle Knex-Befehle ein separates Skript erstellen zu müssen.

@olalonde Ja , das geht auch! Ich ziehe es einfach vor, explizite Skripte "db: migration:make " und "db: migration:latest " zu verwenden, falls ich den genauen Wortlaut ein halbes Jahr später vergessen habe (war es "make"? oder "make-migration"? oder "migrate: make"? oder "migrate:new"? oder...) 🙂

@olalonde ausgezeichneter Vorschlag! Dann können Sie die npm-Skripte "composition" verwenden wie:

{
    "knex": "babel-node node_modules/.bin/knex",
    "migrate": "npm run knex -- migrate:latest --env ",
}

Vielleicht könnte das auch helfen: https://github.com/standard-things/esm

Betriebssystem: Windows
[email protected]
[email protected]

// migrations/contacts.js
export function up (knex) {
  return knex.schema
    .createTable('contacts', table => {
      table.increments('id').primary()
      table.string('firstName')
      table.string('lastName')
      table.string('emailAddress')
    })
}

export function down(knex) {
  return knex.schema
    .dropTable('contacts')
}
$ npx knex migrate:latest
Using environment: development
migrations/contacts.js:1
(function (exports, require, module, __filename, __dirname) { export function up (knex) {
                                                              ^^^^^^
SyntaxError: Unexpected token export
    at Object.exports.runInThisContext (vm.js:73:16)
    at Module._compile (module.js:543:28)
    ...
$ npx babel-node node_modules/.bin/knex migrate:latest
./node_modules/.bin/knex:2
basedir=$(dirname "$(echo "$0" | sed -e 's,\\,/,g')")
          ^^^^^^^
SyntaxError: missing ) after argument list
    at Object.exports.runInThisContext (vm.js:73:16)
    at Module._compile (module.js:543:28)
    ...
$ npx babel-node node_modules/knex/bin/cli.js migrate:latest
Using environment: development
Batch 1 run: 1 migrations
migrations/contacts.js

Wenn ich den Vorschlag von @olalonde versuche, npm run knex migrate:make oder npm run knex mit zusätzlichen Argumenten, wird einfach beendet, ohne etwas anzuzeigen. Wenn Sie nur npm run knex ausführen, wird die Verwendung jedoch normal angezeigt. npm docs sagen, dass ich -- vor die Skriptargumente wie npm run knex -- migrate:make , aber das wird immer noch ohne Ausgabe beendet.

Verwenden von reify (schnell!) auf * nix (keine Ahnung von einem Alias-Synonym unter Windows, sorry!)

/*

  npm install --save-dev reify
  echo '.reify-cache/' >> .gitignore
  alias knex='node -r reify ./node_modules/.bin/knex

  knex migrate:latest # …etc

*/

const table = 'foo';

export const up = knex => {
  return knex.schema.createTable(table, t => {
    t.increments();
    // …etc
    t.timestamps();
  });
};

export const down = knex => knex.schema.dropTable(table);

// OR

// export function up (knex) {
//   return knex.schema.createTable(table, t => {
//     t.increments();
//     // …etc
//     t.timestamps();
//   });
// }

// export function down (knex) {
//   knex.schema.dropTable(table);
// }

Alle Versuche, knexfile.js zu entschlüsseln, sind hässlich, aber ich kann mit einer einzigen Anomalie mit module.exports leben

Erhalten Sie weiterhin No knexfile found in this directory. Specify a path with --knexfile mit dem Folgenden:

// src/knexfile.js
import config from 'config'

export default {
  debug: false,
  settings: config.get('dbConfig'),
  seeds: {
    directory: './seeds/'
  }
}
//package.json
 "scripts": {
    "knex": "babel-node node_modules/.bin/knex"
  }

```
garn knex migrieren: machen lol
````

Irgendwelche Hinweise? Scheint nur ein Arbeitsverzeichnis zu sein (glaube ich)

@haywirez Sind Sie sicher, dass dies mit dem Thema dieses Tickets zusammenhängt? .. Wie auch immer, versuchen Sie genau das zu tun, was es verlangt, fügen Sie --knexfile hinzu, das auf Ihre knexfile.js verweisen würde

Es ist möglich, dass @haywirez 'Problem ist, weil export default { ... } const file = require('/path/to/knexfile').default für ESM-Interop sein muss.

Außerdem ermöglicht Liftoff, wie es von der Knex-Cli verwendet wird, ein --require Flag, um etwas wie esm oder babel-register zu verlangen. Da dieser Befehl im Commander nicht registriert ist, stirbt die Knex-Cli leider, nachdem esm angefordert wurde:

± |master ?:18 ✗| → npx knex --require esm seed:make admin_user
Requiring external module esm

  error: unknown option `--require'

Wäre das Projekt für einen PR offen, um --require für alle Befehle zu aktivieren und Interop für knexfile sicherzustellen?

https://github.com/tgriesser/knex/issues/1232#issuecomment -411775132 würde es Ihnen auch ermöglichen, tsconfg-paths für Alias-Pfadnamen zu registrieren, was nützlich ist, wenn Sie Seeds mit Typoskript erstellen. ts-node plant nicht --require Flag freilegen, kann ich das selbst umgehen.

Wenn andere auf dieses Problem stoßen, können Sie es alternativ ohne das Flag --require umgehen, indem Sie Folgendes tun:

node -r tsconfig-paths/register node_modules/.bin/knex seed:run

@olalonde Ist das in einer Welt, in der alle gängigen Node.js-Versionen ES6 out-of-the-box unterstützen, noch relevant?

@kibertoad Node unterstützt noch keine ESModule.

@kibertoad Ja, aber es ist sehr experimentell und instabil, also kann man sich nicht darauf verlassen.

Wenn Sie esm verwenden , versuchen Sie unter Windows
node -r esm node_modules/knex/bin/cli.js migrate:make migration_name .

Versuchen Sie es unter Linux und Mac
node -r esm node_modules/.bin/knex migrate:make migration_name

Das letzte Update, das ich auf diesem Ticket sehe, betrifft esm und ist über ein halbes Jahr alt ... hat es seither jemand geschafft, das mit Babel zum Laufen zu bringen? Ich bin besonders neugierig auf all die Änderungen an Babel und die scheinbar neue Präferenz der Bibliothek, @babel/register anstelle von babel-node zu verwenden.

@machineghost Sie können den neuesten Master ausprobieren, er verwendet keine Transpilation, funktioniert also möglicherweise besser. Wenn Sie noch auf Einschränkungen stoßen, lassen Sie es mich bitte wissen.

Es scheint immer noch nicht zu funktionieren. Mein package.json ist wie folgt:

"knex": "npx @babel/node node_modules/.bin/knex --knexfile=src/database/knexfile.js",
"migrate": "npm run knex migrate:latest",

// ...
"dependencies": {
// ...
"knex": "git://github.com/tgriesser/knex.git#master",
// ...

und mein knexfile.js ist super einfach:

import { development } from './realKnexFile';
module.exports = {
    development
};

Aber es kommt nicht über die erste Zeile hinaus. Wenn ich npm run migrate ausführe, erhalte ich:

knexfile.js:1
import { development } from './realKnexFile';
       ^

SyntaxError: Unexpected token {
    at Module._compile (internal/modules/cjs/loader.js:760:23)

Nachdem man das erstaunliche Modul "esm" (vom Schöpfer von Lodash) entdeckt hat, braucht man nicht einmal mehr Babel. Wirklich alles, was Knex braucht, um ES6-Module ganz einfach zu unterstützen, ist nur eine Möglichkeit, --require esm node hinter den Kulissen an

Wenn die knex Befehlszeile einfach -r und an Node übergeben könnte, würde dies nicht nur dieses Ticket lösen, sondern auch jedes andere Problem, bei dem jemand ein Node-Modul ausführen muss, bevor Knex ausgeführt wird.

-BEARBEITEN-

Bis ein -r Argument existiert, kann man die ES6-Syntax in allen _erforderlichen_ Modulen (aber nicht in knexfile.js selbst) verwenden, indem man Folgendes tut:

require = require("esm")(module);
const importedContent = require('./someFile.js');

Dadurch kann require selbst ES6-Module problemlos handhaben ... aber das knexfile.js immer noch require und module.exports ; eine Option -r würde das lösen.

Falls jemand sucht, hier ist ein vollständiges Beispiel für die Verwendung von esm für die Arbeit mit knex

knexfile.js

const config = {
}

// Knex will fail if you use "exports default"
module.exports = config

Paket.json

{
  "scripts": {
    "knex": "node -r esm node_modules/.bin/knex",
    "db:migrate": "yarn knex migrate:latest"
  }
}

Da ESM immer beliebter wird, wäre ich bereit, einen Beitrag zu leisten, damit Knex mit Node >12 arbeiten kann. Ich habe ein wenig Erfahrung mit ESM in Node, also geht das hoffentlich reibungslos. Leider kann ich Ihnen nicht sagen, wann ich damit beginnen könnte, da ich nicht während der Arbeitszeit daran arbeiten kann (nicht geschäftlich). Ich werde auch eine Minute brauchen, um mich an die Knex-Codebasis zu gewöhnen

Ich denke, es könnte so einfach sein, wie require('esm') als neue Zeile hinzuzufügen ... wenn die Autoren der Bibliothek mit der neuen Abhängigkeit einverstanden sind.

@jhechtf @machineghost Schau
https://github.com/knex/knex/pull/3616
https://github.com/knex/knex/pull/3639
https://github.com/knex/knex/pull/3638

Auch die Liftoff-Unterstützung wurde behoben. Bevor Sie weitere Änderungen vornehmen, wäre es hilfreich, einige Tests zu schreiben, um herauszufinden, was jetzt funktioniert und was nicht.
Das heißt, wenn jemand all dies untersucht und entscheidet, welche Arbeit (falls vorhanden) noch erforderlich ist und einige Tests beisteuert, wäre das sehr hilfreich.

Ja, ihr habt euch für die offizielle Node-Lösung entschieden, die noch nicht fertig ist.

IMHO ist die "esm" -Modullösung viel einfacher und würde kein spezielles Flag erfordern: Es würde das Bibliotheks-ES-Modul nur für alle in allen Node-Umgebungen freundlich machen (sehr wahrscheinlich mit einer einzigen Anforderungszeile, wie ich sagte) .

Es ist von dem Typen, der Lodash gemacht hat; JDD rockt.

@machineghost https://github.com/knex/knex/pull/3639 verwendet Babel, das ist also eine andere Möglichkeit. Ich glaube, ich habe jemanden gesehen, der den Ansatz des esm Moduls ausprobiert hat, aber aus irgendeinem Grund kann ich den PR jetzt nicht finden.

Nun, FWIW, diese Bibliothek ist meine derzeit schnellste Quelle für Stack Overflow-Punkte;)

Ich habe es entdeckt und hier anderen empfohlen: https://stackoverflow.com/questions/47277887/node-experimental-modules-requested-module-does-not-provide-an-export-named/54302557#54302557

und jetzt bekomme ich alle paar Tage ein neues Upvote, weil es wirklich eine großartige ( im Moment wohl

@machineghost Wie aufdringlich würden Sie erwarten, dass die Einführung auf der vorhandenen Codebasis basiert?

Ich denke, dies ist eines dieser "Es sollte überhaupt keine Auswirkungen haben, aber da es alles betrifft, was Sie zur Sicherheit testen müssen"-Angebote.

Ich habe mir die Interna nicht angesehen, aber angesichts des Profils dieses Projekts in der Community könnte er vielleicht, wenn jemand @jdalton fragt, die Risiken abwägen (mit einer viel fundierteren Meinung als meiner?) :crossed_fingers:

@machineghost Sie können einen Blick auf https://github.com/knex/knex/pull/3616 werfen, um zu sehen, welche Auswirkungen die ursprüngliche Implementierung hatte. Wahrscheinlich müsste das entfernt oder ersetzt werden, wenn esm eingeführt wird.

Ich habe keinen Bandbreiten-ATM, aber ich werde nachsehen, wenn ich Zeit habe. Vielleicht könnte @jhechtf früher dazu in der Lage sein?

Ja, ihr habt euch für die offizielle Node-Lösung entschieden, die noch nicht fertig ist.

@machineghost : Hmm ... ich glaube, das --esm Flag verwendet tatsächlich das esm Ihnen erwähnte

https://github.com/knex/knex/blob/0f523db957138cc0423723c699c9ce52db5feb14/bin/cli.js#L52 -L55

In einem verwandten Hinweis: Sie haben mich gerade daran erinnert, dass ich das Flag --require korrigieren wollte, nachdem die Liftoff Erweiterungen zusammengeführt wurden. das sollte ich jetzt machen...

Oh, meine Entschuldigung! Ich scannte zu schnell, sah " node ${KNEX} --esm " und sah einfach an der Variablen dort vorbei und dachte, Sie würden ein Argument direkt an Node übergeben, um es anzuweisen, die Version von Node zu verwenden.

Es hört sich so an, als ob dies bereits gelöst wurde, und das war nur aus dem Problemthread nicht ersichtlich; schöne arbeit :+1:

np! Es sieht so aus, als ob die Funktion von @D10221 in diesem PR hinzugefügt wurde:

https://github.com/knex/knex/pull/3616

Sie verdienen also die Anerkennung 🎉

War diese Seite hilfreich?
0 / 5 - 0 Bewertungen