Knex-Version: 0.16.3
Datenbank + Version: docker postgres:10.4
Betriebssystem: Windows 10 Pro & Docker node:8.14.0
knex migrate:make --knexfile knexfile.ts
Unexpected token import
Funktioniert normal auf 0.15.x
0.16 enthält jetzt TypeScript-Typen im Repository (siehe #2845 ). Sie müssen wahrscheinlich @types/knex
aus Ihrem Projekt entfernen, damit dies ordnungsgemäß funktioniert.
Ich habe @types/knex
deinstalliert, aber ich habe immer noch den Fehler.
/usr/src/app/src/db/knexfile.ts:1
(function (exports, require, module, __filename, __dirname) { import { database } from '../config'
^^^^^^
SyntaxError: Unexpected token import
at createScript (vm.js:80:10)
at Object.runInThisContext (vm.js:139:10)
at Module._compile (module.js:617:28)
at Object.Module._extensions..js (module.js:664:10)
at Module.load (module.js:566:32)
at tryModuleLoad (module.js:506:12)
at Function.Module._load (module.js:498:3)
at Module.require (module.js:597:17)
at require (internal/module.js:11:18)
at initKnex (/usr/src/app/node_modules/knex/bin/cli.js:62:25)
at Command.commander.command.description.option.action (/usr/src/app/node_modules/knex/bin/cli.js:172:24)
at Command.listener (/usr/src/app/node_modules/commander/index.js:315:8)
at emitTwo (events.js:126:13)
at Command.emit (events.js:214:7)
at Command.parseArgs (/usr/src/app/node_modules/commander/index.js:654:12)
at Command.parse (/usr/src/app/node_modules/commander/index.js:474:21)
knex migrate:make --knexfile knexfile.ts
Versucht das nicht, Typoskriptcode mit einem einfachen Knoten auszuführen? Ich habe auch keine Ahnung, wie das mit 0,15 hätte funktionieren können.
Wie sieht dein Knexfile aus? Gibt es Importanweisungen?
import * as knex from 'knex'
import * as path from 'path'
import { env } from './env'
const database = {
client: 'postgresql',
connection: env.databaseUrl,
migrations: {
directory: path.resolve('../db/migrations'),
tableName: 'knex_migrations',
},
seeds: {
directory: path.resolve('../db/seeds'),
},
} as knex.Config
export = database
funktioniert 100% bei 0.15
Ich habe keine Ahnung, warum das mit 0,15 funktionieren sollte. Wie der Fehler Unexpected token import
Ihnen sagt, wird import * as knex from 'knex'
von Node.js nicht verstanden (zumindest nicht in der Konfiguration, die Sie verwenden).
Sie müssen Ihre Knexdatei entweder in JavaScript kompilieren, eine Node.js-Version verwenden, die die Importsyntax versteht (siehe https://nodejs.org/api/esm.html ) oder die Datei zurücksetzen, um das alte require()
Syntax.
Ich nehme an, es gab einen Fehler in knex 0.15, so dass es diese knex-Datei nie gelesen hat. Sieht nicht nach Fehler in 0.16 aus, der nicht funktionieren sollte.
damit es diese knexfile nie liest
Es liest die Knexdatei zu 100%, ich verwende es in mehr als einem einzigen Projekt (aus dem Kopf fallen mir 4 in der Produktion ein) mit verschiedenen Migrationsordnern und Verbindungsdaten.
In Version 0.15
wurde die Datei kompiliert oder möglicherweise ts-node
automatisch verwendet, um die Datei auszuführen.
Ich habe es gerade getestet ... Sie haben Recht, beide Versionen versuchen, ts-node-Sachen zu registrieren. Klingt so, als ob diese Funktion nicht getestet wurde. Nicht sicher, ob überhaupt dokumentiert.
nein ... jetzt wirklich getestet mit den notwendigen Sachen, die auf Knoten 8 installiert sind
Mikaels-MacBook-Pro-2:test mikaelle$ npm install [email protected] ts-node-register
npm WARN [email protected] No description
npm WARN [email protected] No repository field.
+ [email protected]
+ [email protected]
updated 2 packages and audited 1037 packages in 2.135s
found 0 vulnerabilities
Mikaels-MacBook-Pro-2:test mikaelle$ echo "import * as knex from 'knex'; export = {client: 'pg'}" > knexfile.ts
Mikaels-MacBook-Pro-2:test mikaelle$ node_modules/.bin/knex migrate:make --knexfile knexfile.ts -x ts foo
Failed to load external module ts-node/register
Failed to load external module typescript-node/register
Failed to load external module typescript-register
Failed to load external module typescript-require
Failed to load external module @babel/register
/Users/mikaelle/Projects/Vincit/yessql/dodo-objection/test/knexfile.ts:1
(function (exports, require, module, __filename, __dirname) { import * as knex from 'knex'; export = {client: 'pg'}
^^^^^^
SyntaxError: Unexpected token import
kann nicht reproduziert werden, aber es ist durchaus möglich, dass ein Feature implementiert wird, da Knex bereits ts-node verwendet, um tatsächliche Typoskript-Migrationsdateien und Seeds zu kompilieren
Ich habe ein vollständiges Beispiel eingerichtet, falls Sie untersuchen möchten, warum es bei 0,15 und nicht bei 0,16 funktioniert
Branch: knex16
hat 0.16.3
installiert
https://github.com/brunolm/knex16bug/tree/knex16
Zweig: knex15
hat 0.15.2
installiert
https://github.com/brunolm/knex16bug/tree/knex15
Wechseln Sie zu dem Zweig, den Sie überprüfen möchten, und führen Sie ihn im Stammordner aus:
docker-compose up
Wenn es funktioniert, sollten Sie eine Migration namens test
in /api/src/db/migrations
nach der Installation einiger weiterer Pakete (ts-node ts-node-dev typescript) scheint es, dass sowohl 0.15 als auch 0.16 hier gut funktionieren ... aber in der Tat schlägt Ihr Docker-Setup mit Knoten 0.16 fehl und ich habe keine Ahnung warum
Mikaels-MacBook-Pro-2:test mikaelle$ rm -fr node_modules/*
Mikaels-MacBook-Pro-2:test mikaelle$ npm install knex typescript ts-node
npm WARN [email protected] No description
npm WARN [email protected] No repository field.
+ [email protected]
+ [email protected]
+ [email protected]
added 295 packages from 184 contributors and audited 1213 packages in 6.59s
found 0 vulnerabilities
Mikaels-MacBook-Pro-2:test mikaelle$ node_modules/.bin/knex migrate:make --knexfile knexfile.ts test
Requiring external module ts-node/register
Created Migration: /xxx/migrations/20190119003358_test.js
Mikaels-MacBook-Pro-2:test mikaelle$ cat knexfile.ts
import * as knex from 'knex'; export = {client: 'pg'}
Mikaels-MacBook-Pro-2:test mikaelle$
Ich habe Ihre docker-compose.yml geändert, um so ziemlich dasselbe zu machen, und es schlägt wie folgt fehl:
version: '3'
services:
api:
image: node:8.14.0
command: bash -c 'rm -fr api/node_modules; npm i knex ts-node typescript; node_modules/.bin/knex migrate:make --knexfile ./src/db/knexfile.ts test'
working_dir: /usr/src/app
volumes:
- ./api:/usr/src/app
api_1 | npm WARN [email protected] No repository field.
api_1 |
api_1 | + [email protected]
api_1 | + [email protected]
api_1 | + [email protected]
api_1 | updated 3 packages and audited 1176 packages in 9.804s
api_1 | found 0 vulnerabilities
api_1 |
api_1 | /usr/src/app/src/db/knexfile.ts:1
api_1 | (function (exports, require, module, __filename, __dirname) { import { database } from '../config'
api_1 | ^^^^^^
api_1 |
Wenn ich knexfile in Ihrem Container nach /usr/src/app verschoben habe, hat es versucht, richtig zu kompilieren ... Ich kann dieses Verhalten jedoch lokal nicht reproduzieren. Hier funktioniert alles, auch wenn sich knexfile.ts in Unterverzeichnissen befindet...
Ich glaube, ich habe vielleicht einen Fehler bei 0.16 gefunden oder einfach nur etwas Seltsames.
Am 0.15 wird launch
mit configPath
aufgerufen
https://github.com/tgriesser/knex/blob/0.15.2/bin/cli.js#L260
Aber auf 0.16 heißt es mit
knexfile: argv.knexfile,
knexpath: argv.knexpath,
https://github.com/tgriesser/knex/blob/0.16.3/bin/cli.js#L303 -L304
LiftOff ruft var env = this.buildEnvironment(opts);
was findConfig({
aufruft, vorbei an configPath
(was nicht mehr bereitgestellt wird). Intern verwendet es configPath
und verweist nicht auf knexfile
oder knexpath
.
Ich habe typescript
und ts-node
im Projekt installiert und es funktioniert, wenn ich v0.15 installiert habe (wie das Beispiel, das ich im Git-Repository bereitgestellt habe.
Ich habe ein bisschen debuggt und das gefunden, aber ich habe immer noch nicht herausgefunden, warum es auf 0.15 . funktioniert
[email protected]
Protokollieren des Ergebnisses dieser Zeile
var config = require(env.configPath);
https://github.com/tgriesser/knex/blob/0.15.2/bin/cli.js#L55
Ich verstehe das
api_1 | require(/usr/src/app/src/db/knexfile.ts)------------ { client: 'postgresql',
api_1 | connection: 'postgres://user:password@db/api-db',
api_1 | migrations:
api_1 | { directory: '/usr/src/app/src/db/migrations1337',
api_1 | tableName: 'knex_migrations' },
api_1 | seeds: { directory: '/usr/src/app/src/db/seeds' } }
api_1 | this.config { extension: 'js',
api_1 | loadExtensions:
api_1 | [ '.co',
api_1 | '.coffee',
api_1 | '.eg',
api_1 | '.iced',
api_1 | '.js',
api_1 | '.litcoffee',
api_1 | '.ls',
api_1 | '.ts' ],
api_1 | tableName: 'knex_migrations',
api_1 | schemaName: null,
api_1 | directory: '/usr/src/app/src/db/migrations1337',
api_1 | disableTransactions: false }
Das Migrationsverzeichnis sagt directory: '/usr/src/app/src/db/migrations1337',
, was genau das ist, was ich auf knexfile.ts habe
Und es erfordert direkt die Datei .ts
require('/usr/src/app/src/db/knexfile.ts')
[email protected]
Die Anforderung bezieht sich auf genau dieselbe Datei, aber sie schlägt fehl
// /usr/src/app/src/db/knexfile.ts
env.configuration = require(resolvedKnexfilePath);
[email protected]
Ich habe typescript
und ts-node
deinstalliert. Jetzt bekomme ich das:
api_1 | Failed to load external module ts-node/register
api_1 | Failed to load external module typescript-node/register
api_1 | Failed to load external module typescript-register
api_1 | Failed to load external module typescript-require
api_1 | Failed to load external module @babel/register
cli.on('requireFail', function(name) {
console.log(chalk.red('Failed to load external module'), chalk.magenta(name));
});
https://github.com/tgriesser/knex/blob/0.15.2/bin/cli.js#L254
Ich sehe diese Nachricht bei 16 überhaupt nicht, sie bricht einfach ab.
@elhigu Ich habe es herausgefunden, ich habe eine PR gemacht, kannst du es überprüfen?
https://github.com/tgriesser/knex/pull/3005
Wiedereröffnung, da dies wahrscheinlich irgendwo ein Fehler ist ... auch wenn ich nicht weiß, wie ich es auf osx reproduzieren soll.
Zu Ihrer Information, ich habe das Beispiel von brunolm ausgeführt und Knex 0.15.2 funktioniert, während Knex 0.16.3 nicht funktioniert
@scorbin ja, das konnte ich auch mit Docker reproduzieren, aber nicht lokal auf osx. Deshalb habe ich das wieder geöffnet.
Gleiches Problem hier (TypeScript-Migrationen + 0.16.3).
Wenn Migrator#latest
aufgerufen wird, beginnt es mit migrationListResolver#listAllAndCompleted
was wiederum listAll(config.migrationSource)
aufruft, wobei migrationSource
loadExtensions = [".co", ".coffee", ".eg", ".iced", ".js", ".litcoffee", ".ls", ".ts"]
, auch wenn ich { …, loadExtensions: ['.js'], … }
in der Migrator-Konfiguration.
Als Konsequenz wählt es sowohl die .ts
Dateien als auch .js
und weist die Migration an, mit den .ts
Dateien fortzufahren (da sie noch nicht angewendet werden sollen, offensichtlich), die... bricht, wenn #getMigration
schließlich aufgerufen wird, um das Skript auszuwerten (da es #require
mit dem Migrationsskript, das TypeScript ist, aufruft).
Hoffe das hilft...
Mit der folgenden kleinen Änderung scheinen die Dinge wieder normal zu sein:
function listAllAndCompleted(config, trxOrKnex) {
return _bluebird.default.all([listAll(config.migrationSource, config.loadExtensions), listCompleted(config.tableName, config.schemaName, trxOrKnex)]);
}
Ich habe jedoch nicht validiert, dass es zu 100% mit dem Design des Migrators übereinstimmt - einer, der sachkundiger ist, als ich validieren müsste! :)
Ich hatte das gleiche Problem mit der Knex-Version 0.16.3
.
import * as Knex from 'knex';
^^^^^^
SyntaxError: Unexpected token import
at createScript (vm.js:80:10)
at Object.runInThisContext (vm.js:139:10)
at Module._compile (module.js:617:28)
at Object.Module._extensions..js (module.js:664:10)
Diese Lösung wird nicht empfohlen, aber ich habe sie einfach behoben, indem ich einfach ts-node/register
am Anfang der knexfile.ts
Datei hinzugefügt habe.
require('ts-node/register');
//
Sollte in 0.16.4-Next2 . behoben werden
Habe gerade 0.16.4-next2 ausprobiert. Schade, den gleichen Fehler zu sehen
@brunolm können Sie bestätigen, dass 0.16.4-next2 dies immer noch fehlschlägt?
@pvoisin Funktioniert es bei Ihnen mit 0.16.4-next2?
@kibertoad Ich
OK, die richtige Lösung dafür wäre, die Abhängigkeit von knexfile von migration:make vollständig zu entfernen (da es nicht wirklich benötigt wird).
Ich möchte das tote Pferd nicht schlagen, aber @kibertoad sagte, es _sollte_ repariert werden. Wo war der Beweis für diese Korrektur? Wurden Regressionstests geschrieben? Zu sagen, dass es behoben werden sollte, das Problem zu schließen und dasselbe Problem zu haben, ist nicht die Art und Weise, wie Releases gepusht werden sollten.
@juliancoleman das war schwer zu reproduzieren. Aber in der Tat hätte ein Regressionstest im Fix hinzugefügt werden sollen (nicht überprüft, ob es tatsächlich einen gab, und der Test ist auf ci env einfach nicht fehlgeschlagen).
Schwierig zu reproduzieren ist eigentlich fair, wenn ich zurückblicke und festgestellt habe, dass niemand, mich eingeschlossen, Schritte zur Reproduktion hinzugefügt hat.
[email protected]
zu Abhängigkeiten hinzufügenknexfile.ts
Model.knex
package.json
"knex": "knex --knexfile ./path/to/Knexfile.ts"
yarn knex migrate:latest
SyntaxError
Ich habe diese Schritte bei einem Projekt überprüft, das ich neulich gestartet habe, was mich zu diesem Problem geführt hat
"knex": "^0.16.4-next2",
git clone [email protected]:brunolm/knex16bug.git
cd knex16bug
git checkout knex16
npm run api-i
docker-compose up
api_1 | > knex migrate:make --knexfile ./src/db/knexfile.ts "test"
api_1 |
api_1 | /usr/src/app/src/db/knexfile.ts:1
api_1 | (function (exports, require, module, __filename, __dirname) { import { database } from '../config'
api_1 | ^^^^^^
api_1 |
api_1 | SyntaxError: Unexpected token import
api_1 | at createScript (vm.js:80:10)
api_1 | at Object.runInThisContext (vm.js:139:10)
api_1 | at Module._compile (module.js:617:28)
api_1 | at Object.Module._extensions..js (module.js:664:10)
api_1 | at Module.load (module.js:566:32)
api_1 | at tryModuleLoad (module.js:506:12)
api_1 | at Function.Module._load (module.js:498:3)
api_1 | at Module.require (module.js:597:17)
api_1 | at require (internal/module.js:11:18)
api_1 | at initKnex (/usr/src/app/node_modules/knex/bin/cli.js:62:25)
api_1 | at Command.commander.command.description.option.action (/usr/src/app/node_modules/knex/bin/cli.js:172:24)
api_1 | at Command.listener (/usr/src/app/node_modules/commander/index.js:315:8)
api_1 | at emitTwo (events.js:126:13)
api_1 | at Command.emit (events.js:214:7)
api_1 | at Command.parseArgs (/usr/src/app/node_modules/commander/index.js:654:12)
api_1 | at Command.parse (/usr/src/app/node_modules/commander/index.js:474:21)
api_1 | npm ERR! code ELIFECYCLE
api_1 | npm ERR! errno 1
api_1 | npm ERR! [email protected] migrate-make: `knex migrate:make --knexfile ./src/db/knexfile.ts "test"`
api_1 | npm ERR! Exit status 1
api_1 | npm ERR!
api_1 | npm ERR! Failed at the [email protected] migrate-make script.
api_1 | npm ERR! This is probably not a problem with npm. There is likely additional logging output above.
api_1 |
api_1 | npm ERR! A complete log of this run can be found in:
api_1 | npm ERR! /root/.npm/_logs/2019-03-18T21_39_10_408Z-debug.log
Meine PR behebt es, ich habe nur nicht das Wissen, es vollständig zu testen usw.
Ich möchte das tote Pferd nicht schlagen, aber @kibertoad sagte, es sollte
Ich entschuldige mich, es war zu später Stunde hier in Amsterdam und meine Wortwahl war wirklich nicht die beste. Es hätte "Bitte lassen Sie es mich wissen, wenn 0.16.4-next2 das Problem behebt" heißen müssen, da ich sehr überrascht gewesen wäre, wenn es so wäre. Es wurde ein Komponententest geschrieben, der genau überprüft, was dieser Fix tatsächlich behebt, und jetzt bin ich mir ziemlich sicher, dass ich nichts falsch verstehe und dieses Problem genau das ist, was ich dachte, und die einzige Möglichkeit, wie es früher hätte funktionieren können ist durch das vollständige Umgehen von Knexfile. Dies ist ein Systemverhalten, das ich in naher Zukunft verbessern möchte, aber es erfordert, dass vorher einige Voraussetzungen erfüllt werden. Ich entschuldige mich für die Unannehmlichkeiten. Gib mir einfach etwas Zeit. In der Zwischenzeit scheint die Verwendung von ts-node eine geeignete Lösung zu sein - man könnte argumentieren, dass es tatsächlich weniger hackig ist, als nicht von knexfile abhängig zu sein, da es Ihnen ermöglicht, knexfile als einzige Quelle der Wahrheit über den Speicherort von Migrationsdateien zu verwenden.
@kibertoad
und die einzige Möglichkeit, wie es zuvor hätte funktionieren können, besteht darin, knexfile vollständig zu umgehen.
Dies ist nicht wahr, siehe meine vorherigen Kommentare. Alles funktioniert auf 0.15.
@brunolm Aber können Sie auf technischer Ebene erklären, wie Node.js beim Parsen der Typescript-Datei auch hypothetisch nicht
@kibertoad Ich verwende derzeit ts-node. Ich bin mir nicht sicher, warum das auf technischer Ebene passiert
Wenn ich die Zeit hätte, die Quelle zu überprüfen, würde ich es tun, aber ich benutze Knex seit Jahren und vertraue einfach darauf, dass es zu diesem Zeitpunkt funktioniert. Ich habe wieder auf 0.15 zurückgesetzt und alles funktioniert ... außer natürlich
@brunolm Aber können Sie auf technischer Ebene erklären, wie Node.js beim Parsen der Typescript-Datei auch hypothetisch nicht
Wenn Sie dies tun, können Sie sehen, dass es auf knex 0.15
vollständig funktioniert, ohne die Datei knexfile.ts zu ignorieren
git clone [email protected]:brunolm/knex16bug.git
cd knex16bug
git checkout knex15
npm run api-i
docker-compose up
Wenn Sie jedoch genau dasselbe auf Knex 0.16
ausführen, wird der Fehler angezeigt. Wenn Sie dies klonen, schlage ich vor, in einen anderen Ordner zu klonen, damit Sie sicherstellen können, dass Sie die richtige Version haben
git clone [email protected]:brunolm/knex16bug.git
cd knex16bug
git checkout knex16
npm run api-i
docker-compose up
Ich habe diese Beispiele von @brunolm zuvor überprüft. Ich war nie in der Lage, dafür einen Reproduktionsfall zu erstellen, der auf
Das Problem wäre also derzeit, einen Testfall für Knex CI erstellen zu können, der eigentlich auch bei 0.16 fehlschlägt und mit 0.15 arbeitet. Da CI ein altes Ubuntu ausführt, funktioniert dieser Testfall vielleicht (dh schlägt fehl) dort gut.
Kurzes Update von meiner Seite. Ich bin mir nicht sicher, ob dies nützlich ist oder nicht, aber mein Problem war, dass ich mehrere tsconfig.json
Dateien in meinem Projekt verwendet habe und knex
die Standardeinstellung verwendet hat. Als ich diese Funktionalität überschrieben habe, indem ich knex
mit ts-node
direkt gestartet habe, konnte ich diesen Fehler umgehen.
Mein aktualisiertes package.json
:
// ...
"knex": "ts-node --project tsconfig.server.json $(npm bin)/knex --knexfile ./src/server/knexfile.ts",
// ...
So führe ich Migrationen jetzt durch:
npm run knex -- migrate:latest
Hoffentlich hilft das jemandem.
@FindAPattern würde es Ihnen etwas ausmachen, Ihre tsconfig zu posten? Hier ist meins. Ich benutze nur einen, da ich nicht bauen muss, da ich mit ts-node
bediene
{
"compilerOptions": {
"noEmit": true,
"rootDir": "src",
"target": "es6",
"module": "commonjs",
"moduleResolution": "node",
"declaration": true,
"inlineSourceMap": true,
"resolveJsonModule": true,
},
"include": [
"src/**/*.ts",
],
"exclude": [
"src/**/*.spec.ts"
]
}
Hi! Gibt es diesbezüglich Fortschritte?
@brunolm Wie löst du es? Irgendeine Problemumgehung?
@algil Ich musste noch kein neues Projekt aktualisieren oder starten, daher verwende ich zum größten Teil immer noch 0.15.
Aber ich habe eine PR erstellt, die dieses Problem löst. Sie können Knex fork und diese Änderungen darauf anwenden: https://github.com/tgriesser/knex/pull/3005
Es ist leider nicht so einfach. Ich werde versuchen, eine Lösung zu finden, die diese Woche keine Anwendungsfälle zerstört.
Vielleicht hilft es jemandem. Behoben bei Änderung in tsconfig.json "module": "es2015" zu "module": "commonjs"
Befehl in package.json => "migrate": "ts-node -P ./tsconfig.json node_modules/.bin/knex migration :latest --knexfile knexfile.ts".
Vielleicht hilft es jemandem. Behoben bei Änderung in tsconfig.json "module": "es2015" zu "module": "commonjs"
Befehl in package.json => "migrate": "ts-node -P ./tsconfig.json node_modules/.bin/knex migration :latest --knexfile knexfile.ts".
Keine optimale Lösung, funktioniert aber gut.
@Areshetcov @Meldiron Ich habe das Modul commonjs
wie Sie oben sehen können . Ich denke, was wirklich passieren muss, ist eine tiefere Unterstützung, die nicht unbedingt eine Menge Benutzerkonfiguration verursacht. Es sei denn, das ist wirklich keine Option
Wenn man bedenkt, wie dieses Problem mit einer Veröffentlichung zusammenhängt, die jetzt zurückliegt, ist dies derzeit ein Problem mit 0.17.6
?
@juliancoleman Die Verwendung von ts-node ist immer noch die beste Lösung, da Knex immer noch versucht, knexfile.js zu öffnen und explodiert, wenn es nicht im Javascript-Format vorliegt. Es gab jedoch Verbesserungen, um TS-Erweiterungen in mehr Fällen eleganter zu handhaben (z. B. Migrationsgenerierung oder Auflösung von Knexfiles im Standardspeicherort). Welches spezielle Problem hast du?
Auf jeden Fall vielen Dank, dass Sie mich an dieses Problem erinnern. Ich versuche es am Wochenende noch einmal, hoffentlich kann ich zumindest verstehen, warum es in der Vergangenheit funktioniert hat :D
Als ich diese PR gemacht habe, ist mir aufgefallen, dass es nicht nur mit TypeScript funktionieren soll, sondern auch mit Babel und einigen anderen Sachen, es gibt ein Paket, das all das handhabt - wenn ich mich richtig erinnere.
Meine PR könnte einige nützliche Hinweise enthalten https://github.com/tgriesser/knex/pull/3005/files
Das Problem, das ich habe, ist, wenn ich npm run knex migrate:latest
ausführe, erhalte ich ein unexpected token '{'
. Ich verwende ts-node nur für diese API. Ich lasse es durch keinen Bundler laufen und ich kompiliere den TS nicht. Es ist wahrscheinlich nicht gut, das zu _tun_, aber das ist es, was ich jetzt tue. Mir ist jedoch bewusst, dass Typescript keine Typescript-Dateien von Drittanbietern importieren kann. Sie müssen zuerst gebaut werden. Das habe ich anderswo erlebt, nicht nur bei Knex
Mir ist jedoch bewusst, dass Typescript keine Typescript-Dateien von Drittanbietern importieren kann.
Meinen Sie, dass ts-node
keine Typescript-Dateien mit require()
laden kann? Migrator verwendet require()
, um diese Migrationsdateien dynamisch zu laden...
Ich melde mich einfach hier, wenn jemand das gleiche Problem hat wie ich: Ich habe [email protected]
und habe versucht, im Wesentlichen * knex --knexfile src/knexfile.ts
auszuführen, was fehlgeschlagen ist, da anscheinend versucht wird, die Knexdatei als JS zu lesen. Die Verwendung von knex --cwd src
funktioniert wie beabsichtigt.
*) Die tatsächliche Befehlszeile war node -r dotenv/config node_modules/knex/bin/cli [...]
aber das spielt wahrscheinlich keine Rolle.
@ilkka Könnten Sie klarstellen, was "funktioniert wie beabsichtigt" in diesem Zusammenhang bedeutet? Wenn man bedenkt, dass Sie node
und nicht ts-node
ausführen, ist es nicht Knex, das knexfile.ts nicht parst, sondern Node. Es sei denn, Sie meinen, dass die Dateinamenauflösung falsch funktioniert.
Schafft es knex --cwd src
tatsächlich, das fragliche Knexfile zu öffnen und reagiert es korrekt auf Konfigurationsänderungen darin?
Ah, es tut mir leid, dass ich unklar war. Wenn ich den Parameter --cwd
, wenn ich Knex aus meinen npm-Skripten ausführe, meldet es "Erfordert externes Modul ts-node/register", liest meine Knexdatei und funktioniert. Das Verhalten ist dasselbe, wenn ich es außerhalb eines npm-Skripts als npx knex
ausführe.
@ilkka Interessant. Ich glaube nicht, dass Knex jemals versucht, ts-node alleine zu laden, also muss es etwas anderes aus dem Stack sein, den Sie verwenden. Wenn Sie herausfinden könnten, was es genau ist, könnten Sie herausfinden, was wir getan haben, um die Kompatibilität damit zu unterbrechen.
Ich glaube, die Nachricht über die Anforderung des Moduls wird hier von cli.js
ausgegeben, verursacht durch ein Liftoff-Ereignis (vorher wurde 'require' in Liftoff in etwas anderes umbenannt). Liftoff wiederum verwendet ein Paket namens "rechoir", um Loader oder was auch immer zu registrieren, und die README von rechoir enthält diesen Hinweis, wie es "Transpiler wie coffee-script
automatisch lädt und registriert". Also... vielleicht reicht es aus, in diesem speziellen Fall nur ts-node
in meinem Pfad zu haben, damit dies funktioniert? Es ist ein ziemlich kompliziertes System.
Wie auch immer, jetzt ist mir klar, dass wir in unserem npm-Skript einfach node
in ts-node
hätten ändern können und es hätte auch funktioniert.
Danke, dass Sie sich das angeschaut haben. Ich werde sehen, ob ich mich in diesen Fällen beim Abheben benehmen kann :D
aber ja, die direkte Verwendung von ts-node sollte in allen Fällen funktionieren.
Hatte den gleichen Fehler. Es stellte sich heraus, dass ich tsconfig.json
falsch kopiert habe. Jetzt geht es. Relevante Konfigurationen:
package.json (Arbeitsbereich)
"scripts": {
"migrate:make": "knex --cwd src migrate:make -x ts"
},
"dependencies": {
"knex": "0.19.0",
"pg": "7.11.0"
}
package.json (root):
"ts-node-dev": "1.0.0-pre.40",
(ts-Knotenversion ist: 8.3.0)
tsconfig.json (Arbeitsbereich):
{
"extends": "../../tsconfig.node.json",
"compilerOptions": {
"rootDir": "./src",
"outDir": "./build",
}
}
tsconfig.node.json (root):
{
"compilerOptions": {
"target": "es2015",
"moduleResolution": "node",
"esModuleInterop": true,
"strict": true,
"alwaysStrict": true,
"declaration": true,
}
}
src/knexfile.ts:
import { Config } from 'knex'
export = {
client: 'pg',
connection: {
database: 'db',
user: 'user',
},
} as Config
Befehl zum Ausführen:
yarn migrate:make my_migration_name
Das Problem besteht weiterhin auf [email protected]
git clone [email protected]:brunolm/knex16bug.git
cd knex16bug
git checkout knex19
npm run api-i
docker-compose up
api_1 | /usr/src/app/src/db/knexfile.ts:1
api_1 | (function (exports, require, module, __filename, __dirname) { import { database } from '../config'
api_1 | ^^^^^^
@brunolm warum bist du so ignorant?
diff --git a/api/package.json b/api/package.json
index c0f8bff..0906f51 100644
--- a/api/package.json
+++ b/api/package.json
@@ -8,7 +8,7 @@
"dev": "ts-node-dev --respawn --poll --no-notify src/index.ts",
"\n# Database": "",
"migrate": "knex migrate:latest --knexfile ./src/db/knexfile.ts",
- "migrate-make": "knex migrate:make --knexfile ./src/db/knexfile.ts",
+ "migrate-make": "knex migrate:make --cwd src/db",
"seed": "knex seed:run --knexfile ./src/db/knexfile.ts",
"seed-make": "knex seed:make --knexfile ./src/db/knexfile.ts",
"\n# Testing": "",
api_1 | > [email protected] migrate-make /usr/src/app
api_1 | > knex migrate:make --cwd src/db "test"
api_1 |
api_1 | Requiring external module ts-node/register
api_1 | Working directory changed to /usr/src/app/src/db
api_1 | Created Migration: /usr/src/app/src/db/migrations/20190723173751_test.ts
Die Angabe von --knexfile
funktioniert immer noch nicht.
Die Verwendung von --cwd src/db
funktioniert stattdessen.
Die Dokumentation ist nicht klar, dass Sie cwd
über knexfile
.
Ich habe die Funktionssignatur nicht überprüft, als ich diesen PR geändert habe, um die richtigen Parameter zu übergeben, ist es möglich, dass immer noch die falschen Parameter übergeben werden.
Hallo Leute
Ich hatte diesen Fehler auch
Ich denke, das Problem ist, dass die Option --knexfile
fälschlicherweise ein Verzeichnis für knexfile.ts festgelegt hat
Also setze ich explizite Anweisungen mit --cwd
für das Verzeichnis mit knexfile.ts
Bei mir funktioniert es: "knex migrate:make --cwd src"
(Es ist gleich: "cd src knex migrate:make"
)
Ich habe knex migrate:make --knexfile knexfile.ts -x ts new_script
versucht
Ich bekomme folgenden Fehler
importiere knex von 'knex';
^^^^
SyntaxError: Unerwarteter Bezeichner
beim Hinzufügen von cwd
internal/process/main_thread_only.js:29
Binding.chdir(Verzeichnis);
meine knexfile.ts sieht wie folgt aus
import knex from 'knex';
export const database: knex.Config = {
client: 'postgresql',
connection: process.env.databaseURL,
migrations: {
extension: 'ts',
directory: './ds/migrations',
},
seeds: {
directory: './ds/seed',
},
};
irgendeine Ahnung?
Für andere Google-Nutzer hatte ich den Fehler "unerwarteter Token-Export", als ich versuchte, mit dem neuesten Knex 0.19 im vollständigen Typoskriptmodus nach oben / unten zu migrieren.
Es stellte sich heraus, dass ich sowohl ein tsconfig.json
als auch ein .babelrc
im Arbeitsverzeichnis hatte, ich vermute, dass eines davon die Transpilation störte.
Als ich den Migrationsordner und die knexfile.ts
in ein sauberes Verzeichnis verschoben habe, hat es wieder funktioniert ✅ .
Hallo Leute. Wie @mikl sagte, besteht das Problem darin, dass Sie versuchen, Typoskriptcode auf dem Knoteninterpreter auszuführen. Ich bin heute auf dieses Problem gestoßen, als ich versuchte, eine neue Migration zu erstellen.
Ich habe dieses Problem gelöst, indem ich Knex über ts-node
(https://npmjs.com/package/ts-node) ausgeführt habe.
Damit dies funktioniert, fügen Sie einfach dieses Skript in Ihre package.json
Datei ein :)
"migrate:make": "ts-node ./node_modules/.bin/knex migrate:make --knexfile <PATH_TO_YOUR_KNEXFILE>"
Replizieren Sie dies in migrate:latest
, seed:run
usw... :)
Dann führen Sie einfach Ihr neues Skript aus!
Anstelle von --knexfile
verwenden Sie --cwd
- "migrate-make": "knex migrate:make --knexfile ./src/db/knexfile.ts",
+ "migrate-make": "knex migrate:make --cwd src/db",
Lösung
Anstelle von
--knexfile
verwenden Sie--cwd
- "migrate-make": "knex migrate:make --knexfile ./src/db/knexfile.ts", + "migrate-make": "knex migrate:make --cwd src/db",
Vielen Dank !! Es hilft mir sehr.
Warum ist das geschlossen? Es ist total kaputt beim Arbeiten mit knexfile.ts, habe alles versucht, was ich aus diesem Thread herausholen konnte ... (neueste Version + Typoskript 3.6.4)
Warum ist das geschlossen? Es ist total kaputt beim Arbeiten mit knexfile.ts, habe alles versucht, was ich aus diesem Thread herausholen konnte ... (neueste Version + Typoskript 3.6.4)
Öffnen Sie eine neue Ausgabe und geben Sie einen Reproduktionscode an (z. B. einen Link zu einem Beispielprojekt, bei dem Ihr Problem auftritt). Dies wurde geschlossen, weil @brunolm seine Lösung für sein Problem gefunden hat.
Es ist immer noch mit --cwd
gebrochen:
knexfile.ts:6
export default {
^^^^^^
SyntaxError: Unexpected token export
Ich werde also kein neues Thema ansprechen, da ich nicht weiß, wie es funktionieren soll. Ein minimales vollständiges Typoskript-Beispiel in den Dokumenten wäre ... Gottesgeschenk
Das Typescript-Beispiel von Objectin.js hat sich nicht die Mühe gemacht, Knex in Typescript zu verwenden, daher denke ich, dass sie das gleiche Problem hatten ...
Nun ... Was ich haben wollte:
Ich denke, dieser letzte Punkt war umso schmerzhafter ...
Was ich tun musste, damit alles funktionierte:
export =
anstelle der Typoskript-Exporte zu verwenden ... Also ja, ich habe eine ts-Datei, aber in meiner app.ts kann ich sie nicht importieren und musste sie anfordern.knex.migrate.latest({
loadExtensions: ['.js'],
});
"db:migrate": "knex migrate:latest --cwd ./dist/config --env development --knexfile knexfile.js"
Und ich habe einiges vergessen, da bin ich mir sicher..
Jetzt bin ich nicht ganz zufrieden, da es sich total hacky anfühlt
@ctiaffay-conserto Sie könnten dieses Beispiel versuchen (ersetzen Sie knexfile
durch cwd
)
https://github.com/brunolm/knex16bug/tree/knex16
Lösung
Anstelle von
--knexfile
verwenden Sie--cwd
- "migrate-make": "knex migrate:make --knexfile ./src/db/knexfile.ts", + "migrate-make": "knex migrate:make --cwd src/db",
Es funktioniert, aber... warum? Es sieht nicht nach der richtigen Lösung aus, da --knexfile
funktionieren soll.
@ShGKme Dies sind die Änderungen, die erforderlich sind, damit es funktioniert: https://github.com/knex/knex/pull/3005
Aber niemand will es ansprechen, da cwd
funktioniert, bin ich glücklich genug, das einfach zu akzeptieren.
Ich verbrachte den Nachmittag damit, dies zu untersuchen, weil ich auf ein eng verwandtes Initialisierungsproblem stieß. Ich glaube, dass die Einschätzung von @brunolm richtig ist: Die Methode Liftoff#launch(..)
wird mit den falschen Parametern aufgerufen. Sie können die Details in #3005 sehen
Grob gesagt verhält sich Liftoff
wie folgt:
// If the configPath was specified, then use it. Otherwise, try to infer it.
const configPath = opts.configPath || inferConfigPath(opts);
function inferConfigPath(opts) {
// configName represents the expected name of the config file, minus its extension.
// For example: "knexfile"
// If no configName was specified, then attempt to infer it from the name instead.
// In our case, since `name === "knex"`, this will result in `configName = "knexfile"`
const configName = opts.configName || (opts.name + "file");
return findPathFor(configName, {
withPossibleExtensions: [".js", ".ts"],
inDirectory: opts.cwd,
});
}
Da es zur Zeit um einen Fehler in der Art und Weise ist , dass Liftoff#launch(..)
aufgerufen wird, wird der Wert von configPath
ist _always_ geschlossen wird. Folglich wird Liftoff
die entsprechenden preload
Skripte nicht starten. (Besonders: ts-node/register
wird nicht geladen)
@briandmaged Könnten Sie einen Fix-
@kibertoad + @brunolm : Ich werde versuchen, heute oder morgen etwas zusammenzustellen. Ich stelle immer noch sicher, dass ich zuerst das große Ganze verstehe. Soweit ich das beurteilen kann, sieht es so aus, als würde die Knex-CLI einige der Funktionen duplizieren, die bereits von der Liftoff
Bibliothek bereitgestellt werden.
@briandmaged Könnte sein. Solange die cli-Tests bestehen, damit wir wissen, dass wir keine Breaking Changes für Benutzer einführen, können Sie so tief wie nötig refaktorieren.
@brunolm @ShGKme @mmiszy @ilkka Dies sollte dank der erstaunlichen Arbeit von @briandamaged in 0.20.9 besser funktionieren. Probieren Sie es aus und lassen Sie mich wissen, ob die Änderungen für Sie hilfreich waren.
@kibertoad Alles funktioniert, vielen Dank
@kibertoad vielen Dank ! Ich kann bestätigen, dass es jetzt zu 100% funktioniert!
api_1 | > knex migrate:make --knexfile ./src/db/knexfile.ts "test"
api_1 |
api_1 | Requiring external module ts-node/register
api_1 | Working directory changed to /usr/src/app/src/db
api_1 | Created Migration: /usr/src/db/migrations/20200210194631_test.ts
@brunolm Haha, @briandamaged ist der wahre Held. Schön, dass es jetzt gut funktioniert!
Ich bekomme diesen Fehler immer noch mit NodeJS 14.0.0, dem Befehl knex migrate:make test
und der folgenden Datei:
// knexfile.ts
export const config = {
development: {
client: "postgres",
connection: {
filename: "./dev.sqlite3"
}
},
staging: {
client: "postgresql",
connection: {
database: "my_db",
user: "username",
password: "password"
},
pool: {
min: 2,
max: 10
},
migrations: {
tableName: "knex_migrations"
}
},
production: {
client: "postgresql",
connection: {
database: "my_db",
user: "username",
password: "password"
},
pool: {
min: 2,
max: 10
},
migrations: {
tableName: "knex_migrations"
}
}
};
Ich bekomme diesen Fehler:
Failed to load external module ts-node/register
Failed to load external module typescript-node/register
Failed to load external module typescript-register
Failed to load external module typescript-require
Failed to load external module @babel/register
(node:6468) UnhandledPromiseRejectionWarning: C:\Users\Flori\WebstormProjects\OragesAuthentication-Backend\knexfile.ts:3
export const config = {
^^^^^^
SyntaxError: Unexpected token 'export'
at wrapSafe (internal/modules/cjs/loader.js:1101:16)
at Module._compile (internal/modules/cjs/loader.js:1149:27)
at Object.Module._extensions..js (internal/modules/cjs/loader.js:1205:10)
at Module.load (internal/modules/cjs/loader.js:1034:32)
at Function.Module._load (internal/modules/cjs/loader.js:923:14)
at Module.require (internal/modules/cjs/loader.js:1074:19)
at require (internal/modules/cjs/helpers.js:72:18)
at openKnexfile (C:\Users\Flori\WebstormProjects\OragesAuthentication-Backend\node_modules\knex\bin\cli.js:26:16)
BEARBEITEN: Dies wurde behoben, indem ts-node als Abhängigkeit hinzugefügt wurde. Entschuldigen Sie die Unannehmlichkeiten.
Hilfreichster Kommentar
Ich hatte das gleiche Problem mit der Knex-Version
0.16.3
.Diese Lösung wird nicht empfohlen, aber ich habe sie einfach behoben, indem ich einfach
ts-node/register
am Anfang derknexfile.ts
Datei hinzugefügt habe.