<p>knex 0.16 unterstützt keine in TypeScript geschriebenen knexfiles</p>

Erstellt am 14. Jan. 2019  ·  85Kommentare  ·  Quelle: knex/knex

Umfeld

Knex-Version: 0.16.3
Datenbank + Version: docker postgres:10.4
Betriebssystem: Windows 10 Pro & Docker node:8.14.0

Insekt

  1. knex migrate:make --knexfile knexfile.ts
  2. Fehlermeldung: Unexpected token import

Funktioniert normal auf 0.15.x

Hilfreichster Kommentar

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');
//

Alle 85 Kommentare

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.

  1. [email protected] zu Abhängigkeiten hinzufügen
  2. Erstellen Sie ein knexfile.ts
  3. (optional mit ObjectionJS) Instanziieren Sie die Knex-Konfiguration auf Model.knex
  4. Fügen Sie das folgende Skript zu package.json

    • "knex": "knex --knexfile ./path/to/Knexfile.ts"

  5. Migrationen durchführen

    • yarn knex migrate:latest

  6. Lauf in 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.

https://github.com/tgriesser/knex/pull/3005

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!

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",

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:

  • mein gesamter Quellcode in ts
  • knexfile.ts in Typoskript
  • Migrationen in Typoskript (um die Autocomplete-API von createTable während des Codierens zu haben)
  • die Möglichkeit, all dies in der CLI zum Laufen zu bringen (Knex-Migration) UND die API in meiner app.ts zu verwenden (automatische Migration beim Serverstart)

Ich denke, dieser letzte Punkt war umso schmerzhafter ...

Was ich tun musste, damit alles funktionierte:

  • in tsconfig set allowJs=true + Declaration=false (ohne diesen Knex würde versuchen, .d.ts-Dateien auszuführen ...)
  • knexfile.ts: Es scheint obligatorisch, 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.
  • app.ts: Das Laden von nur .js-kompilierten Dateien funktionierte: knex.migrate.latest({ loadExtensions: ['.js'], });
  • package.json : Außerdem funktionierten nur js-kompilierte Dateien (in meinem /dist): "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.

War diese Seite hilfreich?
0 / 5 - 0 Bewertungen