Jest: Veuillez envisager d'ajouter un support natif pour les modules ES

Jest a sa propre implémentation require (https://github.com/facebook/jest/blob/master/packages/jest-runtime/src/index.js), donc ce serait bien plus impliqué que juste prenant en charge la syntaxe et par défaut regarder .mjs . Je suis également contre l'activation des drapeaux expérimentaux.

Il est peut-être possible de transpiler automatiquement import / export , mais la mise en œuvre de la sémantique est une entreprise énorme, et probablement bloquée pendant un an en raison de la prise en charge du nœud 6.

Je suis d'accord avec SimenB. Nous avons besoin d'un certain nombre de crochets de l'équipe de nœuds pour pouvoir faire fonctionner cela avec le module vm. Cependant, je pense que nous devrions prendre en charge cela en attendant, mais pas en reflétant l'implémentation native complète mais plutôt en utilisant babel et en le compilant pour exiger à l'intérieur de babel-jest . Je pense qu'à des fins de test, cela fonctionnera bien et nous n'avons pas à fournir les mêmes garanties que le runtime du nœud doit fournir de toute façon.

Donc juste en ajoutant babel-plugin-transform-es2015-modules-commonjs & babel-plugin-dynamic-import-node à babel-jest ?

Ouais, c'est ce que je pensais.

Les gars, qu'en est-il de l'intégration de https://github.com/standard-things/esm ? C'est rapide et maintient beaucoup de cas de bord.

@TrySound à quoi cela ressemblerait-il concrètement ? Pouvez-vous faire un prototype?

Nous avons toujours notre propre implémentation des exigences (nécessaire pour les simulations), donc je ne pense pas que cela aiderait beaucoup.

Et nous devons travailler à la fois avec les règles de Node et les règles du navigateur.

Je serais très heureux d'être corrigé et que cela fonctionne parfaitement pour nous :D

@std/esm devrait apparemment fonctionner avec Jest : https://twitter.com/jdalton/status/930257653292400640

Quelqu'un pourrait-il faire un tour et revenir avec un PR pour les docs? ??

Je suppose que les utilisateurs aimeraient avoir un support partout, mais j'ai trouvé que cela ne fonctionnait que pour les dépendances des fichiers de test.

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

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

C'est mieux, mais pas idéal.

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

Donc, il suffit d'ajouter babel-plugin-transform-es2015-modules-commonjs & babel-plugin-dynamic-import-node à babel-jest ?

Je ne pense pas que ce soit une excellente solution, car elle n'effectue aucune vérification des "exportations manquantes" si précieuses avec les modules ES. Par exemple, dans le référentiel React, j'ai commencé à exécuter la génération plus souvent simplement parce que Rollup trouve ces erreurs, mais pas Jest avec es2015-modules-commonjs .

@std/esm devrait apparemment fonctionner avec jest

Ce serait vraiment bien d'investir du temps dans leur interopérabilité. Je suis presque sûr que cette solution hacky finira par se briser : https://stackoverflow.com/questions/46433678/specify-code-to-run-before-any-jest-setup-happens. Mais s'il ne s'agit que d'exposer quelque chose du côté de Jest, ce serait cool de le voir pris en charge.

@SimenB , dans mon esprit, l'étape immédiate ne serait pas trop complexe. Ce qui est urgent, c'est de permettre aux gens de travailler avec le module .mjs, même si babel aide en coulisses. Sinon, les utilisateurs devront peut-être trouver une solution de test différente s'ils souhaitent utiliser .mjs.

1. Correction de la propriété testMatch pour permettre la recherche du fichier .mjs
   (actuellement, cela ne fonctionne pas, même la regex semble déjà correcte, peut-être qu'il y a un code dur quelque part rejetant l'extension .mjs)
2. Passez l'indicateur --experimental-modules lors de l'exécution de node.js afin qu'il s'exécute en mode natif
3. Jest devrait traiter .mjs exactement de la même manière que .js aujourd'hui (par exemple, dans jest require) - les instructions d'importation sont déjà autorisées dans .js aujourd'hui, il suffit donc d'autoriser l'extension .mjs.

La solution finale est peut-être complexe et prend du temps, mais elle est inévitable n'est-ce pas ?

Bonjour, quelqu'un a-t-il pu corriger cette erreur ?

Nous utilisons .mjs avec l'option "node --experimental-modules". Une solution de contournement ?

Nous utilisons .mjs avec l'option "node --experimental-modules". Une solution de contournement ?

C'est expérimental et pas complètement étoffé. Il y a encore beaucoup de désabonnement avec des choses de base, comme comment importer un module intégré, toujours en suspens. Des projets comme AVA ont commencé à autoriser l'utilisation de @std/esm comme pipeline de chargement s'il est utilisé (en contournant Babel). Peut-être que Jest pourrait adopter une approche similaire.

Soutenir @std/esm est quelque chose que nous voulons faire, aider à le mettre en œuvre est plus que bienvenu !

@SimenB Pouvez-vous discuter de temps en temps sur des hangouts ?

Salut @SimenB 👋

Un utilisateur de esm a contribué esm démo et j'ai pensé que cela pourrait être un bon point de départ pour créer un chemin de vache plus officiel.

Mettre à jour:

La démo esm + Jest a été mise à jour avec la prise en charge du mappage de nom de module de base.

C'est plutôt cool! Merci d'avoir partagé.

Nous devrons déterminer où nous voulons que l'intégration soit. Comment gérerait-il les fichiers CSS (ou d'autres actifs non-js) ? Cela devrait-il être juste une transformation? Qu'en est-il de la transformation Babel intégrée ? Comment Jest devrait-il se comporter en ce qui concerne les chargeurs entrants, si cela affecte quoi que ce soit ?

Il semble qu'il puisse y avoir un avantage pour un coureur de plaisanteries alternatif esm activé par la communauté (ou un drapeau non officiel / expérimental) afin que nous puissions progresser sur quelque chose comme ça. Y aurait-il un intérêt pour cela de la part de l'équipe de plaisanteries?

require n'est pas implémenté dans un runner, c'est dans le runtime lui-même. Toute contribution visant à le rendre enfichable est la bienvenue (réf #848).

Je suis sûr que si vous pouvez obtenir le code d'exemple lié à @jdalton pour qu'il fonctionne sans problème (ou presque), il devrait être assez simple de charger dans le chargeur esm derrière un drapeau en plaisantant lui-même. Une chose que je considère comme un problème, c'est qu'il veut le vrai module global, pas le faux que nous créons. Vous ne savez pas si cela signifie que les modules peuvent fuir entre les tests ? Je ne sais pas ce qu'esm en fait sous le capot. Il ne gère pas non plus les moqueries, donc les moqueries avec import seraient toujours cassées

Peut-être juste besoin de peaufiner la façon dont Jest puise dans CJS. Par exemple, lorsque vous vous moquez de l'objet module , au lieu d'utiliser un objet simple, il pourrait utiliser require("module") puis envelopper/écraser module.require pour intercepter les demandes et jongler selon les besoins.

Mettre à jour:

Je travaille maintenant sur l'activation de Jest prêt à l'emploi avec esm (avec, espérons-le, rien à faire différemment pour Jest) . Je vais continuer à expérimenter au cours du week-end, mais les premiers signes semblent bons.

@jdalton Une mise à jour avec la compatibilité esm ?

Salut @JasonCust , wow mon commentaire a attiré l'attention !

J'ai progressé dans l'identification du travail nécessaire pour activer le support Jest dans esm . Dans mes expériences, j'ai obtenu des tests de chargement et d'évaluation de Jest écrits dans ESM. Le travail requis du côté du esm loader est de rendre la façon dont nous gérons vm.Script plus générique. Pour le moment, nous nous y connectons principalement pour une utilisation REPL qui suppose un seul module. Nous devons rendre cela un peu plus générique pour que le support de Jest se débrouille. Il ne semble pas que Jest doive changer quoi que ce soit. Le refactor de notre support vm.Script est toujours sur mon TODO et sera toujours abordé avant que je ne publie des choses comme le support expérimental de WASM. En ce moment, j'ai éliminé les bogues qui sont apparus autour de l'amélioration de l'APM et de la prise en charge des moqueries.

Merci pour la mise à jour @jdalton car je suis ravi de pouvoir utiliser esm avec Jest. Pour ne pas vous déranger pendant que vous travaillez sur ces choses, y a-t-il une tâche pour esm que nous pouvons suivre au fur et à mesure des progrès ?

Vous pouvez rester abonné à ce fil de suivi du repo. La prise en charge de Jest sera dans la version v3.1.0 afin que vous puissiez garder un œil sur cette version.

@jdalton Des nouvelles du soutien à Jest dans esm ?

Salut @deepj !

C'est toujours sur ma liste et les éléments auxquels je peux m'attaquer avant de le faire diminuent. J'ai amélioré la prise en charge supplémentaire de Jest pour tester les modules esm dans Jest _(bien que CJS dans les tests Jest)_. Il n'y a toujours rien qui bloque de manière critique la mise en œuvre du côté de Jest _(donc aucun travail à faire pour eux)_. Microsoft, mon employeur, est également un grand utilisateur de Jest, c'est donc l'un de mes objectifs quotidiens d'améliorer cela également. J'espère m'y attaquer bientôt.

@jdalton Bon à savoir. Et merci pour votre travail. Je vous en suis reconnaissant!

J'attends vraiment cette fonctionnalité avec impatience :speak_no_evil:

J'essaie de faire fonctionner cette fonctionnalité depuis deux heures. Il y a tellement de solutions partielles, de réponses à moitié documentées, toutes différentes les unes des autres... Avant, il était facile de tester les packages node.js.

Donc juste en ajoutant babel-plugin-transform-es2015-modules-commonjs & babel-plugin-dynamic-import-node à babel-jest ?

Qu'est-il arrivé à cette idée? Un problème dans sa mise en œuvre ?

Salut @jdalton. Je me demandais si vous pouviez nous tenir au courant de l'état de cette question. Désolé si je vous dérange, mais j'attends cela depuis un moment, et ce serait mieux si nous recevions une mise à jour au moins pour les six derniers mois/prochains mois. Merci :)

Salut @SurenAt93 !

Merci pour votre patience. J'espère avoir une sortie d'ici la fin du mois avec le support de Jest. Avec cela, vous spécifierez esm tant que transformation Jest .

Frais. En quoi cette transformation est-elle différente de Babel ?

@kenotron

L'utilisation transform option esm . Ainsi, bien qu'il transforme aussi techniquement la source, il câble également le chargeur esm .

Si la question est plus quelle est la différence entre Babel et esm . Babel est une collection de packages qui transforme la source, l'une des cibles pourrait être la syntaxe ESM. Le chargeur esm est un chargeur sans dépendance qui simule l'environnement d'exécution. Ainsi, esm prend en charge des choses comme la dynamique import() , passe les spécifications de test262 pertinentes (zones mortes temporelles, liaisons en direct, erreurs initiales, etc.) et prend en charge le chargement d'un mélange de CJS/ESM/WASM sur goûter par configuration.

@jdalton Merci pour votre travail et votre soutien !

@tomheller ;)

J'essaie de faire fonctionner cette fonctionnalité depuis deux heures. Il y a tellement de solutions partielles, de réponses à moitié documentées, toutes différentes les unes des autres... Avant, il était facile de tester les packages node.js.

Je suis d'accord.

J'ai créé un projet Vue simple, qui manifeste également le problème.
https://github.com/igasparetto/vue-jest-test
Je n'ai pas réussi à le faire fonctionner.

J'ai suivi les instructions des pages suivantes :

• https://vuejs.org/v2/guide/unit-testing.html
• https://medium.com/@kevin_peters/unit -testing-vue-js-components-with-jest-86e14ef499da
• Veuillez consulter ce fil : https://github.com/vuejs/vue-cli/issues/1584

Ma machine (pas sûr que ça ait de l'importance) :

• Windows 10 Professionnel 64 bits
• Nœud v8.9.4
• Vue : 3.2.3
• npm : 6.5.0

@kenotron

L'utilisation transform option esm . Ainsi, bien qu'il transforme aussi techniquement la source, il câble également le chargeur esm .

Si la question est plus quelle est la différence entre Babel et esm . Babel est une collection de packages qui transforme la source, l'une des cibles pourrait être la syntaxe ESM. Le chargeur esm est un chargeur sans dépendance qui simule l'environnement d'exécution. Ainsi, esm prend en charge des choses comme la dynamique import() , passe les spécifications de test262 pertinentes (zones mortes temporelles, liaisons en direct, erreurs initiales, etc.) et prend en charge le chargement d'un mélange de CJS/ESM/WASM sur goûter par configuration.

@kenotron pouvez-vous nous fournir une mise à jour s'il vous plaît?

@igasparetto , c'est le travail de

Le dernier statut là-bas, je pense, est : https://twitter.com/jdalton/status/1080627279124934661

Ouais! Désolé, cela prend plus de temps que je ne le voulais. Localement, j'ai maintenant réussi tous les tests test262 pertinents. Au cours de leur mise en place, les tests de scénarios liés à la moquerie ont glissé, je dois donc les récupérer avant de pouvoir les publier. Ce n'est pas insurmontable, cela prend juste un peu de temps. Je présente à Covalence Conf le 16 janvier et j'espère avoir une sortie d'ici là. Dans d'autres nouvelles, npm tink adopté tôt

16 janvier et j'espère avoir une sortie d'ici là

@jdalton J'espère que la présentation s'est bien passée.

Avez-vous une mise à jour sur cette version s'il vous plaît?

@igasparetto C'est dans https://github.com/standard-things/esm/issues/97#issuecomment -454985896 et dans https://github.com/standard-things/esm/issues/706 ☺️

Je laisse ici un petit "point de données" pour vous aider dans votre planification. Je sais que vous donnez tous de votre temps et de vos compétences pour régler ce problème. En tant que développeur moi-même, j'apprécie votre contribution.

Je viens de passer la majeure partie de la journée d'hier, un samedi pas moins, à me familiariser avec les modules javascript à la fois côté client et côté serveur. ESM, CommonJS, AMD, quel gâchis déroutant. Je n'ai jamais pu obtenir un test de plaisanterie pour travailler avec ESM en chargeant un module (nœud) à l'aide d'une extension .mjs. J'ai pu charger le même module avec succès côté client. Je pourrais créer un nœud "client" qui utilisait le module avec une déclaration d'importation. Je ne pouvais pas configurer correctement jest pour consommer la même instruction d'importation, avec ou sans babel, avec ou sans esm. Je suis finalement passé à ava et je l'ai fait fonctionner en suivant une recette sur leur site Web. Oui, j'ai suivi une recette, je ne comprends pas tout à fait la machinerie qui a fait fonctionner toutes les pièces. Mais au moins, je peux maintenant écrire des modules javascript de chargement ESM et les tests unitaires associés. Je pense. J'extrapole sur la base d'un seul succès. Ils ont également une recette pour connecter ava à webstorm. Mais au moins, ils présentent des recettes à de simples mortels comme moi.

Je me rends également compte que ce message sera lu comme si je pleurnichais (ce que je suis en partie). Je vois tout le travail qui est allé en plaisanterie. Mais cette chose de support ESM est un tueur et un briseur d'affaire pour moi. Je pensais que vous apprécieriez des commentaires, mais sinon, ignorez cela ou demandez-moi de le supprimer et je le ferai.

Des nouvelles à la lumière du support des

@dandv J'ai fait des recherches pour savoir si Jest peut prendre en charge les modules ES natifs dans le nœud 12. Cela impliquera que Jest utilise l'API vm.SourceTextModule , qui nécessite que quelques indicateurs CLI soient transmis à node :

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

L'API est également de très bas niveau.

À déterminer.

Discussion sur https://github.com/nodejs/node/issues/27387

Mise à jour : on vous a dit d'attendre que la conception du chargeur de modules de Node soit verrouillée. En attendant, standard-things/esm#706 pourrait être le meilleur pari.

jest est une très belle bibliothèque de tests. support pour esm vraiment tout ce qu'il faut pour être complet !

Mise à jour : on vous a dit d'attendre que la conception du chargeur de modules de Node soit verrouillée. En attendant, standard-things/esm#706 pourrait être le meilleur pari.

cela ne fonctionne pas avec la plaisanterie, malheureusement.

@jdalton Nous utilisons lodash-es , qui est la version ES Module Exports de lodash. Notre projet est un projet Angular v7, qui utilise Webpack v4 sous le capot comme bundler. Pour ceux qui ne le savent pas, lodash-es est agitable avec Webpack v4 ! ( ౪◔)⊃━☆ﾟ.*・.

Malheureusement, cela nous cause des problèmes étant donné que Jest ne prend pas encore en charge le module ES. Nous espérons que cette fonctionnalité fera bientôt partie de Jest. Est-ce que quelqu'un saurait comment faire travailler lodash-es avec Jest ?

Jest échoue avec le message d'erreur :

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

    SyntaxError: Unexpected token export

Notre jest.config.js

Nous utilisons également le package 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']
};

Malheureusement, cela nous cause des problèmes étant donné que Jest ne prend pas encore en charge le module ES. Nous espérons que cette fonctionnalité fera bientôt partie de Jest. Est-ce que quelqu'un saurait comment faire travailler lodash-es avec Jest ?

Dites à Jest de ne pas ignorer lodash-es lors de la transformation :

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

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

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

@haraldrudell selon les instructions, il n'est pas clair comment utiliser le package, il est dit : créez un fichier à côté de package.json nommé jest.config.js content module.exports = require('jest-esnext') , mais que se passe-t-il si j'ai déjà une configuration ? Comment s'intégrer ?

c'est le fichier utilisé

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

vous pourrez peut-être remplacer le contenu de _default par celui de votre jest.config.js

Salut les gars,
node 12.13.0 LTS est enfin sorti... des nouvelles à ce sujet ?

@ mtsmachado8 Je crains que l'équipe v8

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

Pour l'ESM non signalé, ce PR est en place
https://github.com/nodejs/node/pull/29866

@azder @haraldrudell donc fondamentalement, dans votre solution, vous effectuez une transformation Babel pour tous les fichiers JS, y compris ceux de node_modules ?

Dans mon cas, j'ai dû utiliser votre préréglage directement car je n'ai pas trouvé comment configurer le transformateur comme ceci :

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

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

Node a maintenant la prise en charge du module basculée par défaut

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

La prise en charge par défaut des modules ECMAScript a atterri dans 13.2.0

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

Nous ne travaillerons pas là-dessus tant que les chargeurs ne seront pas disponibles. Sans eux, Node n'a pas les crochets dont Jest a besoin pour fournir un support approprié. Voir https://medium.com/@nodejs/announcing -core-node-js-support-for-ecmascript-modules-c5d6dc29b663 (je n'arrive pas à lier directement à la section, mais c'est la section "Work in Progress" au fond)

Pour ceux qui utilisent des modules natifs et veulent utiliser jest .
Pendant que vous travaillez là-dessus, je suggère une solution rapide pour le nœud v. 13.2.0 :
babel-plugin-transform-default-import
Utilisation (dans _package.json_) :

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

Les bibliothèques doivent installer :
npm i --save-dev @babel/core @babel/preset-env babel-plugin-transform-default-import

Remarque : vous n'avez peut-être pas besoin d'utiliser babel-plugin-transform-default-import si vous n'avez pas de bibliothèques portant le nom de babel export (ou si vous ne l'utilisez pas)

@infodusha Génial :) . Merci pour ça.

Dans mon projet, cela fonctionne sans les plugins :

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

babel.config.js (celui-ci devait être nommé ainsi, pas .babelrc ):

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

    plugins: [],
};

l'astuce consiste à séparer les fichiers dans des répertoires et à utiliser les package.json appropriés :

dans test dir, j'ai utilisé

{
  "type": "commonjs"
}

tandis que dans src dir :

{
  "type": "module"
}

@azder Mais si vous importez un package qui fournit une importation nommée commonjs dans des modules natifs, vous devez l'importer avec l'importation par défaut et dans babel, vous devez utiliser une importation nommée. Probablement, vous n'avez pas de packages comme ça, ou de packages qui fournissent une exportation es6, mais tous les packages ne sont pas prêts à le faire demain

@infodusha Je n'ai probablement pas quoi maintenant? Avez-vous essayé ce que j'ai écrit et avez-vous trouvé un problème ou supposez-vous simplement que j'ai des problèmes à l'utiliser?

Fournissez un exemple réel car je ne comprends pas bien ce que vous entendez par "package d'importation qui fournit des commonjs nommés import dans des modules natifs".

Jusqu'à présent, je n'ai eu aucun problème à écrire tous les fichiers avec l'extension de fichier .js où dans le répertoire ./src trouvent "type":"module" et le répertoire "type":"commonjs" ./test "type":"commonjs" avec ceci :

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

C'est parce que Jest transpile silencieusement les modules ES en code CommonJS .

Voici ce que je pense devrait tester les modules ES en natif :

(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 ce sont des solutions de contournement.

Créez un répertoire mymodule avec package.son type=module et deux fichiers dedans : first.js et second.js .
Ensuite, essayez de import { first } from "mymodule";

Vous avez besoin du champ exports en place dans le json pour utiliser Node ESM, et aucun package ne l'a actuellement (c'est-à-dire: lodash).

Votre exemple peut sembler fonctionner mais il casse dès que l'un des some-module.js ou another-module.js essaie de import un module nommé : ils vont se casser en cascade.

@damianobarbati Vous _ BESOIN de _ "type": "module" dans package.json , sans cela, tous les fichiers .js de votre module seront chargés en tant que CommonJS .

exports n'est utilisé que pour limiter ce qui est exposé aux consommateurs externes et pour les exportations conditionnelles , cela n'a absolument aucun effet sur le fait que les fichiers .js seront analysés en tant que CommonJS ou ESM .

@damianobarbati vous vous trompez, d'après ce que @Exe-Boss a dit, d'ailleurs,

C'est parce que Jest transpile silencieusement les modules ES en code CommonJS.

Oui, je me fie aux bizarreries de Jest, c'est la raison pour laquelle j'utilisais babel.config.js sans même ajouter babel au devDependencies

@damianobarbati

Veuillez noter que j'ai un projet de travail, dans lequel j'utilise Jest transpilé, tandis que le répertoire src a le type de module, notez, ./src pas la racine où se trouve le fichier de configuration babel (celui-ci est CJS en raison de bizarreries).

De plus, vous avez raison car je n'importe rien de NPM qui soit CJS car je ne pense pas que NPM (ou les auteurs du package) soient tout à fait prêts pour le mix and match.

L'objectif de mon projet est de n'avoir que l'ESM (pour réduire la graisse de l'outillage), donc Jest est la seule exception qui se transpile toute seule.

@azder quelque chose comme ça ? https://github.com/damianobarbati/node-jest/tree/feature/azder-test

@damianobarbati

Quelque chose comme ça, voici le projet https://github.com/azder/clip . Notez qu'il n'y a pas de "dépendances" dans mon package.json selon la dernière phrase de l'extrait de l'article de blog, j'ai décidé de ne pas mélanger les modules ESM et CJS de NPM.

De cette façon, pour les besoins de Jest, il transpile ce qui est requis de mes modules ESM, mais peut-être qu'il faudra plus de configuration babel pour gérer le répertoire node_modules .

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

Actuellement, il n'est pas possible de créer un package pouvant être utilisé à la fois via require('pkg') et import 'pkg'. Des efforts sont en cours pour résoudre ce problème, et peuvent impliquer des changements à ce qui précède. En particulier, Node.js peut choisir un champ autre que « principal » pour définir le point d'entrée du module ES d'un package. Bien que nous sachions que la communauté a adopté le champ « module », il est peu probable que Node.js adopte ce champ, car de nombreux packages publiés à l'aide de « module » incluent le module ES JavaScript qui peut ne pas être évalué dans Node.js (car les extensions sont omises des noms de fichiers, ou le code inclut des instructions require, etc.). Veuillez ne publier aucun package de module ES destiné à être utilisé par Node.js jusqu'à ce que ce problème soit résolu.

S'il vous plaît voir #9430 que je viens d'ouvrir pour suivre le support dans Jest. Je garde ce sujet ouvert à la discussion.

@SimenB c'est bon signe ! Ceci et la mention des modules dans les notes de publication de Jest 25 donnent l'espoir de voir le support plus tôt.

@SimenB si je me souviens bien, Jest n'a pas pu utiliser les packages NPM publiés uniquement en tant qu'ESM, ce qui a obligé à activer Babel pour certains packages node_modules également. Cela a-t-il changé ?

Vous devrez transpiler l'import/export jusqu'à l'arrivée du support, à la fois le code de l'utilisateur et celui de la bibliothèque

@SimenB :

Vous devrez transpiler l'import/export jusqu'à l'arrivée du support, à la fois le code de l'utilisateur et celui de la bibliothèque

Pour notre cas, le meilleur moyen jusqu'à présent est le suivant, car tous nos packages ont /es/ , mais c'est fragile et peut ne pas convenir à d'autres projets :

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

Jest ne récupère pas ces packages sans transformation malgré type: module , comme vous l'avez dit.

Vous devrez transpiler l'import/export jusqu'à l'arrivée du support, à la fois le code de l'utilisateur et celui de la bibliothèque

Un calendrier approximatif à ce sujet ?
à partir de la version du nœud 14 :

Nous sommes convaincus que l'implémentation actuelle offre un modèle à l'épreuve du temps pour la création de modules ESM qui ouvre la voie à Universal JavaScript. S'il vous plaît lire plus dans notre documentation.

L'implémentation d'ESM dans Node.js est encore expérimentale, mais nous pensons que nous sommes sur le point de pouvoir appeler ESM dans Node.js « stable ». La suppression de l'avertissement est un grand pas dans cette direction.

en tant que tel, je suis réticent à exporter des packages NPM (qui peuvent très bien être consommés par des tests implémentant le framework de test JEST) en utilisant commonJS pendant beaucoup plus longtemps.

Nous livrons une version expérimentale de Jest 25.4. Quelques corrections de bugs dans 25.5, mais ce n'est toujours pas là où il devrait être. Vous pouvez suivre les progrès dans #9430