Jest: Considere adicionar suporte nativo para módulos ES

Jest tem sua própria implementação require (https://github.com/facebook/jest/blob/master/packages/jest-runtime/src/index.js), então seria muito mais envolvente do que apenas suportando a sintaxe e o padrão para olhar para .mjs . Também sou contra a ativação de sinalizadores experimentais.

Pode ser possível transpilar import / export automaticamente, mas implementar a semântica é uma tarefa enorme e provavelmente bloqueada por um ano por causa do suporte para o nó 6.

Eu concordo com SimenB. Precisamos de vários ganchos da equipe do nó para poder fazer isso funcionar junto com o módulo vm. No entanto, acho que devemos dar suporte a isso enquanto isso, mas não espelhando a implementação nativa completa, mas usando o babel e compilando-o para exigir dentro de babel-jest . Acho que para fins de teste isso funcionará bem e não temos que fornecer as mesmas garantias que o tempo de execução do nó precisa fornecer de qualquer maneira.

Então, apenas adicionando babel-plugin-transform-es2015-modules-commonjs & babel-plugin-dynamic-import-node a babel-jest ?

Sim, era isso que eu estava pensando.

Pessoal, que tal integrar https://github.com/standard-things/esm ? É rápido e mantém muitos casos extremos.

@ TrySound, como seria isso concretamente? Você pode fazer um protótipo?

Ainda temos nossa própria implementação de requerimento (necessária para simulações), então não acho que isso ajudaria muito.

E precisamos trabalhar tanto com as regras do Node quanto com as regras do navegador.

Ficaria muito feliz se fosse corrigido e funcionasse perfeitamente para nós: D

@std/esm aparentemente deve funcionar apenas com jest: https://twitter.com/jdalton/status/930257653292400640

Alguém poderia dar uma olhada e voltar com um PR para os documentos? 🙂

Acho que os usuários gostariam de ter suporte em todos os lugares, mas descobri que funciona apenas para dependências de arquivos de teste.

// test.js
require = require('@std/esm')(module, { esm: 'js', cjs: true });
const utils = require('./utils');

// utils.js
export { default as update } from './update';

É melhor, mas não é o ideal.

https://github.com/tarunlalwani/jest-overriding-require-function-stackoverflow

Então, apenas adicionar babel-plugin-transform-es2015-modules-commonjs & babel-plugin-dynamic-import-node ao babel-jest?

Não acho que seja uma ótima solução, já que não executa nenhuma verificação de "exportação ausente" tão valiosa com os módulos ES. Por exemplo, no React repo, comecei a executar o build com mais frequência só porque o Rollup encontra esses erros, mas o Jest com es2015-modules-commonjs não.

@ std / esm aparentemente deve funcionar apenas com piada

Seria muito bom investir algum tempo em sua interoperabilidade. Tenho certeza de que essa solução hacky acabará quebrando: https://stackoverflow.com/questions/46433678/specify-code-to-run-before-any-jest-setup-happens. Mas se é só uma questão de expor algo do lado de Jest, seria legal ver que tem suporte.

@SimenB , na minha opinião, o passo imediato não seria muito complexo. O que é urgente é permitir que as pessoas trabalhem com o módulo .mjs, mesmo que o babel esteja ajudando nos bastidores. Caso contrário, as pessoas podem ter que encontrar uma solução de teste diferente se quiserem usar .mjs.

1. Corrija a propriedade testMatch para permitir que o arquivo .mjs seja encontrado
   (atualmente não funciona, mesmo o regex parece já estar correto, talvez haja um código rígido em algum lugar rejeitando a extensão .mjs)
2. Passe a sinalização --experimental-modules ao executar node.js para que seja executado nativamente
3. Jest deve tratar .mjs exatamente da mesma maneira que .js hoje (por exemplo, in jest require) - as instruções de importação já são permitidas dentro de .js hoje, então só precisa permitir a extensão .mjs.

A solução final pode ser complexa e demorada, mas é inevitável, não é?

Olá, alguém conseguiu consertar este erro?

Estamos usando .mjs com a opção "node --experimental-modules". Qualquer solução alternativa?

Estamos usando .mjs com a opção "node --experimental-modules". Qualquer solução alternativa?

Isso é experimental e não totalmente desenvolvido. Ainda há muita agitação com coisas básicas, como importar um módulo embutido, ainda no ar. Projetos como AVA começaram a permitir o uso de @std/esm como seu pipeline de carregamento, se usado (ignorando Babel). Talvez jest pudesse adotar uma abordagem semelhante.

Apoiar @std/esm é algo que queremos fazer, ajudar a implementá-lo é mais que bem-vindo!

@SimenB Você pode

Olá @SimenB 👋

Um usuário esm contribuiu com esm + Jest demo e achei que pode ser um bom ponto de partida para a criação de um caminho de vaca mais oficial.

Atualizar:

A demonstração de esm + Jest foi atualizada com suporte para mapeamento de nome de módulo básico.

Isso é bem legal! Obrigado por compartilhar.

Teremos que descobrir onde queremos que a integração esteja. Como ele lidaria com arquivos CSS (ou outros ativos não JS)? Deve ser apenas uma transformação? E quanto à transformação babel embutida? Como Jest deve se comportar quando se trata dos carregadores de entrada, se isso afeta alguma coisa?

Parece que pode haver um benefício para uma comunidade contrib esm -enabled jest runner alternativo (ou um sinalizador não oficial / experimental) para que possamos fazer progresso em algo assim. Haveria interesse nisso da equipe de piadas?

require não é implementado em um runner, ele está no próprio tempo de execução. Quaisquer contribuições para torná-lo plugável são muito bem-vindas (ref # 848).

Tenho certeza de que se você conseguir fazer com que o código de exemplo @jdalton vinculado funcione sem problemas (ou perto disso), ele deve ser simples o suficiente para carregar no carregador esm atrás de um sinalizador em si. Uma coisa que vejo como um problema é que ele quer o real module global, não o falso que criamos. Não tem certeza se isso significa que os módulos podem vazar entre os testes? Não sei o que o ESM faz com ele sob o capô. Ele também não lida com simulações, então simulações com import ainda estariam quebrando

Pode ser necessário apenas alguns ajustes de como Jest se adapta ao CJS. Por exemplo, ao simular o objeto module , em vez de usar um objeto simples, ele poderia usar require("module") e, em seguida, empacotar / sobrescrever module.require para interceptar solicitações e fazer malabarismos conforme necessário.

Atualizar:

Agora estou trabalhando para habilitar o Jest pronto para uso com esm (com sorte, nada que Jest tenha que fazer diferente) . Vou continuar a experimentar durante o fim de semana, mas os primeiros sinais parecem bons.

@jdalton Alguma atualização com a compatibilidade esm ?

Olá @JasonCust , uau, meu comentário chamou a atenção!

Fiz progresso na identificação do trabalho necessário para habilitar o suporte do Jest em esm . Em meus experimentos, recebi Jest carregando e avaliando testes escritos em ESM. O trabalho necessário no lado do carregador de esm é tornar a maneira como lidamos com vm.Script mais genérica. No momento, conectamos isso principalmente para uso REPL, que assume um único módulo. Temos que tornar isso um pouco mais genérico para que o suporte do Jest funcione. Não parece que Jest terá que mudar nada. O refator de nosso suporte vm.Script ainda está em meu TODO e ainda será resolvido antes de eu lançar coisas como suporte experimental WASM. No momento, estou eliminando bugs que surgiram em torno do APM aprimorado e do suporte a mocking.

Obrigado pela atualização @jdalton, pois estou animado em poder usar esm com Jest. Para não incomodá-lo enquanto estiver trabalhando nessas coisas, existe uma tarefa para esm que possamos acompanhar com o progresso?

Você pode continuar inscrito neste tópico de follow the repo. O suporte do Jest estará na versão v3.1.0, então você pode ficar atento a essa versão.

@jdalton Alguma notícia sobre apoiar Jest na ESM?

Olá @deepj!

Ainda está na minha lista e os itens que posso resolver antes de fazer isso estão diminuindo. Eu tenho aprimorado o suporte suplementar do Jest para testar módulos esm dentro do Jest _ (embora o CJS dentro dos testes do Jest) _. Ainda não há nada bloqueando criticamente a implementação do lado de Jest _ (então não há trabalho para eles fazerem) _. A Microsoft, meu empregador, também é um grande usuário do Jest, então um dos meus objetivos do dia-a-dia é melhorar isso também. Espero resolver isso em breve.

@jdalton Bom saber. E obrigado pelo seu trabalho. Eu agradeço!

Estou ansioso por este recurso: speak_no_evil:

Tenho tentado fazer esse recurso funcionar nas últimas duas horas. Existem tantas soluções parciais, respostas meio documentadas, todas diferentes umas das outras ... Costumava ser fácil testar pacotes node.js.

Então, apenas adicionando babel-plugin-transform-es2015-modules-commonjs & babel-plugin-dynamic-import-node a babel-jest ?

O que aconteceu com essa ideia? Algum problema em implementá-lo?

Olá, @jdalton. Gostaria de saber se você poderia nos manter atualizados sobre o status desse problema. Desculpe se estou incomodando, mas estou esperando por isso por um tempo, e seria melhor se recebermos uma atualização pelo menos para os últimos / próximos seis meses. Obrigado :)

Olá, @ SurenAt93!

Obrigado pela sua paciência. Espero lançar um lançamento no final do mês com o apoio do Jest. Com isso, você especificará esm como uma transformação Jest.

Legal. Como essa transformação é diferente de Babel?

@kenotron

Usar a opção transform Jest é uma maneira de eu carregar o carregador esm . Portanto, embora também esteja tecnicamente transformando a fonte, também está conectando o carregador esm .

Se a questão for mais, qual é a diferença entre Babel e esm . Babel é uma coleção de pacotes que transforma a origem, um dos destinos pode ser a sintaxe ESM. O carregador esm é um carregador de dependência zero que simula o ambiente de execução. Portanto, esm suporta coisas como import() dinâmicos, passa especificações test262 relevantes (zonas mortas temporais, ligações

@jdalton Obrigado pelo seu trabalho e apoio!

@tomheller ;)

Tenho tentado fazer esse recurso funcionar nas últimas duas horas. Existem tantas soluções parciais, respostas meio documentadas, todas diferentes umas das outras ... Costumava ser fácil testar pacotes node.js.

Eu concordo.

Eu criei um projeto Vue simples, que também manifesta o problema.
https://github.com/igasparetto/vue-jest-test
Eu não fui capaz de fazer funcionar.

Eu segui as instruções das seguintes páginas:

• https://vuejs.org/v2/guide/unit-testing.html
• https://medium.com/@kevin_peters/unit -testing-vue-js-components-with-jest-86e14ef499da
• Consulte este tópico: https://github.com/vuejs/vue-cli/issues/1584

Minha máquina (não tenho certeza se deve importar):

• Windows 10 Pro 64 bits
• Node v8.9.4
• Vue: 3.2.3
• npm: 6.5.0

@kenotron

Usar a opção transform Jest é uma maneira de eu carregar o carregador esm . Portanto, embora também esteja tecnicamente transformando a fonte, também está conectando o carregador esm .

Se a questão for mais, qual é a diferença entre Babel e esm . Babel é uma coleção de pacotes que transforma a origem, um dos destinos pode ser a sintaxe ESM. O carregador esm é um carregador de dependência zero que simula o ambiente de execução. Portanto, esm suporta coisas como import() dinâmicos, passa especificações test262 relevantes (zonas mortas temporais, ligações

@kenotron você poderia nos fornecer uma atualização, por favor?

@igasparetto , é o trabalho de

O último status lá, eu acho: https://twitter.com/jdalton/status/1080627279124934661

Sim! Desculpe, está demorando mais do que eu queria. Agora, localmente, todos os testes test262 relevantes estão passando. No decorrer da preparação, os testes de cenário relacionado à simulação falharam, então eu tenho que pegá-los de volta antes de poder liberá-los. Não é intransponível, apenas leva um pouco de tempo. Estou me apresentando na Covalence Conf em 16 de janeiro e espero ter um lançamento até então. Em outras notícias, o npm tink adotou antecipadamente

16 de janeiro e espero ter um lançamento até então

@jdalton Espero que a apresentação tenha

Você tem uma atualização sobre este lançamento, por favor?

@igasparetto Está em https://github.com/standard-things/esm/issues/97#issuecomment -454985896 e em https://github.com/standard-things/esm/issues/706 ☺️

Estou deixando um pequeno "ponto de dados" aqui para ajudá-lo no seu planejamento. Sei que todos vocês estão doando seu tempo e habilidades para resolver esse problema. Como desenvolvedor, agradeço sua contribuição.

Passei a maior parte do dia de ontem, não menos do que um sábado, para me atualizar sobre os módulos javascript no lado do cliente e do servidor. ESM, CommonJS, AMD, que bagunça confusa. Nunca consegui fazer um teste de brincadeira para trabalhar com o ESM carregando um módulo (nó) usando uma extensão .mjs. Eu poderia carregar o mesmo módulo do lado do cliente com sucesso. Eu poderia criar um nó "cliente" que usasse o módulo com uma instrução de importação. Não consegui configurar o jest corretamente para consumir a mesma instrução de importação, com ou sem babel, com ou sem esm. Eu finalmente mudei para o ava e comecei a trabalhar seguindo uma receita em seu site. Sim, segui uma receita, não entendo bem a maquinaria que fazia funcionar todas as peças. Mas pelo menos agora posso escrever ESM carregando módulos javascript e testes de unidade associados. Eu penso. Estou extrapolando com base em um único sucesso. Eles também têm uma receita para conectar o ava ao webstorm. Mas pelo menos eles estão apresentando receitas para meros mortais como eu.

Também percebo que esta mensagem será lida como se eu estivesse choramingando (o que em parte estou). Eu vejo todo o trabalho que virou piada. Mas essa coisa de suporte ESM é um assassino e um quebrador de negócios para mim. Achei que você gostaria de receber algum feedback, mas se não, ignore ou peça-me para excluí-lo e eu o farei.

Alguma novidade em relação ao suporte aos

@dandv Tenho feito algumas investigações para vm.SourceTextModule , que requer que alguns sinalizadores CLI sejam passados ​​para node :

--experimental-modules --es-module-specifier-resolution=node --experimental-vm-modules

A API também é de nível super baixo.

TBD.

Discussão em https://github.com/nodejs/node/issues/27387

Atualização: foi dito para esperar até que o design do carregador de módulo do Node seja bloqueado. Enquanto isso, standard-things / esm # 706 pode ser a melhor aposta.

jest é uma biblioteca de testes muito boa. suporte para ESM realmente tudo o que precisa para ser completo!

Atualização: foi dito para esperar até que o design do carregador de módulo do Node seja bloqueado. Enquanto isso, standard-things / esm # 706 pode ser a melhor aposta.

isso não funciona com piada, infelizmente.

@jdalton Estamos usando lodash-es , que é a versão ES Module Exports do lodash. Nosso projeto é um projeto Angular v7, que usa o Webpack v4 sob o capô como seu empacotador. Para quem não sabe, lodash-es pode ser

Infelizmente, isso está nos causando problemas, visto que Jest ainda não tem suporte para o Módulo ES. Esperamos que esse recurso faça parte do Jest em breve. Por acaso, alguém saberia como fazer as lodash-es trabalharem com Jest?

Jest falha com a mensagem de erro:

node_modules\lodash-es\lodash.js:10
    export { default as add } from './add.js';
    ^^^^^^

    SyntaxError: Unexpected token export

Nosso jest.config.js

Também estamos usando o pacote npm

module.exports = {
  testMatch: ['**/+(*.)+(spec|test).+(ts|js)?(x)'],
  transform: {
    '^.+\\.(ts|js|html)$': 'ts-jest'
  },
  resolver: '@nrwl/builders/plugins/jest/resolver',
  moduleFileExtensions: ['ts', 'js', 'html'],
  collectCoverage: true,
  coverageReporters: ['html']
};

Infelizmente, isso está nos causando problemas, visto que Jest ainda não tem suporte para o Módulo ES. Esperamos que esse recurso faça parte do Jest em breve. Por acaso, alguém saberia como fazer as lodash-es trabalharem com Jest?

Diga a Jest para não ignorar os lodash-es ao transformar:

  "transformIgnorePatterns": [
    "[/\\\\]node_modules[/\\\\](?!lodash-es/).+\\.js$"
  ],

https://www.npmjs.com/package/jest-esnext

https://github.com/haraldrudell/ECMAScript2049/tree/master/packages/jest-esnext

@haraldrudell pela instrução não está claro como usar o pacote, ele diz: crie um arquivo próximo ao package.json chamado jest.config.js content module.exports = require('jest-esnext') , mas e se eu já tiver uma configuração? Como integrar?

este é o arquivo usado

https://github.com/haraldrudell/ECMAScript2049/blob/master/packages/jest-esnext/config/jest.config.js

você pode substituir o conteúdo de _default pelo de seu jest.config.js

Oi, pessoal,
Nodo 12.13.0 LTS finalmente lançado ... alguma notícia sobre esse assunto?

@ mtsmachado8 Receio que ainda

https://nodejs.org/api/esm.html

Para ESM não sinalizado, este PR está em vigor
https://github.com/nodejs/node/pull/29866

@azder @haraldrudell então basicamente em sua solução você faz a transformação Babel para todos os arquivos JS, incluindo aqueles em node_modules ?

No meu caso, tive que usar sua predefinição diretamente porque não descobri como configurar o transformador assim:

const babelPreset7Esnext = require('babel-preset-7-esnext');
const babelJest = require('babel-jest');

module.exports = babelJest.createTransformer(
    babelPreset7Esnext(undefined, {decorators: {legacy: true}})
);

Node agora tem suporte a módulo alternado por padrão

https://github.com/nodejs/node/pull/29866

Suporte padrão para Módulos ECMAScript desembarcado em 13.2.0

https://github.com/nodejs/node/blob/master/doc/changelogs/CHANGELOG_V13.md#13.2.0

Não trabalharemos nisso até que os carregadores estejam disponíveis. Sem eles, o Node não tem os ganchos de que Jest precisa para fornecer o suporte adequado. Consulte https://medium.com/@nodejs/announcing -core-node-js-support-for-ecmascript-modules-c5d6dc29b663 (não consigo vincular diretamente à seção, mas é o "Trabalho em andamento" no fundo)

Para quem usa módulos nativos e quer usar jest .
Enquanto você trabalha nisso, sugiro uma solução rápida para o node v. 13.2.0:
babel-plugin-transform-default-import
Uso (em _package.json_):

{
  "babel": {
    "presets": [
      [
        "@babel/preset-env",
        {
          "targets": {
            "node": "current"
          }
        }
      ]
    ],
    "plugins": ["transform-default-import"]
  },
}

As bibliotecas precisam instalar:
npm i --save-dev @babel/core @babel/preset-env babel-plugin-transform-default-import

Nota: você não precisa usar babel-plugin-transform-default-import se não tiver libs que tenham o babel chamado export (ou não o usar)

@infodusha Awesome :). Obrigado por isso.

No meu projeto funciona sem os plug-ins:

npm i --save-dev @babel/preset-env

babel.config.js (este tinha que ser nomeado assim, não .babelrc ):

module.exports = {
    presets: [
        [
            '@babel/preset-env',
            {
                targets: {
                    node: '13.2',
                },
                modules: 'commonjs',
            },
        ],
    ],

    plugins: [],
};

o truque é separar os arquivos em diretórios e usar os package.json apropriados neles:

em test dir, eu usei

{
  "type": "commonjs"
}

enquanto em src dir:

{
  "type": "module"
}

@azder Mas se você importar um pacote que fornece commonjs named import em módulos nativos, você precisa importá-lo com a importação padrão e no babel você precisa usar a importação nomeada. Provavelmente, você não tem pacotes como esse, ou pacotes que fornecem exportação es6, mas nem todos os pacotes estão prontos para fazer isso amanhã

@infodusha Provavelmente não tenho o que agora? Você tentou o que escrevi e encontrou problemas com isso ou apenas presume que tenho problemas para usá-lo?

Forneça um exemplo real, uma vez que não estou certo do que você quer dizer com "pacote de importação que fornece commonjs chamados import em módulos nativos".

Até agora, não tive problemas para gravar todos os arquivos com .js extensão de arquivo onde no diretório ./src estão "type":"module" e no diretório "type":"commonjs" ./test "type":"commonjs" com este:

const imported = require('../src/module.js').default;
const {anotherOne} = require('../src/module.js');

Isso porque Jest silenciosamente transpila os Módulos ES para o código CommonJS .

Isso é o que eu acho que deveria testar os Módulos ES nativamente:

(async () => {
    const [
        { default: imported },
        { anotherOne },
    ] = await Promise.all([
        import('../src/some-module.js'),
        import('../src/another-module.js'),
    ]);

    // Rest of your test goes here.
})();

@azder, essas são soluções alternativas.

Faça um diretório mymodule com package.son type=module e dois arquivos nele: first.js e second.js .
Em seguida, tente import { first } from "mymodule";

Você precisa do campo exports no json para usar o Node ESM, e nenhum pacote hoje em dia o tem (ou seja: lodash).

Seu exemplo pode parecer funcionar, mas ele quebra assim que some-module.js ou another-module.js tenta import um módulo nomeado: eles vão quebrar em cascata.

@damianobarbati You _ NEED _ "type": "module" in package.json , sem ele, todos os .js arquivos em seu módulo serão carregados como CommonJS .

exports é usado apenas para limitar o que é exposto a consumidores externos e para exportações condicionais , não tem absolutamente nenhum efeito se .js arquivos serão analisados ​​como CommonJS ou ESM .

@damianobarbati você está errado, pelo que @ Exe-Boss disse, aliás,

Isso porque Jest silenciosamente transpila os Módulos ES para o código CommonJS.

Sim, confio nas peculiaridades de Jest, essa é a razão pela qual estava usando babel.config.js sem nem mesmo adicionar babel a devDependencies

@damianobarbati

Observe, eu tenho um projeto de trabalho, nele estou usando Jest transpilado, enquanto o diretório src tem o tipo de módulo, observe, ./src não a raiz onde está o arquivo de configuração do babel (aquele é CJS devido a peculiaridades).

Além disso, você está certo, pois eu não importo nada do NPM que seja CJS, pois não acho que o NPM (ou os autores do pacote) estejam prontos para misturar e combinar.

O objetivo do meu projeto é ter apenas ESM (para reduzir a gordura das ferramentas), então Jest é a única exceção que é transpilada por conta própria.

@azder algo assim? https://github.com/damianobarbati/node-jest/tree/feature/azder-test

@damianobarbati

Algo assim, aqui está o projeto https://github.com/azder/clip . Observe que não há "dependências" em meu package.json acordo com a última frase do trecho da postagem do blog, decidi não misturar os módulos ESM e CJS do NPM.

Desta forma, para as necessidades do Jest, ele transpila o que requer dos meus módulos ESM, mas talvez mais configuração do babel seja necessária para lidar com o diretório node_modules .

https://medium.com/@nodejs/announcing -a-new-experimental-modules-1be8d2d6c2ff

Atualmente, não é possível criar um pacote que possa ser usado por meio de require ('pkg') e importação 'pkg'. Há esforços em andamento para resolver isso e podem envolver mudanças nos itens acima. Em particular, o Node.js pode escolher um campo diferente de “principal” para definir o ponto de entrada do módulo ES de um pacote. Embora estejamos cientes de que a comunidade abraçou o campo "módulo", é improvável que Node.js adote esse campo, pois muitos dos pacotes publicados usando "módulo" incluem o módulo ES JavaScript que pode não ser avaliado em Node.js (porque extensões são deixadas de fora dos nomes de arquivo ou o código inclui instruções de requerer, etc.). Não publique nenhum pacote de módulo ES destinado ao uso por Node.js até que isso seja resolvido.

Por favor, veja # 9430 que acabei de abrir para rastrear o suporte em Jest. Vou manter este assunto aberto para discussão.

@SimenB isso é um bom sinal! Isso e a menção dos módulos nas notas de lançamento do Jest 25 dão a esperança de ver o suporte mais cedo.

@SimenB se bem me lembro Jest não conseguiu usar pacotes NPM publicados apenas como ESM, o que forçou a habilitar o Babel para alguns pacotes node_modules também. Isso mudou?

Você precisará transportar a importação / exportação até o suporte, tanto do usuário quanto do código da biblioteca

@SimenB :

Você precisará transportar a importação / exportação até o suporte, tanto do usuário quanto do código da biblioteca

Para nosso caso, a melhor maneira até agora é esta, já que todos os nossos pacotes têm /es/ dir, mas é frágil e pode não servir para outros projetos:

transformIgnorePatterns: ['node_modules/(?!.*?/es/.*\\.js)'],

Jest não pega esses pacotes sem transformação, apesar de type: module , como você disse.

Você precisará transportar a importação / exportação até o suporte, tanto do usuário quanto do código da biblioteca

Algum cronograma aproximado sobre isso?
da liberação do nó 14:

Acreditamos que a implementação atual oferece um modelo à prova de futuro para a criação de módulos ESM que abre o caminho para o JavaScript universal. Por favor, leia mais em nossa documentação.

A implementação do ESM no Node.js ainda é experimental, mas acreditamos que estamos chegando muito perto de poder chamar o ESM no Node.js de “estável”. Remover o aviso é um grande passo nessa direção.

como tal, estou relutante em exportar pacotes NPM (que podem ser consumidos por testes que implementam a estrutura de teste JEST) usando commonJS por muito mais tempo.

Estamos enviando uma versão experimental do Jest 25.4. Algumas correções de bugs no 25.5, mas ainda não está onde deveria estar. Você pode acompanhar o progresso em # 9430