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.
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.
@mAAdhaTTah Das https://nodejs.org/api/esm.html
@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 🎉
Hilfreichster Kommentar
@jeremejevs gute Idee... mit
du könntest es so gebrauchen
ohne für alle Knex-Befehle ein separates Skript erstellen zu müssen.