0.16 a maintenant des types TypeScript inclus dans le référentiel (voir #2845 ). Vous devrez probablement supprimer le @types/knex de votre projet pour que cela fonctionne correctement.

J'ai désinstallé @types/knex mais j'ai toujours l'erreur.

/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 n'est-ce pas essayer d'exécuter du code dactylographié avec un nœud simple ? Je n'ai aucune idée de comment cela aurait pu fonctionner avec 0,15 non plus.

A quoi ressemble votre fichier knex ? y a-t-il des déclarations d'importation?

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

fonctionne à 100 % sur 0.15

Je ne sais pas pourquoi cela fonctionnerait avec 0,15. Comme vous l'indique l'erreur Unexpected token import , le import * as knex from 'knex' n'est pas compris par Node.js (pas dans la configuration que vous utilisez, du moins).

Vous devrez soit compiler votre fichier knex en JavaScript, utiliser une version Node.js qui comprend la syntaxe d'importation (voir https://nodejs.org/api/esm.html ), ou rétablir le fichier pour utiliser l'ancien require() Syntaxe

Je suppose qu'il y avait un bogue dans knex 0.15 pour qu'il ne lise jamais ce fichier knex. Ne ressemble pas à un bug dans 0.16 qui ne devrait pas fonctionner.

pour qu'il ne lise jamais ce fichier knex

Il lit à 100% le fichier knex, je l'utilise dans plus d'un seul projet (du haut de ma tête, je peux penser à 4, en production) avec différents dossiers de migration et données de connexion.

Sur la version 0.15 il était en train de compiler ou peut-être d'utiliser ts-node automatiquement pour exécuter le fichier.

Je viens de le tester... vous avez raison, les deux versions essaient d'enregistrer des trucs ts-node. On dirait que cette fonctionnalité n'est pas testée. Je ne sais pas si même documenté.

non... maintenant vraiment testé avec les trucs nécessaires installés sur le nœud 8

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

ne peut pas se reproduire, mais il est tout à fait possible d'implémenter une fonctionnalité, car knex utilise déjà ts-node pour compiler les fichiers et les graines de migration dactylographiés

J'ai configuré un exemple complet au cas où vous voudriez savoir pourquoi cela fonctionne sur 0,15 et non sur 0,16

Branche : knex16 a 0.16.3 installé
https://github.com/brunolm/knex16bug/tree/knex16

Branche : knex15 a 0.15.2 installé
https://github.com/brunolm/knex16bug/tree/knex15

Basculez vers la branche que vous souhaitez vérifier et exécuter sur le dossier racine :

docker-compose up

Si cela fonctionne, vous devriez voir une migration appelée test dans /api/src/db/migrations

après avoir installé également quelques paquets supplémentaires (ts-node ts-node-dev dactylographié), il semble que les deux, 0.15 et 0.16 fonctionnent très bien ici ... mais en effet votre configuration de docker avec le nœud 0.16 échoue et je ne sais pas pourquoi

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$ 

J'ai modifié votre docker-compose.yml pour qu'il soit à peu près le même et cela échoue comme ceci :

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  | 

Si j'ai déplacé knexfile dans votre conteneur vers /usr/src/app, il a essayé de compiler correctement... Je ne peux cependant pas reproduire ce comportement localement. Ici tout fonctionne même si knexfile.ts est dans des sous-répertoires...

Je pense avoir trouvé peut-être un bug sur 0.16, ou juste quelque chose de bizarre.

Sur 0,15 launch est appelé avec configPath
https://github.com/tgriesser/knex/blob/0.15.2/bin/cli.js#L260

Mais sur 0.16 il est appelé avec

    knexfile: argv.knexfile,
    knexpath: argv.knexpath,

https://github.com/tgriesser/knex/blob/0.16.3/bin/cli.js#L303 -L304

LiftOff appelle var env = this.buildEnvironment(opts); qui appelle findConfig({ passant configPath (qui n'est plus fourni). En interne, il utilise configPath et ne fait aucune référence à knexfile ou knexpath .

J'ai typescript et ts-node installés dans le projet et cela fonctionne lorsque j'ai installé la v0.15 (comme l'exemple que j'ai fourni sur le référentiel Git.

J'ai fait un peu de débogage et j'ai trouvé ça, mais je n'ai toujours pas compris pourquoi cela fonctionnait sur 0.15

[email protected]

Enregistrement du résultat de cette ligne

var config = require(env.configPath);

https://github.com/tgriesser/knex/blob/0.15.2/bin/cli.js#L55

j'ai compris

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 }

Le répertoire de migration indique directory: '/usr/src/app/src/db/migrations1337', , ce qui est exactement ce que j'ai sur knexfile.ts

Et cela nécessite directement le fichier .ts

require('/usr/src/app/src/db/knexfile.ts')

[email protected]

L'exigence concerne exactement le même fichier, mais elle échoue

// /usr/src/app/src/db/knexfile.ts
env.configuration = require(resolvedKnexfilePath);

[email protected]

J'ai désinstallé typescript et ts-node . Maintenant j'obtiens ceci :

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

Je ne vois pas du tout ce message le 16, il casse juste.

@elhigu j'ai compris, j'ai fait un PR, tu peux le vérifier ?
https://github.com/tgriesser/knex/pull/3005

Réouverture car c'est probablement un bug quelque part... même si je ne sais pas comment le reproduire sur osx.

Pour info, j'ai exécuté l'exemple de brunolm et knex 0.15.2 fonctionne alors que knex 0.16.3 ne fonctionne pas

@scorbin oui, j'ai pu reproduire cela aussi avec docker, mais pas localement sur osx. C'est pourquoi j'ai rouvert ça.

Même problème ici (migrations TypeScript + 0.16.3).
Lorsque Migrator#latest est appelé, il commence par migrationListResolver#listAllAndCompleted qui à son tour appelle listAll(config.migrationSource) où migrationSource ayant loadExtensions = [".co", ".coffee", ".eg", ".iced", ".js", ".litcoffee", ".ls", ".ts"] , même si je { …, loadExtensions: ['.js'], … } dans la configuration du migrateur.
En conséquence, il sélectionne à la fois les fichiers .ts et .js et indique à la migration de continuer avec les fichiers .ts (puisqu'on leur dit de ne pas encore être appliqués, évidemment), ce qui... casse lorsque #getMigration est finalement appelé pour évaluer le script (puisqu'il appelle #require avec le script de migration qui est TypeScript).

J'espère que cela t'aides...

Avec le petit changement suivant, les choses semblent revenir à la normale :

function listAllAndCompleted(config, trxOrKnex) {
  return _bluebird.default.all([listAll(config.migrationSource, config.loadExtensions), listCompleted(config.tableName, config.schemaName, trxOrKnex)]);
}

Je n'ai pas validé qu'il est conforme à 100% à la conception du migrateur - un plus connaisseur que moi devrait valider ! :)

J'étais confronté au même problème avec la version Knex 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)

Cette solution n'est pas encouragée mais je l'ai simplement corrigée en ajoutant simplement ts-node/register au début du fichier knexfile.ts .

require('ts-node/register');
//

Devrait être corrigé dans 0.16.4-next2

Je viens d'essayer 0.16.4-next2. Triste de voir la même erreur

@brunolm pouvez-vous confirmer que 0.16.4-next2 échoue toujours ?

@pvoisin Est-ce que ça marche pour vous avec 0.16.4-next2 ?

@kibertoad J'obtiens exactement la même erreur sur 0.16.4-next2.

OK, donc la solution appropriée pour cela serait de supprimer complètement la dépendance sur knexfile de migration:make (puisqu'il n'en a pas vraiment besoin).

Je ne veux pas battre le cheval mort, mais @kibertoad a dit qu'il _devrait_ être corrigé. Où était la preuve de ce correctif ? Des tests de régression ont-ils été écrits ? Dire qu'il devrait être corrigé, fermer le problème et avoir le même problème présent n'est pas la façon dont les versions devraient être poussées.

@juliancoleman cela a été difficile à reproduire. Mais en effet, il aurait dû y avoir un test de régression ajouté dans le correctif (je n'ai pas vérifié s'il y en avait réellement et le test n'a tout simplement pas échoué sur ci env).

Difficile à reproduire est en fait juste car j'ai regardé en arrière et j'ai vu que personne, y compris moi-même, n'a ajouté d'étapes pour se reproduire.

1. Ajouter [email protected] aux dépendances
2. Créez un knexfile.ts
3. (éventuellement en utilisant ObjectionJS) instanciez la configuration de knex sur Model.knex
4. Ajoutez le script suivant à package.json
   
   
   
   • "knex": "knex --knexfile ./path/to/Knexfile.ts"
   
   
5. Faire des migrations
   
   
   
   • yarn knex migrate:latest
   
   
6. Courir dans SyntaxError

J'ai vérifié ces étapes sur un projet que je viens de commencer l'autre jour, ce qui m'a amené à ce problème

    "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

Mon RP le répare, je n'ai tout simplement pas les connaissances pour le tester complètement, etc., si quelqu'un pouvait l'examiner ...

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

Je ne veux pas battre le cheval mort, mais @kibertoad a dit que cela devrait être corrigé. Où était la preuve de ce correctif ? Des tests de régression ont-ils été écrits ? Dire qu'il devrait être corrigé, fermer le problème et avoir le même problème présent n'est pas la façon dont les versions devraient être poussées.

Je m'excuse, il était une heure tardive ici à Amsterdam et mon choix de mots n'était vraiment pas le meilleur. Cela aurait dû être "S'il vous plaît laissez-moi savoir si 0.16.4-next2 résout le problème", car, TBH, j'aurais été très surpris si cela avait été le cas. Il y avait un test unitaire écrit qui vérifie exactement ce que ce correctif corrige réellement, et maintenant je suis à peu près sûr que je ne me trompe pas et que ce problème est exactement ce que je pensais que c'était, et la seule façon dont cela aurait pu fonctionner auparavant est en contournant entièrement knexfile. C'est un comportement du système que j'ai l'intention d'améliorer dans un avenir proche, mais il nécessite un peu de prérequis pour être livré avant. Je m'excuse pour le dérangement. Donne-moi juste un peu de temps. En attendant, l'utilisation de ts-node semble être une bonne solution - on pourrait dire que c'est en fait moins compliqué que de ne pas dépendre de knexfile, car il vous permet d'utiliser knexfile comme source unique de vérité concernant l'emplacement des fichiers de migration.

@kibertoad

et la seule façon dont cela aurait pu fonctionner auparavant était de contourner entièrement knexfile.

Ce n'est pas vrai, voir mes commentaires précédents. Tout fonctionne sur 0.15.

@brunolm Mais pouvez-vous expliquer sur le plan technique comment Node.js peut ne pas s'étouffer lors de l'analyse du fichier Typescript, même de manière hypothétique ? Je vais vérifier le PR, mais je soupçonne qu'il atteint finalement la même chose (bien que par des moyens différents) - contourne le fichier knex.

@kibertoad J'utilise actuellement ts-node. Je ne sais pas pourquoi cela se produit au niveau technique

Si j'avais le temps de vérifier la source, je le ferais, mais j'utilise Knex depuis des années et j'espère simplement qu'il fonctionne à ce stade. Je suis revenu à 0,15 et tout fonctionne... Sauf ça, bien sûr

@brunolm Mais pouvez-vous expliquer sur le plan technique comment Node.js peut ne pas s'étouffer lors de l'analyse du fichier Typescript, même de manière hypothétique ? Je vais vérifier le PR, mais je soupçonne qu'il atteint finalement la même chose (bien que par des moyens différents) - contourne le fichier knex.

si vous faites cela, vous pouvez le voir fonctionner pleinement sur knex 0.15 , sans ignorer le fichier knexfile.ts

git clone [email protected]:brunolm/knex16bug.git
cd knex16bug
git checkout knex15
npm run api-i
docker-compose up

Cependant, si vous exécutez exactement la même chose sur knex 0.16 vous verrez l'erreur. Si vous le clonez, je vous suggère de le cloner dans un dossier différent afin que vous puissiez vous assurer que vous êtes sur la bonne version

git clone [email protected]:brunolm/knex16bug.git
cd knex16bug
git checkout knex16
npm run api-i
docker-compose up

J'ai vérifié ces exemples de @brunolm plus tôt, je n'ai jamais pu créer de cas de reproduction pour cela qui échouerait sur macos, mais j'ai pu reproduire la configuration de docker.

Le problème actuel serait donc de pouvoir créer un cas de test pour knex CI, qui échoue également sur 0.16 et fonctionne avec 0.15. Étant donné que CI exécute un ancien ubuntu, peut-être que ce cas de test fonctionne (c'est-à-dire échoue) là-bas très bien.

Mise à jour rapide de mon côté. Je ne sais pas si cela est utile ou non, mais mon problème était que j'utilisais plusieurs fichiers tsconfig.json dans mon projet et que knex utilisait la valeur par défaut. Lorsque j'ai remplacé cette fonctionnalité en lançant directement knex aide de ts-node , j'ai pu contourner cette erreur.

Mes package.json :

// ...
"knex": "ts-node --project tsconfig.server.json $(npm bin)/knex --knexfile ./src/server/knexfile.ts",
// ...

Comment j'exécute les migrations maintenant :

npm run knex -- migrate:latest

Espérons que cela aide quelqu'un.

@FindAPattern voudriez-vous publier votre tsconfig ? Voici la mienne. Je n'en utilise qu'un, car je n'ai pas besoin de construire car je sers avec ts-node

{
  "compilerOptions": {
    "noEmit": true,
    "rootDir": "src",
    "target": "es6",
    "module": "commonjs",
    "moduleResolution": "node",
    "declaration": true,
    "inlineSourceMap": true,
    "resolveJsonModule": true,
  },
  "include": [
    "src/**/*.ts",
  ],
  "exclude": [
    "src/**/*.spec.ts"
  ]
}

Salut! Y a-t-il des progrès à ce sujet?

@brunolm Comment le

@algil Je n'ai pas encore eu besoin de mettre à jour ou de démarrer un nouveau projet, donc j'utilise toujours 0,15 pour la plupart.

Mais j'ai fait un PR qui résout ce problème, vous pouvez fork knex et lui appliquer ces modifications : https://github.com/tgriesser/knex/pull/3005

Ce n'est pas si simple, malheureusement. Je vais essayer de trouver un correctif qui ne casse aucun cas d'utilisation cette semaine.

Peut-être que cela aidera quelqu'un. Correction lors du changement dans tsconfig.json "module": "es2015" en "module": "commonjs"
Commande dans package.json => "migrate": "ts-node -P ./tsconfig.json node_modules/.bin/knex migrate:latest --knexfile knexfile.ts".

Peut-être que cela aidera quelqu'un. Correction lors du changement dans tsconfig.json "module": "es2015" en "module": "commonjs"
Commande dans package.json => "migrate": "ts-node -P ./tsconfig.json node_modules/.bin/knex migrate:latest --knexfile knexfile.ts".

Solution pas optimale mais fonctionne très bien.

@Areshetcov @Meldiron J'utilise le module commonjs comme vous pouvez le voir ci -

Considérant comment ce problème est lié à une version qui est maintenant en retard, est-ce actuellement un problème avec 0.17.6 ?

@juliancoleman L' utilisation de ts-node reste la meilleure solution, car knex essaie toujours d'ouvrir knexfile.js et explose s'il n'est pas au format Javascript. Cependant, des améliorations ont été apportées pour gérer les extensions TS de manière plus gracieuse dans davantage de cas (par exemple, génération de migration ou résolution du fichier knex dans l'emplacement par défaut). Quel problème particulier rencontrez-vous ?

En tout cas, merci de m'avoir rappelé ce problème. Je vais essayer de faire un autre swing ce week-end, j'espère pouvoir au moins comprendre pourquoi cela a fonctionné dans le passé :D

Quand j'ai fait ce PR, j'ai remarqué qu'il est censé fonctionner non seulement avec TypeScript, mais aussi avec babel et d'autres trucs, il y a un package qui gère tout ça - si je me souviens bien.

Mon RP pourrait avoir des conseils utiles https://github.com/tgriesser/knex/pull/3005/files

Le problème que j'ai est que lorsque j'exécute npm run knex migrate:latest , j'obtiens un unexpected token '{' . J'utilise ts-node uniquement pour cette API. Je ne le lance dans aucun bundler et je ne compile pas le TS. Ce n'est probablement pas une bonne chose de faire ça, mais c'est ce que je fais pour l'instant. Je suis cependant conscient que Typescript ne peut pas importer de fichiers dactylographiés tiers. Ils doivent être construits en premier. J'ai vécu ça ailleurs, pas seulement avec Knex

Je suis cependant conscient que Typescript ne peut pas importer de fichiers dactylographiés tiers.

Voulez-vous dire que ts-node ne peut pas charger des fichiers tapuscrits avec require() ? Migrator utilise require() pour charger ces fichiers de migration dynamiquement...

Je viens de sonner ici si quelqu'un d'autre a le même problème que moi : j'ai [email protected] et j'essayais d'exécuter essentiellement* knex --knexfile src/knexfile.ts qui a échoué car il essaie apparemment de lire le fichier knex en tant que JS. L'utilisation de knex --cwd src fonctionne comme prévu.

*) la ligne de commande réelle était node -r dotenv/config node_modules/knex/bin/cli [...] mais cela n'a probablement pas d'importance.

@ilkka Pourriez-vous préciser ce que signifie « fonctionne comme prévu » dans ce contexte ? Considérant que vous exécutez node et non ts-node , ce n'est pas Knex qui échoue à analyser knexfile.ts, c'est Node. À moins que vous ne vouliez dire que la résolution du nom de fichier fonctionne mal.
knex --cwd src parvient-il réellement à ouvrir le fichier knex en question et réagit-il correctement aux changements de configuration ?

Ah, je suis désolé de ne pas être clair. Lorsque j'utilise le paramètre --cwd lors de l'exécution de knex à partir de mes scripts npm, il signale "Nécessitant un module externe ts-node/register", lit mon fichier knex et fonctionne. Le comportement est le même si je l'exécute en tant que npx knex , en dehors d'un script npm.

@ilkka Intéressant. Je ne pense pas que knex tente de charger ts-node tout seul, il doit donc s'agir d'autre chose de la pile que vous utilisez. Si vous pouviez identifier ce que c'est exactement, il serait possible de comprendre ce que nous avons fait pour rompre la compatibilité avec cela.

Je crois que le message sur l'exigence du module est imprimé par cli.js ici , causé par un événement Liftoff (avant que 'require' ne soit renommé en quelque chose d'autre dans Liftoff). Liftoff utilise à son tour un package appelé "rechoir" pour enregistrer des chargeurs ou autre, et le fichier README de rechoir contient cette note sur la façon dont il "chargera et enregistrera automatiquement des transpileurs comme coffee-script ". Alors... peut-être que le simple fait d'avoir ts-node dans mon chemin dans ce cas spécifique est suffisant pour que cela fonctionne ? C'est un système assez compliqué.

Quoi qu'il en soit, je me rends compte maintenant que nous aurions pu simplement changer node en ts-node dans notre script npm et que cela aurait également fonctionné.

Merci de vous y être penché. Je vais voir si je peux faire en sorte que le décollage se comporte dans ces cas :D
mais oui, l'utilisation directe de ts-node devrait fonctionner dans tous les cas.

Avait la même erreur. Il s'est avéré que j'ai mal copié tsconfig.json . Maintenant ça marche. Configurations pertinentes :

package.json (espace de travail)

  "scripts": {
    "migrate:make": "knex --cwd src migrate:make -x ts"
  },
  "dependencies": {
    "knex": "0.19.0",
    "pg": "7.11.0"
  }

package.json (racine) :

        "ts-node-dev": "1.0.0-pre.40",

(la version du nœud ts est : 8.3.0)

tsconfig.json (espace de travail) :

{
    "extends": "../../tsconfig.node.json",
    "compilerOptions": {
        "rootDir": "./src",
        "outDir": "./build",
    }
}

tsconfig.node.json (racine) :

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

Commande à exécuter :

yarn migrate:make my_migration_name

Le problème persiste sur [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 pourquoi es-tu si 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

La spécification de --knexfile ne fonctionne toujours pas.

Utiliser --cwd src/db place fonctionne.

La documentation n'indique pas clairement que vous devez utiliser cwd sur knexfile .

Je n'ai pas vérifié la signature de la fonction, quand j'ai fait ce PR j'ai changé pour passer les bons paramètres, il est possible qu'elle passe toujours les mauvais paramètres.

salut les gars

j'ai aussi eu cette erreur
Je pense que le problème est que l'option --knexfile est mal définie un répertoire pour knexfile.ts
J'ai donc défini des directions explicites avec --cwd pour le répertoire avec knexfile.ts

Cela fonctionne pour moi : "knex migrate:make --cwd src"
(C'est égal à ceci : "cd src knex migrate:make" )

J'ai essayé knex migrate:make --knexfile knexfile.ts -x ts new_script
j'obtiens l'erreur suivante

importer knex à partir de « knex » ;
^^^^
SyntaxError: Identifiant inattendu

lors de l'ajout de cwd

interne/processus/main_thread_only.js:29
binding.chdir(répertoire);

mon knexfile.ts ressemble à ci-dessous

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',
  },
};

une idée ?

Pour les autres googleurs, j'ai eu l'erreur "exportation de jeton inattendue" en essayant de migrer vers le haut/bas avec le dernier knex 0.19 en mode dactylographié complet.

Il s'est avéré que j'avais à la fois un tsconfig.json et un .babelrc dans le répertoire de travail, je soupçonne que l'un de ceux-ci a interféré avec la transpilation.

Lorsque j'ai déplacé le dossier de migration et le knexfile.ts dans un répertoire propre, cela a fonctionné à nouveau ✅ .

Salut les gars. Donc, comme l' a dit

J'ai résolu ce problème en exécutant knex via ts-node (https://npmjs.com/package/ts-node).

Pour que cela fonctionne, ajoutez simplement ce script dans votre fichier package.json :)

"migrate:make": "ts-node ./node_modules/.bin/knex migrate:make --knexfile <PATH_TO_YOUR_KNEXFILE>"

Reproduisez ceci sur migrate:latest , seed:run etc... :)
Ensuite, exécutez simplement votre nouveau script !

Solution

Au lieu de --knexfile utilisez --cwd

-    "migrate-make": "knex migrate:make --knexfile ./src/db/knexfile.ts",
+    "migrate-make": "knex migrate:make --cwd src/db",

Solution

Au lieu de --knexfile utilisez --cwd

-    "migrate-make": "knex migrate:make --knexfile ./src/db/knexfile.ts",
+    "migrate-make": "knex migrate:make --cwd src/db",

Merci !! Cela m'aide beaucoup.

Pourquoi est-ce fermé ? C'est totalement cassé lorsque je travaille avec knexfile.ts, j'ai essayé tout ce que j'ai pu à partir de ce fil ... (dernière version + tapuscrit 3.6.4)

Pourquoi est-ce fermé ? C'est totalement cassé lorsque je travaille avec knexfile.ts, j'ai essayé tout ce que j'ai pu à partir de ce fil ... (dernière version + tapuscrit 3.6.4)

Ouvrez un nouveau numéro et fournissez le code de reproduction (par exemple un lien vers un exemple de projet où votre problème se produit). Cela a été fermé car @brunolm a trouvé sa solution à son problème.

C'est toujours cassé avec --cwd :

knexfile.ts:6
export default {
^^^^^^

SyntaxError: Unexpected token export

Donc, je ne soulèverai pas de nouveau problème car je ne sais même pas comment cela est censé fonctionner. Un exemple dactylographié complet minimal dans la documentation serait ... une aubaine
L'exemple de script dactylographié Objectin.js n'a pas pris la peine d'utiliser knex en script dactylographié, donc je pense qu'ils ont eu le même problème ...

Et bien...Ce que je voulais avoir :

• tout mon code source dans ts
• knexfile.ts en tapuscrit
• migrations en tapuscrit (pour avoir l'API de saisie semi-automatique createTable pendant le codage)
• la possibilité de faire fonctionner tout cela en CLI (migration knex) ET en utilisant l'API dans mon app.ts (migration automatique au démarrage du serveur)

Je pense que ce dernier point était d'autant plus pénible...

Ce que j'ai dû faire pour que tout fonctionne :

• dans tsconfig, définissez allowJs=true + declaration=false (sans cela, knex essaierait d'exécuter les fichiers .d.ts ...)
• knexfile.ts : il semble obligatoire d'utiliser export = place des exportations de dactylographes ... Donc oui j'ai un fichier ts mais dans mon app.ts je ne peux pas l'importer et j'ai dû l'exiger ..
• app.ts : le chargement uniquement des fichiers compilés .js a fonctionné : knex.migrate.latest({ loadExtensions: ['.js'], });
• package.json : aussi, seuls les fichiers compilés js fonctionnaient (dans mon /dist) : "db:migrate": "knex migrate:latest --cwd ./dist/config --env development --knexfile knexfile.js"

Et j'en ai oublié, j'en suis sûr..

Maintenant, je ne suis pas tout à fait satisfait car il se sent totalement hacky

@ctiaffay-conserto vous pouvez essayer cet exemple (remplacez knexfile par cwd )
https://github.com/brunolm/knex16bug/tree/knex16

Solution

Au lieu de --knexfile utilisez --cwd

-    "migrate-make": "knex migrate:make --knexfile ./src/db/knexfile.ts",
+    "migrate-make": "knex migrate:make --cwd src/db",

Ça marche mais... pourquoi ? Cela ne semble pas la bonne solution car --knexfile censé fonctionner.

@ShGKme voici les modifications nécessaires pour que cela fonctionne : https://github.com/knex/knex/pull/3005

Mais personne ne veut y répondre, puisque cwd fonctionne, je suis assez heureux pour l'accepter.

J'ai passé l'après-midi à étudier cela car je rencontrais un problème d'initialisation étroitement lié. Je pense que l'évaluation de @brunolm est correcte : la méthode Liftoff#launch(..) est invoquée avec les mauvais paramètres. Vous pouvez voir les détails dans #3005

En gros, Liftoff semble se comporter comme suit :

// 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,
  });
}

Puisqu'il y a actuellement un bogue dans la manière dont Liftoff#launch(..) est invoqué, la valeur de configPath est _toujours_ déduite. Par conséquent, Liftoff ne lancera pas les scripts preload appropriés. (Plus précisément : ts-node/register ne se chargera pas)

@briandamaged Pourriez-vous fournir un correctif qui ne briserait pas les tests existants ?

@kibertoad + @brunolm : Je vais essayer de journée ou demain. Je m'assure toujours de comprendre d'abord la situation dans son ensemble. D'après ce que je peux dire, il semble que la CLI Knex duplique certaines des fonctionnalités déjà fournies par la bibliothèque Liftoff .

@briandamaged Peut-être. Tant que les tests cli réussissent afin que nous sachions que nous n'introduisons pas de changements de rupture pour les utilisateurs, n'hésitez pas à refactoriser aussi profondément que nécessaire.

@brunolm @ShGKme @mmiszy @ilkka Cela devrait mieux fonctionner en 0.20.9 grâce au travail incroyable de @briandamaged. Essayez-le et dites-moi si les changements vous ont été utiles.

@kibertoad Tout fonctionne, merci beaucoup

@kibertoad merci beaucoup ! Je peux confirmer qu'il fonctionne à 100 % maintenant !

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 est le vrai héros. Content que ça marche bien maintenant !

J'obtiens toujours cette erreur avec NodeJS 14.0.0, la commande knex migrate:make test et le fichier suivant :

// 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"
    }
  }
};

J'obtiens cette erreur :

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)

EDIT: Cela a été corrigé en ajoutant ts-node en tant que dépendance. Désolé pour le dérangement.