Knex: Knex cli deve suportar es6 para configuração e migrações

Definitivamente, isso seria ótimo. Fico feliz em aceitar um PR para este.

Desculpa. Esse comentário anterior deveria ser para a edição 1220, mas eu coloquei esse comentário por engano aqui.

@ rhys-vdw você sabe de antemão o que seria necessário?

@ rhys-vdw @jmfurlott . Na verdade, estou interessado em pesquisar isso também, pois acho que esse seria um recurso muito bom de se ter. Você acha que pode nos apontar os componentes que devemos explorar para tentar tornar isso uma possibilidade? Alguma ideia ajudaria

Adicionar require("babel-register") ao ponto de entrada CLI pode funcionar.

Confirmado - adicionado isso ao meu arquivo de seed e tinha o ES2015 rodando! Talvez devesse ser uma opção em knexfile.js para definir compiler , como o mocha faz com seu CLI?

Eu finalmente consegui fazer o meu funcionar:

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"]
        }
    }
}

No entanto, eu não posso mudar o caminho da semente, quando eles não estão localizados em ./seeds eu sempre pegarei

No seed files exist

O mesmo também para migrações.

Outra opção é executar o Knex com babel-node , disponível em babel-cli , assim:

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

Você pode querer fazer isso se seu aplicativo importa knexfile.js enquanto já está sendo processado pelo Babel, tornando a opção require('babel-register') inutilizável.

boa ideia @jeremejevs ... com

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

você poderia usar assim

npm run knex migrate:latest

sem ter que criar um script separado para todos os comandos Knex.

@olalonde Sim, isso também funciona! Eu apenas prefiro ter os scripts "db: migrate: make " e "db: migrate: latest " explícitos, caso eu esqueça a formulação exata meio ano depois (foi "make"? Ou "make-migration"? Ou "migrate: make "? or" migrate: new "? or ...) 🙂

@olalonde excelente proposta! Em seguida, você pode usar os scripts npm "composição" como:

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

Talvez isso também possa ajudar: 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

Quando tento a sugestão de @olalonde , npm run knex migrate:make ou npm run knex com quaisquer argumentos adicionais, apenas sai sem exibir nada. Porém, apenas executar npm run knex exibe o uso normalmente. A documentação do npm diz que preciso colocar -- antes dos argumentos de script como npm run knex -- migrate:make , mas isso ainda sai sem saída.

Usando reify (rápido!) Em * nix (nenhuma ideia sobre um sinônimo de alias no Windows, desculpe!)

/*

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

Qualquer tentativa es6ificadora de knexfile.js é feia, mas posso conviver com uma única anomalia usando module.exports

Continue recebendo No knexfile found in this directory. Specify a path with --knexfile com o seguinte:

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

`` `
fio knex migrar: fazer lol
`` ``

Quaisquer dicas? Parece ser apenas um problema de diretório funcional (eu acho) 🤔

@haywirez Tem certeza que isso está relacionado ao tópico deste tíquete? .. De qualquer forma, tente fazer exatamente o que ele está pedindo, adicione --knexfile que apontaria para seu knexfile.js

É possível que o problema de @haywirez 'seja porque export default { ... } precisará ser const file = require('/path/to/knexfile').default para interoperabilidade ESM.

Além disso, Liftoff, conforme usado pelo knex cli, permite um sinalizador --require para exigir algo como esm ou babel-register . Infelizmente, como este comando não está registrado no Commander, o knex cli morre após exigir em esm :

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

  error: unknown option `--require'

O projeto seria aberto a um PR para habilitar --require em todos os comandos, bem como garantir a interoperabilidade em knexfile ?

https://github.com/tgriesser/knex/issues/1232#issuecomment -411775132 também permitiria que você registrasse caminhos tsconfg para nomes de ts-node não planeja oferecer suporte a caminhos de alias, então isso se torna problemático quando estou criando sementes que requerem algumas transformações complexas antes de persistir os dados no banco de dados. Se expormos a sinalização --require , posso contornar isso sozinho.

Como alternativa, se outras pessoas tiverem esse problema, você pode contorná-lo sem a sinalização --require fazendo:

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

@olalonde Isso ainda é relevante em um mundo onde todas as versões populares do Node.js suportam ES6 pronto para uso?

O nó

@mAAdhaTTah É meio que sim: https://nodejs.org/api/esm.html

@kibertoad Sim, mas é muito experimental e instável, então você não pode confiar nele.

Se você estiver usando ESM , no Windows, tente isto:
node -r esm node_modules/knex/bin/cli.js migrate:make migration_name .

No Linux e Mac, tente
node -r esm node_modules/.bin/knex migrate:make migration_name

Portanto, a última atualização que vejo neste tíquete envolve ESM e tem mais de meio ano ... alguém conseguiu fazer isso funcionar com o Babel desde então? Estou particularmente curioso com todas as mudanças no Babel e a aparente nova preferência da biblioteca em usar @ babel / register em vez de babel-node.

@machineghost Você pode tentar o master mais recente, ele não usa nenhuma transpilação, então pode funcionar melhor. Se você encontrar alguma limitação restante, por favor me avise.

Ainda não parece funcionar. Meu package.json é o seguinte:

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

e meu knexfile.js é super simples:

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

Mas não pode passar da primeira linha. Quando executo npm run migrate recebo:

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

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

Tendo descoberto o incrível módulo "esm" (do criador de Lodash), ninguém mais precisa do envolvimento de Babel. Realmente, tudo que o Knex precisa para suportar módulos ES6, com muita facilidade, é apenas uma maneira de passar --require esm para node nos bastidores.

Se a linha de comando knex pudesse simplesmente pegar -r e passá-lo para o Node, isso não apenas resolveria esse tíquete, mas também qualquer outro problema em que alguém precise executar um módulo Node antes de executar o Knex.

-EDITAR-

Até que exista um argumento -r , pode-se usar a sintaxe ES6 em todos os módulos _requiridos_ (mas não no próprio knexfile.js ) fazendo:

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

Isso fará com que require manipule módulos ES6 muito bem ... mas o knexfile.js ainda precisa usar require e module.exports ; uma opção -r resolveria isso.

Caso alguém esteja procurando, aqui está um exemplo completo de como usar ESM para trabalhar com 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"
  }
}

Com o ESM se tornando mais popular, gostaria de fazer alguma contribuição para permitir que o Knex trabalhe com o Node> 12. Tenho um pouco de experiência em trabalhar com ESM no Node, então espero que tudo corra bem. Infelizmente, não posso dizer quando poderei começar com isso, pois não posso trabalhar nisso durante o expediente (não relacionado aos negócios). Também vou demorar um minuto para me acostumar com a base de código knex

Acho que pode ser tão simples quanto adicionar require('esm') como a nova linha um ... se os autores da biblioteca concordarem com a nova dependência.

@jhechtf @machineghost Verifique isto:
https://github.com/knex/knex/pull/3616
https://github.com/knex/knex/pull/3639
https://github.com/knex/knex/pull/3638

O suporte ao Liftoff também foi corrigido, portanto, antes de fazer mais alterações, seria útil escrever alguns testes para descobrir o que funciona e o que não funciona agora.
Dito isso, se alguém investigar tudo isso e decidir qual trabalho (se houver) ainda é necessário e contribuir com alguns testes, isso seria muito útil.

Sim, vocês escolheram a solução Node oficial, que ainda não está totalmente pronta.

IMHO, a solução do módulo "esm" é muito mais simples e não exigiria nenhum sinalizador especial: apenas tornaria a biblioteca do Módulo ES amigável para todos, em todos os arredores do Node (muito provavelmente com uma única linha de requerimento, como eu disse) .

É do cara que fez Lodash; JDD é demais.

@machineghost https://github.com/knex/knex/pull/3639 usa babel, então é uma outra maneira. Acho que vi alguém tentando a abordagem do módulo esm , mas por algum motivo não consigo encontrar o PR agora.

Bem, FWIW essa biblioteca é minha fonte mais rápida de pontos Stack Overflow;)

Eu descobri e recomendei a outras pessoas aqui: https://stackoverflow.com/questions/47277887/node-experimental-modules-requested-module-does-not-provide-an-export-named/54302557#54302557

e agora recebo um novo voto positivo a cada poucos dias porque é realmente uma ótima (indiscutivelmente a melhor , no momento) solução para ESM.

@machineghost Quão intrusivo você esperaria que sua introdução fosse baseada na base de código existente?

Eu acho que este é um desses acordos "não deve ter nenhum efeito, mas uma vez que afeta tudo, você tem que testar para ter certeza".

Não olhei seus internos, mas dado o perfil deste projeto na comunidade, talvez se alguém perguntasse a @jdalton ele pudesse avaliar os riscos (com uma opinião muito mais informada que a minha?): Cross_fingers:

@machineghost Você pode dar uma olhada em https://github.com/knex/knex/pull/3616 para ver qual foi o impacto da implementação original. Provavelmente, isso teria que ser removido ou substituído se esm fosse introduzido.

Não tenho ATM com largura de banda, mas vou dar uma olhada quando tiver tempo. Talvez @jhechtf consiga fazer isso antes?

Sim, vocês escolheram a solução Node oficial, que ainda não está totalmente pronta.

@machineghost : Hmm ... acredito que a sinalização --esm está realmente usando o módulo esm que você mencionou:

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

Em uma nota relacionada: você acabou de me lembrar que eu pretendia consertar o sinalizador --require depois que as melhorias de Liftoff tivessem sido mescladas. Eu deveria ir fazer isso agora ...

Oh, minhas desculpas! Eu estava digitalizando muito rápido, vi " node ${KNEX} --esm " e apenas olhei além da variável lá e pensei que você estava passando um arg para o Node diretamente para dizer a ele para usar a versão do Node.

Parece que isso já foi resolvido e isso simplesmente não ficou claro no tópico do problema; bom trabalho: +1:

np! Parece que o recurso foi adicionado por @ D10221 neste PR:

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

Então, eles merecem o crédito 🎉