Jest: Considere agregar soporte nativo para módulos ES

Jest tiene su propia implementación require (https://github.com/facebook/jest/blob/master/packages/jest-runtime/src/index.js), por lo que sería mucho más complicado que solo admite la sintaxis y, por defecto, mira .mjs . También estoy en contra de activar banderas experimentales.

Podría ser posible transpilar automáticamente import / export , pero implementar la semántica es una tarea enorme y probablemente bloqueada durante un año debido al soporte para el nodo 6.

Estoy de acuerdo con SimenB. Necesitamos una serie de ganchos del equipo del nodo para poder hacer que esto funcione junto con el módulo vm. Sin embargo, creo que deberíamos admitir esto mientras tanto, pero no reflejando la implementación nativa completa, sino usando babel y compilándolo para requerir dentro de babel-jest . Creo que, para fines de prueba, esto funcionará bien y no tenemos que proporcionar las mismas garantías que el tiempo de ejecución del nodo debe proporcionar de todos modos.

Entonces, ¿simplemente agregando babel-plugin-transform-es2015-modules-commonjs & babel-plugin-dynamic-import-node a babel-jest ?

Sí, eso es lo que estaba pensando.

Chicos, ¿qué hay de la integración de https://github.com/standard-things/esm ? Es rápido y mantiene muchos casos extremos.

@ TrySound, ¿cómo se vería eso en concreto? ¿Puedes hacer un prototipo?

Todavía tenemos nuestra propia implementación requerida (necesaria para simulacros), así que no creo que eso ayude mucho.

Y necesitamos trabajar tanto con las reglas de Node como con las reglas del navegador.

Estaría muy feliz de que me corrijan y de que funcione perfectamente para nosotros: D

@std/esm aparentemente debería funcionar con broma: https://twitter.com/jdalton/status/930257653292400640

¿Alguien podría darle una vuelta y volver con un PR para los documentos? 🙂

Supongo que a los usuarios les gustaría tener soporte en todas partes, pero descubrí que funciona solo para dependencias de archivos de prueba.

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

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

Es mejor, pero no ideal.

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

Entonces, ¿simplemente agregando babel-plugin-transform-es2015-modules-commonjs & babel-plugin-dynamic-import-node a babel-jest?

No creo que esta sea una gran solución, ya que no realiza ninguna comprobación de "exportación faltante" que es tan valiosa con los módulos ES. Por ejemplo, en el repositorio de React comencé a ejecutar build con más frecuencia solo porque Rollup encuentra estos errores, pero Jest con es2015-modules-commonjs no.

@ std / esm aparentemente debería funcionar con jest

Sería genial invertir algo de tiempo en su interoperabilidad. Estoy bastante seguro de que esta solución hacky se romperá eventualmente: https://stackoverflow.com/questions/46433678/specify-code-to-run-before-any-jest-setup-happens. Pero si es solo una cuestión de exponer algo del lado de Jest, sería genial verlo respaldado.

@SimenB , en mi opinión, el paso inmediato no sería demasiado complejo. Lo urgente es permitir que las personas trabajen con el módulo .mjs, incluso si babel está ayudando detrás de la escena de prueba. De lo contrario, las personas podrían tener que encontrar una solución de prueba diferente si quieren usar .mjs.

1. Corrija la propiedad testMatch para permitir que se encuentre el archivo .mjs
   (actualmente no funciona, incluso la expresión regular ya parece correcta, tal vez haya un código duro en algún lugar que rechace la extensión .mjs)
2. Pase la marca --experimental-modules al ejecutar node.js para que se ejecute de forma nativa
3. Jest debería tratar .mjs exactamente de la misma manera que .js hoy (por ejemplo, en jest require): las declaraciones de importación ya están permitidas dentro de .js hoy, por lo que solo es necesario permitir la extensión .mjs.

La solución final puede ser compleja y lleva tiempo, pero es inevitable ¿no?

Hola, ¿alguien ha podido solucionar este error?

Estamos usando .mjs con la opción "node --experimental-modules". ¿Alguna solución?

Estamos usando .mjs con la opción "node --experimental-modules". ¿Alguna solución?

Eso es experimental y no está completamente desarrollado. Todavía hay mucha rotación con cosas básicas, como cómo importar un módulo incorporado, aún en el aire. Proyectos como AVA han comenzado a permitir el uso de @std/esm como su canal de carga si se usa (sin pasar por Babel). Tal vez broma podría adoptar un enfoque similar.

Apoyar @std/esm es algo que queremos hacer, ¡ayudar a implementarlo es más que bienvenido!

@SimenB ¿Puedes chatear en algún momento de los hangouts?

Hola @SimenB 👋

Un usuario de esm ha contribuido con la demostración de esm + Jest y pensé que podría ser un buen punto de partida para crear un camino de vaca más oficial.

Actualizar:

La demostración de esm + Jest se ha actualizado con soporte básico de asignación de nombres de módulos .

¡Eso es muy bonito! Gracias por compartir.

Tendremos que averiguar dónde queremos que esté la integración. ¿Cómo manejaría los archivos CSS (u otros activos que no sean js)? ¿Debería ser solo una transformación? ¿Qué pasa con la transformación de babel incorporada? ¿Cómo debería comportarse Jest cuando se trata de cargadores entrantes, si afecta algo?

Parece que puede haber un beneficio para un corredor de bromas alternativo habilitado para contribuciones de la comunidad esm (o una bandera no oficial / experimental) para que podamos avanzar en algo así. ¿Habría interés en eso por parte del equipo de bromas?

require no está implementado en un corredor, está en el tiempo de ejecución. Cualquier contribución para hacerlo conectable es muy bienvenida (ref # 848).

Estoy seguro de que si puede hacer que el código de ejemplo @jdalton esté vinculado para que funcione sin problemas (o cerca de él), debería ser lo suficientemente simple como para cargarlo en el cargador esm detrás de una bandera en forma de broma. Una cosa que veo como un problema es que quiere el module global real, no el falso que creamos. ¿No está seguro de si eso significa que los módulos pueden tener fugas entre las pruebas? No sé qué hace Esm con él debajo del capó. Tampoco maneja simulaciones, por lo que las simulaciones con import aún se romperían

Puede que solo necesite algunos ajustes de cómo Jest aprovecha CJS. Por ejemplo, al burlarse del objeto module , en lugar de usar un objeto simple, podría usar require("module") y luego envolver / sobrescribir module.require para interceptar solicitudes y hacer malabares según sea necesario.

Actualizar:

Ahora estoy trabajando para habilitar Jest listo para usar con esm (con suerte, nada que Jest tenga que hacer de manera diferente) . Continuaré experimentando durante el fin de semana, pero los primeros signos se ven bien.

@jdalton ¿ Alguna actualización con la compatibilidad esm ?

Hola @JasonCust , ¡mi comentario ha recibido algo de atención!

He avanzado en la identificación del trabajo necesario para habilitar el soporte de Jest en esm . En mis experimentos obtuve Jest cargando y evaluando pruebas escritas en ESM. El trabajo requerido en el lado del cargador de esm es hacer que la forma en que manejamos el uso de vm.Script más genérica. Por el momento, nos conectamos con eso principalmente para el uso de REPL, que asume un solo módulo. Tenemos que hacer eso un poco más genérico para que el soporte de Jest se libere. No parece que Jest tenga que cambiar nada. El refactor de nuestro soporte de vm.Script todavía está en mi TODO y todavía será abordado antes de que publique cosas como el soporte experimental de WASM. Por el momento, he estado solucionando errores que han aparecido en torno a APM mejorado y soporte simulado.

Gracias por la actualización @jdalton ya que estoy emocionado de poder usar esm con Jest. Para no molestarlo mientras trabaja en esas cosas, ¿hay alguna tarea para esm que podamos seguir junto con el progreso?

Puede mantenerse suscrito a este hilo de seguir el repositorio. El soporte de Jest estará en la versión v3.1.0 para que pueda estar atento a esa versión.

@jdalton ¿ Alguna noticia sobre el apoyo a Jest en esm?

¡Hola @deepj!

Todavía está en mi lista y los elementos que puedo abordar antes de hacer esto se están reduciendo. He estado mejorando el soporte complementario de Jest para probar los módulos esm dentro de Jest _ (aunque CJS dentro de las pruebas de Jest) _. Todavía no hay nada que bloquee críticamente la implementación por parte de Jest _ (por lo que no hay trabajo para ellos) _. Microsoft, mi empleador, también es un gran usuario de Jest, por lo que uno de mis objetivos en el trabajo diario es mejorar esto también. Espero abordarlo pronto.

@jdalton Es bueno saberlo. Y gracias por tu trabajo. ¡Lo aprecio!

Tengo muchas ganas de esta característica: speak_no_evil:

He intentado que esta función funcione durante las últimas dos horas. Hay tantas soluciones parciales, respuestas medio documentadas, todas diferentes entre sí ... Solía ​​ser fácil probar los paquetes de node.js.

Entonces, ¿simplemente agregando babel-plugin-transform-es2015-modules-commonjs & babel-plugin-dynamic-import-node a babel-jest ?

¿Qué pasó con esa idea? ¿Algún problema para implementarlo?

Hola @jdalton. Me preguntaba si podría mantenernos actualizados sobre el estado de este problema. Lo siento si le molesto, pero estoy esperando esto por un tiempo, y sería mejor si recibiéramos una actualización al menos durante los últimos / próximos seis meses. Gracias :)

¡Hola @ SurenAt93!

Gracias por su paciencia. Espero tener un lanzamiento a finales de mes con el apoyo de Jest. Con eso, especificará esm como una transformación Jest.

Frio. ¿En qué se diferencia esa transformación de Babel?

@kenotron

Usar la opción transform Jest es una forma de cargar lateralmente el cargador esm . Entonces, aunque técnicamente también está transformando la fuente, también está conectando el cargador esm .

Si la pregunta es más, ¿cuál es la diferencia entre Babel y esm ? Babel es una colección de paquetes que transforma la fuente, uno de los objetivos podría ser la sintaxis de ESM. El cargador esm es un cargador de dependencia cero que simula el entorno de ejecución. Por lo tanto, esm admite cosas como import() dinámicos, pasa las especificaciones de prueba 262 relevantes (zonas muertas temporales, enlaces en vivo, errores iniciales, etc.) y admite la carga de una combinación de CJS / ESM / WASM en gusto por configuración.

@jdalton ¡ Gracias por su trabajo y apoyo!

@tomheller ;)

He intentado que esta función funcione durante las últimas dos horas. Hay tantas soluciones parciales, respuestas medio documentadas, todas diferentes entre sí ... Solía ​​ser fácil probar los paquetes de node.js.

Estoy de acuerdo.

Creé un proyecto Vue simple, que también manifiesta el problema.
https://github.com/igasparetto/vue-jest-test
No pude hacer que funcionara.

Seguí las instrucciones de las siguientes 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 hilo: https://github.com/vuejs/vue-cli/issues/1584

Mi máquina (no estoy seguro de que deba importar):

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

@kenotron

Usar la opción transform Jest es una forma de cargar lateralmente el cargador esm . Entonces, aunque técnicamente también está transformando la fuente, también está conectando el cargador esm .

Si la pregunta es más, ¿cuál es la diferencia entre Babel y esm ? Babel es una colección de paquetes que transforma la fuente, uno de los objetivos podría ser la sintaxis de ESM. El cargador esm es un cargador de dependencia cero que simula el entorno de ejecución. Por lo tanto, esm admite cosas como import() dinámicos, pasa las especificaciones de prueba 262 relevantes (zonas muertas temporales, enlaces en vivo, errores iniciales, etc.) y admite la carga de una combinación de CJS / ESM / WASM en gusto por configuración.

@kenotron, ¿ podría proporcionarnos una actualización, por favor?

@igasparetto , es el trabajo de

El último estado que creo que es: https://twitter.com/jdalton/status/1080627279124934661

¡Sí! Siento que esté tardando más de lo que quería. Localmente, ahora tengo todas las pruebas relevantes de test262 aprobadas. En el transcurso de subirlos, las pruebas de escenarios relacionados con la burla se deslizaron, así que tengo que recuperarlas antes de poder liberarlas. No es insuperable, solo lleva un poco de tiempo. Me presentaré en Covalence Conf el 16 de enero y espero tener un lanzamiento para entonces. En otras noticias, npm tink adoptó anticipadamente

16 de enero y espero tener un lanzamiento para entonces.

@jdalton Espero que la presentación haya ido bien.

¿Tiene una actualización sobre esta versión, por favor?

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

Dejo un pequeño "punto de datos" aquí para ayudarlo en su planificación. Me doy cuenta de que todos están donando su tiempo y sus habilidades para abordar este problema. Como desarrollador, agradezco su contribución.

Pasé la mayor parte de ayer, un sábado nada menos, para ponerme al día con los módulos javascript tanto en el lado del cliente como en el del servidor. ESM, CommonJS, AMD, qué lío confuso. Nunca pude obtener una prueba de broma para trabajar con ESM cargando un módulo (nodo) usando una extensión .mjs. Podría cargar el mismo módulo con éxito en el lado del cliente. Podría crear un "cliente" de nodo que usara el módulo con una declaración de importación. No pude configurar jest correctamente para consumir la misma declaración de importación, con o sin babel, con o sin esm. Finalmente me cambié a Ava y lo hice funcionar siguiendo una receta en su sitio web. Sí, seguí una receta, no entiendo del todo la maquinaria que hizo funcionar todas las piezas. Pero al menos ahora puedo escribir módulos javascript de carga de ESM y pruebas unitarias asociadas. Creo. Extrapolo sobre la base de un solo éxito. También tienen una receta para conectar ava a webstorm. Pero al menos están presentando recetas a simples mortales como yo.

También me doy cuenta de que este mensaje se leerá como si estuviera lloriqueando (que en parte lo estoy haciendo). Veo todo el trabajo que se ha convertido en una broma. Pero esto del soporte de ESM es un asesino y un factor decisivo para mí. Pensé que agradecería algunos comentarios, pero si no, ignórelos o pídame que los elimine y lo haré.

¿Alguna noticia a la luz de la compatibilidad con los

@dandv He estado investigando si Jest puede admitir módulos ES nativos en el nodo 12. vm.SourceTextModule , que requiere que se pasen algunos indicadores CLI a node :

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

La API también es de muy bajo nivel.

TBD.

Discusión en https://github.com/nodejs/node/issues/27387

Actualización: se le ha dicho que espere hasta que el diseño del cargador de módulos de Node esté bloqueado. Mientras tanto, standard-things / esm # 706 podría ser la mejor opción.

jest es una biblioteca de pruebas muy agradable. soporte para esm realmente todo lo que necesita para ser completo!

Actualización: se le ha dicho que espere hasta que el diseño del cargador de módulos de Node esté bloqueado. Mientras tanto, standard-things / esm # 706 podría ser la mejor opción.

esto no funciona con broma, lamentablemente.

@jdalton Estamos usando lodash-es , que es la compilación de exportaciones del módulo ES de lodash. Nuestro proyecto es un proyecto de Angular v7, que utiliza Webpack v4 bajo el capó como su paquete. Para aquellos que no lo saben, ¡ lodash-es se puede sacudir con Webpack v4! (◔ ౪◔) ⊃━ ☆ ﾟ. * ・.

Desafortunadamente, esto nos está causando problemas dado que Jest aún no tiene soporte para el módulo ES. Esperamos que esta función sea parte de Jest pronto. ¿Alguien sabría cómo hacer que lodash-es trabaje con Jest?

Jest falla con el mensaje de error:

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

    SyntaxError: Unexpected token export

Nuestro jest.config.js

También estamos usando el paquete npm jest-preset-angular .

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

Desafortunadamente, esto nos está causando problemas dado que Jest aún no tiene soporte para el módulo ES. Esperamos que esta función sea parte de Jest pronto. ¿Alguien sabría cómo hacer que lodash-es trabaje con Jest?

Dile a Jest que no ignore lodash-es al 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 según las instrucciones, no está claro cómo usar el paquete, dice: crear un archivo junto a package.json llamado jest.config.js content module.exports = require('jest-esnext') , pero ¿qué pasa si ya tengo una configuración? ¿Cómo integrar?

este es el archivo usado

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

es posible que pueda reemplazar el contenido de _default con el de su jest.config.js

Hola tios,
El nodo 12.13.0 LTS finalmente se lanzó ... ¿alguna noticia al respecto?

@ mtsmachado8 Me temo que el equipo de la v8 aún necesita algo de tiempo porque veo que los módulos de ESM aún se marcan como experimentales ... tal vez fallaron en la hoja de ruta.

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

Para el ESM sin indicador, este RP está en su lugar
https://github.com/nodejs/node/pull/29866

@azder @haraldrudell, así que básicamente en su solución realiza la transformación de Babel para todos los archivos JS, incluidos los de node_modules ?

En mi caso, tuve que usar su preset directamente porque no he encontrado cómo configurar el transformador así:

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

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

El nodo ahora tiene el soporte de módulo activado de forma predeterminada

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

El soporte predeterminado de los módulos ECMAScript aterrizó en 13.2.0

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

No trabajaremos en esto hasta que los cargadores estén disponibles. Sin ellos, Node no tiene los ganchos que Jest necesita para brindar el soporte adecuado. Consulte https://medium.com/@nodejs/announcing -core-node-js-support-for-ecmascript-modules-c5d6dc29b663 (no puedo vincularme directamente a la sección, pero es la de "Trabajo en progreso" en el fondo)

Para aquellos que usan módulos nativos y quieren usar jest .
Mientras trabaja en esto, le sugiero una solución rápida para el nodo v. 13.2.0:
babel-plugin-transform-default-import
Uso (en _package.json_):

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

Libs necesitan instalar:
npm i --save-dev @babel/core @babel/preset-env babel-plugin-transform-default-import

Nota: es posible que no necesite usar babel-plugin-transform-default-import si no tiene bibliotecas que tengan babel llamado export (o no lo usa)

@infodusha Impresionante :). Gracias por esto.

En mi proyecto funciona sin los complementos:

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

babel.config.js (este tenía que llamarse así, no .babelrc ):

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

    plugins: [],
};

el truco consiste en separar los archivos en directorios y usar el package.json apropiado en ellos:

en test dir, usé

{
  "type": "commonjs"
}

mientras que en src dir:

{
  "type": "module"
}

@azder Pero si importa un paquete que proporciona commonjs named import en módulos nativos, debe importarlo con la importación predeterminada y en babel debe utilizar named import. Es probable que no tenga paquetes como ese, o paquetes que proporcionen exportación es6, pero no todos los paquetes están listos para hacerlo mañana.

@infodusha Probablemente no tengo qué ahora? ¿Intentaste lo que escribí y encuentras un problema con él o simplemente asumes que tengo problemas para usarlo?

Proporcione un ejemplo real, ya que no estoy claro a qué se refiere con "paquete de importación que proporciona commonjs con nombre de importación en módulos nativos".

Hasta ahora no he tenido problemas para escribir todos los archivos con la extensión de archivo .js donde en el directorio ./src están "type":"module" y el directorio "type":"commonjs" ./test "type":"commonjs" con esto:

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

Eso es porque Jest transpila silenciosamente los módulos ES al código CommonJS .

Esto es lo que creo que debería probar los módulos ES de forma nativa:

(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 esas son soluciones.

Cree un directorio mymodule con package.son type=module y dos archivos en él: first.js y second.js .
Luego intente import { first } from "mymodule";

Necesita el campo exports en su lugar en el json para usar Node ESM, y actualmente ningún paquete lo tiene (es decir, lodash).

Su ejemplo puede parecer que funciona, pero se rompe tan pronto como uno de some-module.js o another-module.js intente import un módulo con nombre: se romperán en cascada.

@damianobarbati _ NECESITA _ "type": "module" en package.json , sin él, todos los archivos .js en su módulo se cargarán como

exports solo se usa para limitar lo que está expuesto a consumidores externos y para exportaciones condicionales , no tiene absolutamente ningún efecto sobre si los archivos .js se analizarán como CommonJS o ESM .

@damianobarbati estás equivocado, según lo que dijo @ Exe-Boss, por cierto,

Eso es porque Jest transpila silenciosamente los módulos ES al código CommonJS.

Sí, confío en las peculiaridades de Jest, esa es la razón por la que estaba usando babel.config.js sin siquiera agregar babel al devDependencies

@damianobarbati

Tenga en cuenta que tengo un proyecto de trabajo, en él estoy usando Jest transpiled, mientras que el directorio src tiene el tipo de módulo, nota, ./src no la raíz donde está el archivo de configuración de babel (ese es CJS debido a peculiaridades).

Además, tiene razón, ya que no importo nada de NPM que sea CJS, ya que no creo que NPM (o los autores del paquete) estén listos para mezclar y combinar.

El objetivo de mi proyecto es tener solo ESM (para reducir la grasa de las herramientas), por lo que Jest es la única excepción que se transpila por sí sola.

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

@damianobarbati

Algo así, aquí está el proyecto https://github.com/azder/clip . Tenga en cuenta que no hay "dependencias" en mi package.json según la última oración del extracto de la publicación del blog, decidí no mezclar los módulos ESM y CJS de NPM.

De esta manera, para las necesidades de Jest, transpila lo que requiere de mis módulos ESM, pero tal vez se requiera más configuración de babel para lidiar con el directorio node_modules .

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

Actualmente, no es posible crear un paquete que se pueda usar a través de require ('pkg') e import 'pkg'. Se están realizando esfuerzos para abordar esto y pueden implicar cambios en lo anterior. En particular, Node.js puede elegir un campo que no sea "principal" para definir el punto de entrada del módulo ES de un paquete. Si bien somos conscientes de que la comunidad ha adoptado el campo "módulo", es poco probable que Node.js adopte ese campo, ya que muchos de los paquetes publicados con "módulo" incluyen JavaScript del módulo ES que puede no evaluar en Node.js (porque las extensiones se dejan fuera de los nombres de archivo, o el código incluye declaraciones require, etc.). No publique ningún paquete de módulo ES destinado a ser utilizado por Node.js hasta que esto se resuelva.

Consulte el n. ° 9430 que acabo de abrir para realizar un seguimiento del soporte en Jest. Mantendré este tema abierto a discusión.

@SimenB ¡ esto es una buena señal! Esto y la mención de los módulos en las notas de la versión de Jest 25 dan la esperanza de ver el soporte antes.

@SimenB, si node_modules también. ¿Ha cambiado esto?

Deberá transpilar la importación / exportación hasta que llegue el soporte, tanto el código de usuario como de biblioteca

@SimenB :

Deberá transpilar la importación / exportación hasta que llegue el soporte, tanto el código de usuario como de biblioteca

Para nuestro caso, la mejor manera hasta ahora es esta, ya que todos nuestros paquetes tienen /es/ dir, pero eso es frágil y puede que no se ajuste a otros proyectos:

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

Jest no recoge esos paquetes sin transformación a pesar de type: module , como dijiste.

Deberá transpilar la importación / exportación hasta que llegue el soporte, tanto el código de usuario como de biblioteca

¿Algún calendario aproximado sobre esto?
desde la versión del nodo 14:

Creemos que la implementación actual ofrece un modelo a prueba de futuro para la creación de módulos ESM que allana el camino hacia JavaScript universal. Lea más en nuestra documentación.

La implementación de ESM en Node.js aún es experimental, pero creemos que nos estamos acercando mucho a poder llamar a ESM en Node.js "estable". Eliminar la advertencia es un gran paso en esa dirección.

como tal, soy reacio a exportar paquetes NPM (que pueden ser consumidos por las pruebas que implementan el marco de prueba JEST) usando commonJS durante mucho más tiempo.

Estamos enviando una versión experimental de Jest 25.4. Varias correcciones de errores en 25.5, pero aún no está donde debería estar. Puedes seguir el progreso en # 9430