Knex: Knex cli devrait prendre en charge es6 pour la configuration et les migrations

Ce serait certainement génial. Heureux d'accepter un PR pour celui-ci.

Désolé. Ce commentaire précédent était censé concerner le numéro 1220, mais je l'ai mis par erreur ici.

@rhys-vdw savez-vous d'emblée ce qu'il faudrait ?

@rhys-vdw @jmfurlott . En fait, je suis également intéressé à poursuivre cela car je trouve que ce serait une fonctionnalité vraiment cool à avoir. Pensez-vous que vous pouvez nous indiquer les composants que nous devrions explorer pour essayer de rendre cela possible. Un peu de perspicacité aiderait

L'ajout de require("babel-register") au point d'entrée CLI pourrait bien fonctionner.

Confirmé - j'ai ajouté cela à mon fichier de départ et j'avais ES2015 en cours d'exécution ! Peut-être devrait-il y avoir une option dans knexfile.js pour définir compiler , comme le fait mocha avec leur CLI ?

J'ai enfin réussi à faire fonctionner le mien :

db.config.js

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

knexfile.js

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

module.exports = config

.babelrc

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

Cependant, je ne peux pas changer le chemin des graines, quand ils ne sont pas situés dans ./seeds, j'obtiendrai toujours

No seed files exist

Idem aussi pour les migrations..

Une autre option consiste à exécuter Knex avec babel-node , disponible en babel-cli , comme ceci :

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

Vous voudrez peut-être le faire si votre application importe knexfile.js alors qu'elle est déjà traitée par Babel, rendant l'option require('babel-register') inutilisable.

@jeremejevs bonne idée... avec

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

vous pouvez l'utiliser de cette façon

npm run knex migrate:latest

sans avoir à créer un script séparé pour toutes les commandes Knex.

@olalonde Ouais , ça marche aussi ! Je préfère simplement avoir des scripts explicites "db: migrate:make " et "db: migrate:latest " au cas où j'oublierais le libellé exact six mois plus tard (était-ce "make" ? ou "make-migration" ? ou "migrate: make"? ou "migrate:new"? ou...) 🙂

@olalonde excellente proposition ! Ensuite, vous pouvez utiliser les scripts npm "composition" comme :

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

Peut-être que cela pourrait également aider : https://github.com/standard-things/esm

OS : Windows
[email protected]
[email protected]

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

export function down(knex) {
  return knex.schema
    .dropTable('contacts')
}

$ npx knex migrate:latest
Using environment: development
migrations/contacts.js:1
(function (exports, require, module, __filename, __dirname) { export function up (knex) {
                                                              ^^^^^^
SyntaxError: Unexpected token export
    at Object.exports.runInThisContext (vm.js:73:16)
    at Module._compile (module.js:543:28)
    ...

$ npx babel-node node_modules/.bin/knex migrate:latest
./node_modules/.bin/knex:2
basedir=$(dirname "$(echo "$0" | sed -e 's,\\,/,g')")
          ^^^^^^^
SyntaxError: missing ) after argument list
    at Object.exports.runInThisContext (vm.js:73:16)
    at Module._compile (module.js:543:28)
    ...

$ npx babel-node node_modules/knex/bin/cli.js migrate:latest
Using environment: development
Batch 1 run: 1 migrations
migrations/contacts.js

Lorsque j'essaie la suggestion de @olalonde , npm run knex migrate:make , ou npm run knex avec des arguments supplémentaires, quitte simplement sans rien afficher. Le simple fait d'exécuter npm run knex affiche l'utilisation comme d'habitude. npm docs dit que je dois mettre -- avant les arguments de script comme npm run knex -- migrate:make , mais cela se termine toujours sans sortie.

Utilisation de reify (rapide !) sur *nix (aucune idée d'un synonyme d'alias sur windows, désolé !)

/*

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

  knex migrate:latest # …etc

*/

const table = 'foo';

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

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

// OR

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

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

Toutes les tentatives d'es6ifying knexfile.js sont laides mais je peux vivre avec une seule anomalie en utilisant module.exports

Continuez à obtenir No knexfile found in this directory. Specify a path with --knexfile avec les éléments suivants :

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

export default {
  debug: false,
  settings: config.get('dbConfig'),
  seeds: {
    directory: './seeds/'
  }
}

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

```
fil knex migrer:faire lol
````

Des pointeurs? Semble être juste un problème de répertoire de travail (je suppose)

@haywirez Êtes-vous sûr que cela est lié au sujet de ce ticket? .. Quoi qu'il en soit, essayez de faire exactement ce qu'il demande, ajoutez --knexfile qui pointerait vers votre knexfile.js

Il est possible que le problème de export default { ... } devra être const file = require('/path/to/knexfile').default pour l'interopérabilité ESM.

De plus, Liftoff, tel qu'il est utilisé par le knex cli, permet un indicateur --require pour exiger quelque chose comme esm ou babel-register . Malheureusement, parce que cette commande n'est pas enregistrée dans Commander, le cli knex meurt après avoir demandé dans esm :

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

  error: unknown option `--require'

Le projet serait-il ouvert à un PR pour activer --require sur toutes les commandes ainsi que pour assurer l'interopérabilité sur le knexfile ?

https://github.com/tgriesser/knex/issues/1232#issuecomment -411775132 vous permettrait également d'enregistrer tsconfg-paths pour les noms de chemin d'alias, ce qui est utile lors de la création de graines avec un script dactylographié. ts-node ne prévoit pas de prendre en charge les chemins d'alias , cela devient donc problématique lorsque je crée des graines qui nécessitent des transformations complexes avant de conserver les données dans la base de données. Si nous exposons le drapeau --require , je peux contourner ce problème moi-même.

Alternativement, si d'autres rencontrent ce problème, vous pouvez le contourner sans l'indicateur --require en faisant :

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

@olalonde Est-ce toujours d'actualité dans un monde où toutes les versions populaires de Node.js prennent en charge ES6 prête à l'emploi ?

@kibertoad Node ne prend pas encore en charge ESModules.

@mAAdhaTTah C'est en quelque https://nodejs.org/api/esm.html

@kibertoad Oui, mais c'est très expérimental et instable, vous ne pouvez donc pas vous y fier.

Si vous utilisez esm , sous Windows, essayez ceci :
node -r esm node_modules/knex/bin/cli.js migrate:make migration_name .

Sous Linux et Mac, essayez
node -r esm node_modules/.bin/knex migrate:make migration_name

Donc, la dernière mise à jour que je vois sur ce ticket concerne esm et date de plus de six mois… est-ce que quelqu'un a réussi à faire fonctionner ça avec Babel depuis ? Je suis particulièrement curieux de tous les changements apportés à Babel et de la nouvelle préférence apparente de la bibliothèque pour l'utilisation de @babel/register au lieu de babel-node.

@machineghost Vous pouvez essayer le dernier maître, il n'utilise aucune transpilation, il pourrait donc mieux fonctionner. Si vous rencontrez des limitations restantes, veuillez me le faire savoir.

Cela ne semble toujours pas fonctionner. Mon package.json est le suivant :

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

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

et mon knexfile.js est super simple :

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

Mais il ne peut pas dépasser la première ligne. Lorsque je lance npm run migrate j'obtiens :

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

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

Ayant découvert l' incroyable module "esm" (du créateur de Lodash), on n'a même plus besoin de Babel pour s'impliquer. Vraiment, tout ce dont Knex a besoin pour prendre en charge les modules ES6, très facilement, est juste un moyen de passer --require esm à node dans les coulisses.

Si la ligne de commande knex pouvait simplement prendre -r et le transmettre à Node, cela résoudrait non seulement ce ticket mais également tout autre problème où quelqu'un doit exécuter un module Node avant d'exécuter Knex.

-ÉDITER-

Jusqu'à ce qu'un argument -r existe, on peut utiliser la syntaxe ES6 dans tous les modules _required_ (mais pas dans knexfile.js lui-même) en faisant :

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

Cela permettra à require gérer lui-même les modules ES6 correctement ... mais le knexfile.js doit toujours utiliser require et module.exports ; une option -r résoudrait cela.

Au cas où quelqu'un chercherait, voici un exemple complet sur la façon d'utiliser esm pour travailler avec knex

knexfile.js

const config = {
}

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

package.json

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

L'ESM devenant de plus en plus populaire, je serais prêt à envisager d'apporter une contribution pour permettre à Knex de fonctionner avec Node >12. J'ai un peu d'expérience de travail avec ESM dans Node, donc j'espère que cela se passera bien. Malheureusement, je ne peux pas vous dire quand je pourrais commencer car je ne peux pas y travailler pendant les heures de travail (non liées aux affaires). Il va aussi me falloir une minute pour m'habituer à la base de code knex

Je pense que cela pourrait être aussi simple que d'ajouter require('esm') tant que nouvelle ligne ... si les auteurs de la bibliothèque sont d'accord avec la nouvelle dépendance.

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

La prise en charge de Liftoff a également été corrigée, donc avant de faire plus de changements, il serait utile d'écrire quelques tests pour déterminer ce qui fonctionne et ce qui ne fonctionne pas maintenant.
Cela dit, si quelqu'un enquête sur tout cela et décide quel travail (le cas échéant) est encore nécessaire et contribue à quelques tests, ce serait très utile.

Oui, vous avez opté pour la solution officielle de Node, qui n'est pas encore complètement prête.

À mon humble avis, la solution du module "esm" est beaucoup plus simple et ne nécessiterait aucun indicateur spécial: cela rendrait simplement le module ES de la bibliothèque convivial pour tout le monde, dans tous les environnements Node (très probablement avec une seule ligne requise, comme je l'ai dit) .

C'est du gars qui a fait Lodash ; JDD déchire.

@machineghost https://github.com/knex/knex/pull/3639 utilise babel, c'est donc une autre façon. Je pense avoir vu quelqu'un essayer l'approche du module esm , mais pour une raison quelconque, je ne trouve pas le PR maintenant.

Eh bien, FWIW cette bibliothèque est ma source actuelle de points de débordement de pile la plus rapide ;)

Je l'ai découvert et recommandé à d'autres ici : https://stackoverflow.com/questions/47277887/node-experimental-modules-requested-module-does-not-provide-an-export-named/54302557#54302557

et maintenant, je reçois un nouveau vote tous les quelques jours car c'est vraiment une excellente (sans doute la meilleure , en ce moment) solution pour ESM.

@machineghost Dans

Je pense que c'est l'un de ces "ça ne devrait avoir aucun effet, mais comme cela affecte tout, vous devez tester pour être sûr".

Je n'ai pas regardé ses internes, mais étant donné le profil de ce projet dans la communauté, peut-être que si quelqu'un demandait à @jdalton, il pourrait peser sur les risques (avec un avis beaucoup plus éclairé que le mien ?) :crossed_fingers:

@machineghost Vous pouvez consulter https://github.com/knex/knex/pull/3616 pour voir quel a été l'impact de la mise en œuvre d'origine. Cela devrait probablement être supprimé ou remplacé si esm est introduit.

Je n'ai pas de bande passante ATM, mais je regarderai quand j'aurai le temps. Peut-être que @jhechtf pourrait le faire plus tôt ?

Oui, vous avez opté pour la solution officielle de Node, qui n'est pas encore complètement prête.

@machineghost : Hmm... Je crois que le drapeau --esm utilise en fait le module esm vous avez mentionné :

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

Sur une note connexe: vous venez de me rappeler que je voulais corriger le drapeau --require après la fusion des améliorations Liftoff . Je devrais aller le faire maintenant...

Oh, mes excuses ! Je scannais trop rapidement, j'ai vu " node ${KNEX} --esm ", et j'ai juste regardé au-delà de la variable là-bas et j'ai pensé que vous passiez un argument directement à Node pour lui dire d'utiliser la version de Node.

Il semble que cela ait déjà été résolu, et ce n'était tout simplement pas clair dans le fil de discussion; beau boulot :+1:

np ! Il semble que la fonctionnalité ait été ajoutée par @ D10221 dans ce PR :

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

Alors, ils méritent le crédit 🎉