Réflexions initiales sur le dessus de ma tête, avant de faire d'autres recherches :

• Il me semble me rappeler que les gens de Node ont spécifiquement modifié la norme pour permettre la rétrocompatibilité avec les modules CommonJS. Si c'est (toujours?) vrai, alors je m'attendrais à ce qu'il soit finalement pris en charge sans avoir besoin de faire quoi que ce soit avec / vers Mocha. (Et par "éventuellement", je veux dire "peut-être encore plus vite que les changements de Mocha", étant donné le rythme du cycle de publication de Node ; voir l'avant-dernier souligné ci-dessous pour une explication plus détaillée de cela.)
• Puis-je supposer que cela a été exécuté comme node --experimental-modules node_modules/mocha/bin/_mocha ?
• Comment exactement .jsx est-il impliqué ? Je vois que l'exemple d'erreur affiché fait référence à .mjs ; on ne sait pas, d'après ce qui a été posté, où se trouve le jsx .
• Je me souviens aussi vaguement avoir entendu parler de la mise en œuvre initiale de Node nécessitant l'extension de fichier .mjs ; si c'est (toujours ?) vrai, et si vous essayez d'utiliser import / export avec un fichier .jsx (soit import $ avec un fichier .jsx Fichier .mjs ou chargement d'un fichier .jsx contenant import / export ), cela pourrait-il être le problème plutôt que Mocha ?
• Nous aurions besoin de trouver un moyen de garantir que les modifications apportées à la fonctionnalité expérimentale ne nécessitent pas de modifications de Mocha qui devraient attendre un semver majeur - sinon vous pourriez vous retrouver là où nous en sommes maintenant, sauf attendre encore plus longtemps (puisque le cycle de publication majeur de Mocha n'est pas verrouillé sur deux fois par an comme celui de Node).
• Parlant uniquement de mon propre avis et non au nom de l'équipe, si le nouveau format de module ne peut pas interagir avec l'ancien format de module sans modification des bibliothèques existantes écrites dans l'ancien format, alors le nouveau format de module n'est pas encore prêt .

Il me semble me rappeler que les gens de Node ont spécifiquement modifié la norme pour permettre la rétrocompatibilité avec les modules CommonJS. Si c'est (toujours?) vrai, alors je m'attendrais à ce qu'il soit finalement pris en charge sans avoir besoin de faire quoi que ce soit avec / vers Mocha. (Et par "éventuellement", je veux dire "peut-être encore plus vite que les changements de Mocha", étant donné le rythme du cycle de publication de Node ; voir l'avant-dernier souligné ci-dessous pour une explication plus détaillée de cela.)

D'après mes (petites) recherches, il semble qu'au moins pour l'instant, il est permis d'utiliser require partir d'un module ECMAScript mais pas import partir d'un module commonjs.

Puis-je supposer que cela a été exécuté comme node --experimental-modules node_modules/mocha/bin/_mocha ?
Comment exactement .jsx est-il impliqué ? Je vois que l'exemple d'erreur affiché fait référence à .mjs ; on ne sait pas, d'après ce qui a été posté, où se trouve le jsx.

Oui, il a été exécuté avec --experimental-modules . jsx est une faute de frappe, je voulais dire mjs , mettra à jour le message initial.

Je me souviens aussi vaguement avoir entendu parler de la mise en œuvre initiale de Node nécessitant l'extension de fichier .mjs ; si c'est (toujours ?) vrai, et si vous essayez d'utiliser l'importation/exportation avec un fichier .jsx (soit en important un fichier .jsx dans un fichier .mjs, soit en chargeant un fichier .jsx contenant l'importation/exportation), cela pourrait-il être le problème plutôt que Moka ?

Le problème semble être, et il me manque peut-être quelque chose ici, que moka utilise require pour charger le test (c'est du moins mon hypothèse actuelle car je ne suis pas un expert en moka, plus un utilisateur) qui alors inclut d'autres modules via import . Ceci en conjonction avec le premier point expliquerait l'erreur.

Nous aurions besoin de trouver un moyen de garantir que les modifications apportées à la fonctionnalité expérimentale ne nécessitent pas de modifications de Mocha qui devraient attendre un semver majeur - sinon vous pourriez vous retrouver là où nous en sommes maintenant, sauf attendre encore plus longtemps (puisque le cycle de publication majeur de Mocha n'est pas verrouillé sur deux fois par an comme celui de Node).
Parlant uniquement de mon propre avis et non au nom de l'équipe, si le nouveau format de module ne peut pas interagir avec l'ancien format de module sans modification des bibliothèques existantes écrites dans l'ancien format, alors le nouveau format de module n'est pas encore prêt.

J'avais peur que ce soit la réponse et je comprends que ce n'est pas une priorité absolue. Si mon hypothèse de la cause de l'erreur ci-dessus est correcte, quelque chose comme # 956 pourrait aider car le point d'entrée du test pourrait être un module mjs plutôt que commonjs, ce qui est probablement difficile à réaliser autrement. Il semble être sur la feuille de route de l'équipe nodejs de prendre en charge import partir des modules actuels, mais les délais ne sont pas clairs.

D'après mes (petites) recherches, il semble qu'au moins pour l'instant, il est permis d'utiliser require depuis un module ECMAScript mais pas d'importer depuis un module commonjs.

Il semble être sur la feuille de route de l'équipe nodejs de prendre en charge l'importation à partir des modules actuels, mais les délais ne sont pas clairs.

Pour clarifier : étant donné que dans les environnements "anciens" (dans certains cas non expérimentaux actuels) import est une erreur de syntaxe, qui ne peut être évitée avec une logique de branchement ou quelque chose comme ça, ce dont Mocha a besoin n'est pas pouvoir utiliser import lui-même mais plutôt pouvoir utiliser require pour charger des modules qui utilisent (ou qui utilisent des modules qui utilisent) le nouveau format.

jsx est une faute de frappe, je voulais dire mjs , mettra à jour le message initial.

Merci, cela élimine un angle possible !

Si mon hypothèse sur la cause de l'erreur ci-dessus est correcte, quelque chose comme # 956 pourrait aider car le point d'entrée du test pourrait être un module mjs plutôt que commonjs, ce qui est probablement difficile à réaliser autrement.

Faire en sorte que Mocha ne crée pas de variables globales n'est malheureusement pas possible sans une réécriture approfondie de certains des éléments internes les plus mystérieux (j'ai essayé et je n'ai pas pu le comprendre moi-même 😿 ); cependant, l'utilisation de votre propre point d'entrée JS est désormais possible via l'API "programmatique" (qui peut ne pas être documentée en dehors d' une ancienne page wiki et des commentaires JSDoc dans les fichiers source, mais qui est officiellement prise en charge) :

// test.mjs
var Mocha = require('mocha'),
var mocha = new Mocha();

// your mission: create a file `example.mjs`
// in the `test` folder and have it `import` stuff
// as well as using `describe` and `it` to make tests
mocha.addFile("./test/example.mjs");

mocha.run(function(failures){
  process.on('exit', function () {
    process.exit(failures ? 1 : 0);
  });
});

node --experimental-modules test.mjs

Je n'ai pas vraiment essayé cela pour voir si cela fait une différence (il faut d'abord récupérer la dernière version de Node), mais faites-moi savoir si cela fonctionne pour vous...

Tout d'abord merci pour votre soutien à ce sujet !

j'ai essayé ça

// runner.mjs
import Mocha from 'mocha';
var mocha = new Mocha();

// your mission: create a file `example.mjs`
// in the `test` folder and have it `import` stuff
// as well as using `describe` and `it` to make tests
mocha.addFile('./test/frontend/components/global/test.mjs');

mocha.run(function (failures) {
    process.on('exit', function () {
        process.exit(failures ? 1 : 0);
    });
});

Donc, fondamentalement, le point d'entrée du nœud est un module ECMAScript.

Je le lance via node --experimental-modules --harmony ./runner.mjs

Je reçois

(node:88620) ExperimentalWarning: The ESM module loader is experimental.
{ Error [ERR_REQUIRE_ESM]: Must use import to load ES Module: /.../test/frontend/components/global/test.mjs
    at Object.Module._extensions..mjs (module.js:658:11)
    at Module.load (module.js:545:32)
    at tryModuleLoad (module.js:508:12)
    at Function.Module._load (module.js:500:3)

ce dont Mocha a besoin n'est pas de pouvoir utiliser import lui-même mais plutôt de pouvoir utiliser require pour charger des modules qui utilisent (ou qui utilisent des modules qui utilisent) le nouveau format.

Je crains que ce ne soit actuellement pas possible dans node, vous ne pouvez utiliser require dans les modules que vous avez importés via import . Existe-t-il un moyen d'éviter mocha.addFile('./test/frontend/components/global/test.mjs'); et d'importer à la place le test et d'ajouter le script importé comme celui-ci

import test from './test';
mocha.addTest(test);

?

Il n'y a pas de fonction comme ça dans Mocha pour le moment, mais vous pouvez faire quelque chose dans ce sens. addFile ajoute simplement le fichier à une liste qui est plus tard require d par la fonction run . La fonction run appelle loadFiles à require :

https://github.com/mochajs/mocha/blob/1cc0fc0e6153bbd746b0c2da565363570432cdf7/lib/mocha.js#L220 -L235

Ce que vous voudriez faire, c'est pour tous les fichiers qui doivent être import ed au lieu de require d n'appelez pas addFile (pour que Mocha n'essaie pas de $#$8$# require sur run ) et à la place avant d'appeler run appeler un code qui ressemble à ce qu'il y a dans loadFiles mais en utilisant import au lieu de require . Je ne me souviens pas du haut de ma tête s'il existe des restrictions sur l'utilisation de import qui empêcheraient cela, mais si c'est possible, j'imagine que cela ressemblerait assez à:

modules.forEach(function (file) {
  file = path.resolve(file);
  mocha.suite.emit('pre-require', global, file, mocha);
  import fileExport from file; // fileExport is used by the exports interface, not sure if anything else; most interfaces act as a side effect of running the file
  mocha.suite.emit('require', fileExport, file, mocha);
  mocha.suite.emit('post-require', global, file, mocha);
});

Vous pouvez également voir comment https://github.com/mochajs/mocha/blob/master/bin/_mocha utilise l'API programmatique de Mocha pour avoir une idée de la façon de fournir d'autres options et comment utiliser des choses comme la fonctionnalité de recherche de fichiers de Mocha. Ce n'est pas très bien organisé mais tout ce que fait l'interface de ligne de commande est là (soit directement, soit parce qu'il y a un appel aux fonctions de l'API programmatique de Mocha).

Je peux aller plus loin, mais le test importé se plaint maintenant qu'il ne sait pas décrire ( ReferenceError: describe is not defined ). Quelle est la bonne façon de l'injecter? Si je fais

import Mocha from 'mocha';
const describe = Mocha.describe;

il se plaint TypeError: describe is not a function

Donc, ma distribution a finalement obtenu NodeJS 8.5, et j'ai eu la chance de jouer avec cela et de confirmer quelques intuitions que j'avais mais que je ne voulais pas déclarer avant d'avoir pu vérifier :

1. Je ne trouve aucun moyen de charger un module ES sans coder en dur son nom dans un fichier de script/module. Cela signifie que Mocha ne peut pas les charger via l'interface de ligne de commande, peu importe ce que nous faisons et quelle que soit la sémantique ES vs CommonJS. Si et quand cela change, nous voudrons le savoir, je suppose. (S'il change de telle sorte que le module ES puisse être chargé via une variable require , nous n'aurons probablement pas besoin de changer quoi que ce soit, mais je ne pense pas que nous puissions dire quoi que ce soit sur le fonctionnement des modules jusqu'à ce que cela se produise .)
2. Alors que Mocha configure l'interface dans l'émission d'événement pre-require (pas lors du premier chargement du module ; l'interface choisie est spécifique à l'instance new Mocha ), le nouveau système de module analyse en fait l'arbre de dépendance et charge les dépendances avant les modules qui en dépendent, donc la raison pour laquelle describe n'est pas défini est que Mocha ne le configure qu'après le chargement des modules de test. Cela signifie que cela va être alambiqué pour que cela se produise (encore une fois, à moins que et jusqu'à ce que require(file) soit autorisé et charge la dépendance à cette ligne spécifique, de préférence de manière synchrone afin que nous n'ayons rien à changer d'autre ).

Cependant, j'ai découvert que je pouvais le faire fonctionner en exploitant le fait que les modules import ed sont chargés dans l'ordre des appels import . (Cela deviendrait beaucoup plus redondant si vous utilisiez l'interface Exports ou un reporter qui a besoin du nom de chaque fichier individuel, comme décrit dans le code que je suis sur le point de lier, mais en principe cela fonctionne.) Si ce fait était changer sans qu'aucun des autres faits ci-dessus ne change, alors même cela ne serait pas possible du tout. Mais pour l'instant je pense que c'est ce que tu dois faire.

https://gist.github.com/anonymous/caba0883254a2349c5615df8e9286665

node --experimental-modules ./run.mjs

Malheureusement, je suis à peu près sûr que c'est le mieux que nous puissions faire étant donné la façon dont les modules ES fonctionnent et ce que Node permet à l'heure actuelle.

Pensez-y d'une autre manière :

• import est la syntaxe.
• require est une fonction.

Vous ne pouvez rien import dynamiquement, tout comme vous ne pouvez pas exécuter de code dynamiquement sans utiliser, par exemple, eval() .

Il y a cette proposition d'étape 3 qui permettrait ce comportement, mais je ne sais pas si des runtimes l'expédient encore.

En tant que tel, il n'y a aucun moyen pour Mocha d'importer un fichier .mjs lors de l'exécution via mocha sans ajouter peut-être @std/esm et en utilisant son implémentation require pour les fichiers avec le .mjs Rallonge peut être une solution viable et quelque chose que nous pourrions envisager de soutenir, mais une discussion (et un tel PR) devrait probablement venir de la communauté, au moins jusqu'à ce que ce comportement ne soit pas derrière un drapeau.

import describe from 'mocha' est assez bas sur la liste des priorités, malheureusement, en raison de la difficulté inhérente à ce genre de chose (#956). Mieux vaut courir avec node et s'en tenir à la consommation des globales.

En fait, il me semble que nous pourrions charger les tests et tirer parti vm.runInContext , en supposant qu'une telle chose prend en charge les modules. Étant donné que le comportement de chargement de Node est lié à l'extension .mjs et que vm.runInContext attend une chaîne , vous ne voyez pas comment cela pourrait se produire - et rien n'est mentionné à ce sujet dans la documentation. Peut-être un problème quelque part ?

(encore une fois, c'est peut-être exactement ce que @std/esm fait sous le capot !)

J'ai des tests moka qui fonctionnent sans transpiler dans un navigateur . Peut-être que cela aide pour ce problème.

cela n'a aucun rapport car vous n'utilisez pas moka en tant que module, mais plutôt en tant que script ...

désolé moi-même confus. c'est différent dans un navigateur.

Je veux peser avec un vote de soutien pour faire quelque chose pour permettre à Mocha d'exécuter des tests situés dans un module ES. J'ai atterri ici après avoir essayé d'écrire un tel test et obtenu une erreur bizarre du chargeur de module Node.js. J'utilise Node.js 9.5, qui prend en charge nativement les modules ES6.

Dans l'état actuel des choses, Node.js 9.5 n'autorise pas un module CommonJS à exiger () un module ES6. Peut-être qu'ils travaillent dans le sens de permettre cela, je ne sais pas.

J'ai écrit le test en tant que module ES6 avec l'extension .mjs et j'ai essayé de l'exécuter. J'ai eu l'erreur du chargeur - je suppose que la commande mocha entraîne l'utilisation require() et c'est pourquoi elle a échoué.

Refait le test avec l'extension .js et essayait d'utiliser require() pour charger le module qui devait être testé. Cela a également obtenu l'erreur du chargeur.

Je suis d'avis que le monde Node.js doit réfléchir à la manière dont il va passer aux modules ES6 et les prendre en charge. Étant donné que Mocha est un outil très populaire dans ce monde, il serait préférable que l'équipe Mocha réfléchisse à la manière de prendre en charge les modules ES6.

Pour continuer ... Après quelques réflexions et recherches, j'ai pu faire fonctionner cette séquence comme solution de contournement.

Nommez le script de test avec l'extension .js (ce qui en fait un script CommonJS)

Ajoutez ensuite ceci dans le script de test :

require = require("@std/esm")(module,{"esm":"js"});

Ensuite, je peux require() un module ES comme suit :

const model = require('../models/notes');

@robogeek Ou il pourrait être encore mieux d'utiliser le préchargeur @std/esm partir de la ligne de commande, de sorte que vous n'ayez pas à encombrer vos fichiers de spécifications avec des solutions de contournement et que vous puissiez avoir des extensions .mjs .

mocha -r @std/esm spec.mjs

L'importation dynamique est livrée avec le nœud v9.6 derrière le drapeau --harmony-dynamic-import . Les importations dynamiques permettent à mocha de charger les tests contenus dans les modules es6 sans avoir besoin d'un transpileur.

@harrysarson Cela ne fonctionnera pas immédiatement. Mocha utilise des modules cjs et require , vous devrez écrire les fichiers de test à l'aide de cjs, avec du code de colle supplémentaire pour gérer la nature asynchrone de import . Ou est-ce que je manque quelque chose?

Je suis un bot qui surveille les problèmes d'inactivité.
Ce problème n'a pas eu d'activité récente et je l'appelle stale . Dans 14 jours, s'il n'y a plus de commentaires ou d'activité, je fermerai ce sujet.
Merci d'avoir contribué à Mocha !

Le problème est toujours d'actualité mais repose sur la prise en charge native d'ESM. Les navigateurs l'ont, Node pas encore.

J'étais juste en train de jouer, de me familiariser avec ESM/.mjs et j'ai décidé que j'avais besoin de tests pour mon jouet. Réalisant que mocha ne prend pas encore officiellement en charge les fichiers .mjs , j'ai parcouru ensemble un module intermédiaire rapide (jusqu'à ce que quelqu'un ait le temps d'ajouter un support complet à mocha):

https://www.npmjs.com/package/mocha-esm
Relations publiques/problèmes bienvenus : https://github.com/stefanpenner/mocha-esm

Il y avait peut-être quelque chose de mieux, mais c'était amusant de vivre ensemble. donc \o/

J'ai décidé de bifurquer mocha lui-même pour prendre en charge les importations dynamiques (sur la base de certaines idées ci-dessus, mais je n'ai pas pu le faire fonctionner d'une autre manière).

Cela signifie que vous pouvez exécuter en utilisant par exemple node --experimental-modules --harmony-dynamic-import test.mjs

Puis dans test.mjs :

import 'should';
import Mocha from 'mocha';

const mocha = new Mocha();

mocha.addFile(() => import("./some-module.spec.mjs"));

mocha.run(failures => {
  process.on('exit', function () {
    process.exit(failures ? 1 : 0);
  });
});

J'ai gardé les changements dans moka pour supporter ce minimum , et je n'ai pas eu le temps de l'intégrer correctement pour un potentiel PR ni d'ajouter un module npm spécialisé, mais vous pouvez installer ce fork directement depuis github "mocha": "git+https://[email protected]/odolha/mocha" .

Notez que vous pouvez utiliser cette approche pour charger des fichiers de la manière asynchrone que vous souhaitez, pas seulement via une importation dynamique, car mocha attend une fonction qui fournit une promesse.

ÉDITER

J'ai oublié de mentionner que vos tests ne peuvent pas être de purs scripts avec cette approche, car nous ne pouvons pas injecter de contexte, vous devrez donc :

// some-module.psec.mjs
export const test = ({ describe, it }) => {
  describe('Something', () => {
    it('works', () => {
      ...
}

@odolha
Merci d'avoir lié votre fork.
Il y avait déjà un PR pour supporter l'ESM natif mais il a été fermé car le support des modules est encore expérimental.

Votre implémentation me conforte dans le fait que l'ajout d'un support pour cela devrait être facile. Nous sommes nombreux à attendre cette fonctionnalité avec impatience :)

@demurgos :no_mouth: ouais... Je viens de voir ce PR après avoir fait mon propre truc, d'oh 😃.

@harrysarson @boneskull
Le package esm (anciennement nommé @std/esm ) a supprimé les fichiers de support .mjs dans ce commit .
Cela signifie qu'il n'est plus possible de l'utiliser avec Mocha pour tester des fichiers .mjs . Ceci est discuté dans ce numéro .

Je veux toujours pouvoir tester les modules ES afin de pouvoir les exécuter en toute sécurité dans Node ou dans les navigateurs.

En ce qui concerne les discussions actuelles sur le module, il y a consensus sur le fait que .mjs devrait être disponible dans le résultat final (peut-être pas comme la seule solution, mais au moins disponible) et que import("./foo.mjs") renverra une promesse pour le espace de noms ES correspondant. Le fait que les modules CJS soient convertis en un module avec une exportation default correspondant à module.exports est plus débattu, mais cela semble être une hypothèse sûre.

Serait-il possible de reconsidérer l'ajout d'un support ES natif à l'aide de import dynamiques à Mocha ? L'indicateur de fonctionnalité pourrait être renommé en --experimental-es-modules (à partir de #3253) pour mieux signaler que cela dépend de l'avancement actuel du support de Node.
Selon les délais, la spécification finale n'atterrirait pas avant le nœud 12, donc l'implémentation actuelle y restera pendant un certain temps (et est un sous-ensemble relativement sûr de la proposition finale).

@demurgos Personnellement , je préfère attendre un peu plus avant de m'engager dans des implémentations de code sur moka. Mais peut-être que @boneskull ou @ScottFreeCode ne sont pas d'accord ?

@demurgos

Le package esm (anciennement nommé @std/esm) a supprimé les fichiers de support .mjs dans ce commit.

Le chargeur esm n'a pas abandonné la prise en charge de .mjs . Nous suivons simplement l'implémentation actuelle --experimental-modules et renvoyons une erreur lors de la tentative de chargement .mjs avec require . Les utilisateurs peuvent toujours utiliser un fichier .js pour leur fichier d'entrée de test qui utilise la syntaxe ESM ou import() dynamique pour charger les fichiers de test suivants de .mjs ou .js , beaucoup comme esm fait pour ses propres tests .

Selon les délais, la spécification finale n'atterrirait pas avant le nœud 12, donc l'implémentation actuelle y restera pendant un certain temps

Il n'y a pas de temps défini pour que --experimental-modules atterrisse sans drapeau. L'espoir est qu'il puisse atterrir dans le cycle de support du nœud 10 _ (donc dans les 2 prochaines années) _ mais rien n'est gravé dans le marbre.

(et est un sous-ensemble relativement sûr de la proposition finale).

L'implémentation actuelle --experimental-modules peut ne pas être compatible avec la proposition finale. Il y a plusieurs discussions autour de ce à quoi ressemblera le support ESM dans Node. Certaines directions proposées ne sont pas compatibles avec la mise en œuvre expérimentale actuelle. En fonction de la manière dont les choses évoluent, le code que vous écrivez aujourd'hui pour --experimental-modules peut ne pas fonctionner quelle que soit la forme finale.

Le chargeur esm n'a pas abandonné la prise en charge de .mjs.

Mon point est que esm ne permet plus d'exiger .mjs donc vous ne pouvez plus utiliser la découverte de test de Mocha pour .mjs . Mais vous avez raison, ce n'était pas documenté, donc ce n'est pas vraiment un changement radical, même si d'autres personnes s'en sont appuyées.

En ce qui concerne les délais, je parlais de cette question . Il semble y avoir une tentative pour le nœud 11 et une implémentation finale pour le nœud 12 afin qu'il puisse être porté sur le nœud 10 LTS. Certains souhaitent que cela se produise plus tôt, d'autres ont averti de ne pas se précipiter.

Ma proposition est de fusionner #3253. Cela offre uniquement un mécanisme opt-in pour utiliser import(...) au lieu de require pour charger les cas de test. Comme je m'attends à ce qu'il soit principalement appliqué pour .mjs dans le contexte de --experimental-modules , je pense toujours que c'est sûr. (l'importation dynamique de .mjs renvoyant une promesse d'espace de noms est susceptible de rester). Mais je vous laisse décider si vous pouvez le fusionner et éviter de trop pousser pour cela.

Encore une fois, la raison principale de ce PR est que sans lui, vous ne pouvez plus utiliser la découverte de test de Mocha mais devez utiliser la solution de contournement décrite ci-dessus par @jdalton. ( .js point d'entrée et importations manuelles)

Ma proposition est de fusionner #3253.

3253 avait quelques défauts n'est certainement pas une bonne idée de le fusionner tel quel.

Suivant l'exemple de @jdalton , j'ai configuré un petit workflow pour tester l'ESM natif sans le package esm (pur Node + Mocha).
J'utilise des définitions de test asynchrones (en utilisant --delay ) et --experimental-modules .

Actuellement, _mocha_ ne peut importer que CJS, et CJS ne peut importer qu'ESM en utilisant la pseudo-fonction dynamique import() . Je génère donc le point d'entrée CJS suivant (son nom se termine par .js ) qui importe les fichiers de spécification et déclenche l'exécution du test :

test.esm.js :

(async () => {
  await import("./test/a.spec.mjs");
  await import("./test/b.spec.mjs");
  run();
})();

(Je génère le point d'entrée avec la liste des importations au moment de la construction, mais vous pouvez l'écrire manuellement ou utiliser glob ici.)

Je l'exécute ensuite avec la commande suivante :

NODE_OPTIONS="--experimental-modules" mocha --delay build/test/test.esm.js

Je dois passer par NODE_OPTIONS car le drapeau n'est pas reconnu par mocha.

J'espère toujours que moka fournirait un meilleur support pour l'ESM expérimental, mais au moins c'est bien de savoir qu'il existe un moyen de l'utiliser aujourd'hui sans autres outils.

@demurgos c'est une jolie petite solution de contournement que vous avez trouvée :+1:.

Il est bon de voir qu'il est effectivement possible (sinon facile) d'utiliser es modules avec moka : sourire:.

@demurgos Ce problème concerne la prise en charge des tests de style ES6 sans utilisation du transpiler . Qu'est-ce que le "temps de construction" ? Ce code que vous utilisez pour générer les points d'entrée de test est un transpileur, juste un spécialisé.

@rulatir
J'ai mentionné que j'utilisais des outils de construction, mais ils ne sont pas au niveau discuté dans ce numéro : Mocha fonctionne avec ESM natif, et non ESM réduit à CJS par un transpileur.

Voir mon message :

Je génère le point d'entrée avec la liste des importations au moment de la construction, mais vous pouvez l'écrire manuellement ou utiliser glob ici.

J'ai utilisé une étape de construction parce que je veux que mes importations soient (1) définies statiquement et (2) ne maintiennent pas la liste moi-même.

Si vous n'avez que quelques fichiers de spécifications, supprimer (2) convient : ayez simplement un point d'entrée pour importer vos fichiers de spécifications 1-2.
(1) est déjà une exigence spécifique pour les fichiers de test, donc c'est surtout une chose "agréable à avoir" et vous pouvez utiliser glob au moment de l'exécution (au lieu du temps de construction comme moi). Ce n'est qu'un détail qui n'a finalement aucune importance une fois que l'on a compris l'idée de base.

Si vous voulez juste quelque chose comme une simple solution de copier-coller pour trouver les fichiers de spécification mjs au moment de l'exécution, voici un exemple :

const {sync: globSync} = require("glob");

(async () => {
  const matches = globSync("**/*.spec.mjs");
  for (const match of matches) {
    await import(match);
  }
  run();
})();

Exécutez-le avec NODE_OPTIONS="--experimental-modules" mocha --delay test.esm.js .
Comme vous le voyez, pas de build du tout, mais un peu plus de bruit dans le code.

Je suis un bot qui surveille les problèmes d'inactivité.
Ce problème n'a pas eu d'activité récente et je l'appelle stale . Dans 14 jours, s'il n'y a plus de commentaires ou d'activité, je fermerai ce sujet.
Merci d'avoir contribué à Mocha !

Ce problème est toujours d'actualité et ne doit pas être clos.

La prochaine version mocha@6 aura le drapeau --experimental-modules liste blanche permettant d'expérimenter plus facilement les modules ES6. Serait-il possible d'avoir une version mineure ou un patch avant la v6 ? Je suis actuellement en train de finaliser un nouvel outil de couverture qui utilise le débogueur V8 au lieu d'Istanbul et j'aimerais le tester avec les modules Mocha et ES6 (sans avoir à utiliser une dépendance git dans mon package.json).

@demurgos

Quand j'essaie comme ça...

const {sync: globSync} = require("glob");
(async () => {
    const matches = globSync("**/*.spec.mjs");
    for (const match of matches) {
        await import(match);
    }
    run();
})();

Je reçois

(node:4632) UnhandledPromiseRejectionWarning: Error: Cannot find module test/Sanity.spec.mjs

Mais quand je cours comme ça...

const {sync: globSync} = require("glob");
(async () => {
    await import("./Sanity.spec.mjs");
    run();
})();

Il fonctionne parfaitement, qu'est-ce que je rate ?

@demurgos vous devez vous coordonner avec @bcoe ; voir https://github.com/bcoe/c8

@demurgos pour couper une version mineure, nous aurions besoin de sélectionner toutes les modifications sans rupture depuis la v5.2.0 dans une branche et de les compiler dans le CHANGELOG. si vous ou quelqu'un d'autre êtes prêt à faire ce travail, nous pouvons couper la publication.

fwiw je recommande esm sur --experimental-modules jusqu'à ce que Node.js ait son histoire droite. ce sera une attente considérable.

@boneskull
Haha merci. Je travaille déjà autour c8 depuis juillet (j'ai ouvert un tas de relations publiques et de problèmes sur ce repo). Il y a aussi certaines décisions de conception où nous ne sommes pas d'accord, nous essayons donc de partager la plupart des dépendances (j'ai écrit l'algorithme de fusion par exemple) et avons décidé de publier un autre outil : c88 . Je l'ai fait fonctionner ce week-end et je le teste maintenant sur mes bibliothèques. Je suis capable de l'utiliser avec ESM natif et moka en CI. J'ai encore besoin de temps pour le documenter et le corriger mais il devrait être prêt en janvier).

@jrgleason
J'ai écrit le code ci-dessus du haut de ma tête. Il semble que le problème ici est que globSync renvoie des chemins relatifs qui ne commencent pas par ./ ou ../ . Vous voudrez peut-être le faire précéder de ./ : cela devrait fonctionner avec des chemins relatifs simples.
Notez également que les importations dynamiques utilisent des URL relatives : # , ? et d'autres caractères spéciaux peuvent être traités différemment. Si vous voulez une solution solide comme le roc, vous devez résoudre le chemin absolu du module, puis le convertir en URL de fichier. Dans le cadre de mon travail sur la couverture, j'ai écrit une bibliothèque pour convertir entre les chemins absolus et les URL : vous pouvez utiliser fromSysPath from furi . Les conversions doivent gérer tout type de chemin (même les espaces de noms Windows et les chemins UNC...).

Voici à quoi un exemple complet peut ressembler :

const {fromSysPath} = require("furi");
const {sync: globSync} = require("glob");
const {resolve} = require("path");

(async () => {
    const matches = globSync("**/*.spec.mjs");
    for (const match of matches) {
        await import(fromSysPath(resolve(match)).href);
    }
    run();
})();

Je veux dire, est-ce que mocha --require esm ne marche pas ? Avons-nous vraiment besoin d'une détection automatique ? Cela semble difficile et ajoute des frais généraux...

@demurgos pour couper une version mineure, nous aurions besoin de sélectionner toutes les modifications sans rupture depuis la v5.2.0 dans une branche et de les compiler dans le CHANGELOG. si vous ou quelqu'un d'autre êtes prêt à faire ce travail, nous pouvons couper la publication.

Merci pour la proposition. Il est toujours possible d'obtenir --experimental-modules avec NODE_OPTIONS donc ce n'est pas une priorité élevée (et cela peut compliquer l'arborescence git pour sélectionner les commits). Si je parviens à résoudre les problèmes que j'ai avec d'autres dépendances, je verrai si je peux passer du temps là-dessus. En attendant, je garde juste un œil sur le jalon v6.

fwiw, je recommande esm sur --experimental-modules jusqu'à ce que Node.js ait son histoire claire. ce sera une attente considérable.
Je veux dire, moka --require esm ne fonctionne-t-il pas?

Je suis tout à fait d'accord que c'est la meilleure solution en ce moment : c'est la solution la plus facile à mettre en place et qui est sortie depuis un certain temps : ça marche. Dans mon cas, je maintiens mes propres outils de construction et je gère l'ESM natif comme une alternative aux constructions CJS classiques. Bien que j'aie vraiment envie d'ESM natif, je recommande toujours de ne pas l'utiliser comme seul moyen d'exécuter votre code : c'est expérimental après tout :stuck_out_ tongue:.

La plupart de mes messages récents concernent le partage de ce qui peut être fait en utilisant l'ESM natif. Il s'agit principalement d'un travail expérimental et je m'attends à devoir le modifier lorsque l'ESM de Node sera stable. À long terme, il y a des avantages à avoir une solution qui ne nécessite pas le package esm . Voici mes raisons :

• Il réduit la quantité d'outils nécessaires (complexité moindre, moins de configuration à comprendre)
• Il peut y avoir quelques différences entre l'ESM réel et esm autour des cas extrêmes (erreurs d'évaluation, cycles, erreurs de chargement, modules asynchrones/dynamiques, wasm, etc.). Lors de l'écriture de code isomorphe, il peut être plus sûr de réduire toute source possible de divergence de comportement. Ceci est également un peu lié à la couverture native : avec esm , V8 voit la sortie transpilée, vous devez donc gérer les cartes source (pas encore pris en charge par c8 , mais je prépare un PR, ils travaillent sur c88 ). D'autres différences peuvent également apparaître lors du débogage.
• Cela évite d'avoir à transpiler dynamiquement le code et contribue à améliorer les performances.

Avons-nous vraiment besoin d'une détection automatique ? Cela semble difficile et ajoute des frais généraux...

Je ne sais pas à quelle détection automatique vous faites référence. Est-ce lié au PR qui a été envoyé plus tôt cette année ?

Edit : je suis aussi sur le Node tooling Slack (principalement actif sur le canal #c8 ) si vous voulez discuter.

@demurgos Je pense que j'étais un peu confus quant à ce que les gens voulaient ici. En tous cas...

Si NODE_OPTIONS=--experimental-modules fonctionne jusqu'à ce que --experimental-modules soit pris en charge dans Mocha v6.0.0, y a-t-il d'autres travaux à effectuer pour ce problème ? C'est ce qui me manque.

Je m'attends à ce que ce problème reste ouvert jusqu'à ce que l'ESM natif ("tests de style ES6 sans utilisation de transpiler") fonctionne immédiatement / aussi facilement que CJS fonctionne actuellement.

La solution que j'ai publiée avec --delay et NODE_OPTIONS=--experimental-modules est plus une solution de contournement qu'un support approprié. Je considérerais ce problème comme résolu une fois que vous pourrez exécuter mocha **/*.spec.mjs et obtenir un rapport.

Malheureusement, pour le moment, je pense que nous devons encore attendre que Node comprenne le support ESM. Je devrais vérifier, mais je pense que le PR n'a pas utilisé la détection automatique mais a simplement importé chaque module (CJS ou ESM) en utilisant des importations dynamiques. L'implémentation dépendra de l'histoire d'interopérabilité des modules.

Edit : je fais référence à https://github.com/mochajs/mocha/pull/3253. Il permet de charger tous les modules comme ESM (pas de détection automatique).

Je suis un bot qui surveille les problèmes d'inactivité.
Ce problème n'a pas eu d'activité récente et je l'appelle stale . Dans 14 jours, s'il n'y a plus de commentaires ou d'activité, je fermerai ce sujet.
Merci d'avoir contribué à Mocha !

Le nœud 12 doit inclure la nouvelle implémentation ESM. Ce sera l'occasion de vérifier comment supporter les modules ES dans Mocha.

J'ai rencontré un bogue GC lors de l'utilisation de Mocha un ESM, mais il est signalé et confirmé, il devrait donc être corrigé : https://github.com/nodejs/node/issues/27492.

A côté de ce bogue, la stratégie décrite dans mon commentaire ci-dessus fonctionne toujours pour utiliser Mocha avec ESM.

Salut les gens de Mocha, merci d'avoir créé et maintenu un bel outil !

Ce n'est qu'un commentaire pour info. Au cours des derniers mois, j'ai travaillé sur Mocha et * -test.mjs , en utilisant les correctifs ci-dessous. Il n'y a presque aucun problème pour exécuter mocha test/*.mjs (sans transpiler ou module esm npm).
https://gist.github.com/tadd/756d21bad38933c179f10e59bddee6b4

Bien sûr, ce patch n'est pas "prêt pour la production" pour les committers Mocha ; ce n'est qu'un hack pour les utilisateurs de Mocha qui souhaitent utiliser ESM dans les codes de test dès que possible.
J'ai utilisé Node.js v11 avec l'option --experimental-modules . Actuellement, je suis avec v12 et fonctionne également.

C'est une autre histoire, mais Node v12 a introduit l'extension $# .cjs 4$#$ et le champ "type" dans package.json . Il semble que ceux-ci doivent également être pris en compte.

Salut les gens de Mocha, merci d'avoir créé et maintenu un bel outil !

En effet, et je voudrais aussi rendre grâce 😄

J'ai adopté une approche différente pour que loadFiles reste synchrone, voir ci-dessous. Cela a fonctionné pour moi depuis février. Contrairement à certains autres hacks, cela permet toujours tous les drapeaux, inspect/devtools et une couverture de code précise à l'aide de c8 . Cette dernière fonctionnalité est la raison pour laquelle j'ai vraiment besoin d'ESM natif, car le package esm a des décalages différents pour chaque fichier. (Les exportations du module sont répertoriées et déroutantes à Istanbul).

https://gist.github.com/maxnordlund/a860dd67013beaf0f31ce776536f0a47

Bonjour! Ceci est également nécessaire pour tester tout code qui dépend du projet natif ES6, par exemple lit-element . Sinon, ça lance comme ça :

node_modules/lit-element/lit-element.js:14
import { TemplateResult } from 'lit-html';
       ^

SyntaxError: Unexpected token {
    at Module._compile (internal/modules/cjs/loader.js:703:23)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:770:10)
    at Module.load (internal/modules/cjs/loader.js:628:32)
    at Function.Module._load (internal/modules/cjs/loader.js:555:12)
    at Module.require (internal/modules/cjs/loader.js:666:19)
    at require (internal/modules/cjs/helpers.js:16:16)
    ...

Je ne sais pas s'il existe une solution de contournement pour cela, mais actuellement je ne pense pas qu'il existe un moyen d'utiliser Mocha avec le framework natif ES6.

@heruan J'ai posté une solution fonctionnant depuis Node 8 dans les commentaires ci-dessus. Voici une version mise à jour qui nécessite Node 10.12 pour les conversions d'URL de fichiers natifs :

Ajoutez le fichier test.esm.js suivant :

const {pathToFileURL} = require("url");
const {sync: globSync} = require("glob");
const {resolve} = require("path");

(async () => {
    const matches = globSync("**/*.spec.mjs"); // Change the glob to match your test files
    for (const match of matches) {
        await import(pathToFileURL(resolve(match)).href);
    }
    run();
})();

Lancez ensuite les tests avec mocha --experimental-modules --delay test.esm.js .

Ce code fonctionne en utilisant test.esm.js comme pont commonjs pour charger les tests ESM.

Le nœud 12 a un problème signalé où l'IIAFE est collecté par le GC (nodejs/node#27492), il devrait être corrigé dans l'une des prochaines versions mineures (il peut y avoir des solutions de contournement mais je ne les ai pas encore examinées). Je recommande d'utiliser la dernière version de Node 10 jusqu'à ce qu'elle soit corrigée.

Thar déclenchera un avertissement UnhandledPromiseRejectionWarning en cas d'erreur. Mieux vaut enchaîner un console.error ou autrement gérer l'erreur.

import glob from "glob"
import { pathToFileURL } from "url"
import { resolve } from "path"
import { promisify } from "util"

const globAsync = promisify(glob)

async function main() {
  const matches = await glob("test/**/*.mjs")

  for (const match of matches) {
    await import(pathToFileURL(resolve(match)).href)
  }

  run()
}

main().catch(console.error)

_Je sais que cela utilise import sur require , mais voyez mon essentiel pour une solution qui vous permet de rester dans le pays ESM_

@demurgos Merci pour l'extrait de code pour Node 10.12 que vous avez posté il y a dix jours !

J'utilise Node 12.1 et cela semble bien fonctionner. Cela sera-t-il bientôt ajouté à Mocha, ou existe-t-il un moyen encore plus simple de le faire avec Node 12 ? Aussi, comment puis-je l'utiliser en mode --watch ?

https://github.com/standard-things/esm semble fonctionner avec --require esm , mais ce serait bien d'abandonner une autre dépendance :) Merci.

Si Mocha devait passer à l'ESM en source, Rollup pourrait fournir un fichier de distribution ESM ainsi qu'un CommonJS et/ou UMD.

Un autre avantage ici est que le HTML du navigateur n'aurait pas besoin d'être pollué avec des balises de script supplémentaires pour extraire Mocha. Les fichiers de test (ou le fichier d'entrée de test principal) pourraient effectuer l'importation (et éviter la "magie" dans les fichiers de test en ce qui concerne la détermination de la provenance des variables - il suffit de tracer les chemins d'importation).

On peut également utiliser des plugins CSS pour Rollup pour permettre l'injection mocha.css , minimisant davantage le besoin d'encombrement HTML.

Je suis un bot qui surveille les problèmes d'inactivité.
Ce problème n'a pas eu d'activité récente et je l'appelle stale . Dans 14 jours, s'il n'y a plus de commentaires ou d'activité, je fermerai ce sujet.
Merci d'avoir contribué à Mocha !

Je pense que c'est toujours d'actualité.

Quelqu'un a-t-il pu exécuter Mocha avec des modules ES6 sur (edit : ~Travis~) Node > = 12.11.0 ?
Le 12.10.0 semble-t-il, je l'ai configuré avec succès :
moka-run.js

(async () => {
    await import("./tests.js");
    run();
})();

Alors mocha --experimental-modules --delay ./mocha-run.js fonctionne comme un charme.

Mais pour une raison inconnue, le 12.11.0, il se comporte comme s'il n'y avait pas de paramètre --delay :

>  mocha --experimental-modules --delay ./mocha-run.js

(node:6439) ExperimentalWarning: The ESM module loader is experimental.

internal/modules/cjs/loader.js:1007

      internalBinding('errors').triggerUncaughtException(

                                ^

Error [ERR_REQUIRE_ESM]: Must use import to load ES Module: /home/travis/build/Palindrom/Palindrom/mocha-run.js

@tomalec J'exécute mocha avec des modules ES sur le nœud 12.11.1 :

__mocha-run.js__

(async () => {
    await import("./tests.mjs");
    run();
})();

Cependant, le mode montre ne fonctionne pas. mocha attend les modifications de fichier, mais n'exécute pas un autre test après la modification d'un fichier.

@vanslly Vous avez de la chance ;)
Pour moi avec Node 12.12.0 (https://travis-ci.org/Palindrom/Palindrom/builds/597771311#L450) et mocha-run.js comme vous l'avez suggéré ci-dessus (https://github.com/Palindrom/ Palindrom/commit/49835962bdd61c849f115e271bbc6c3f82d30511#diff-24eabf03aee8844b2b4747aa95a6af7d),

mocha --experimental-modules --delay test/mocha-run.js https://travis-ci.org/Palindrom/Palindrom/builds/597771311#L643 , , lance toujours la même erreur

Que ce soit toujours un problème, c'est fou ! ESM n'est plus caché derrière --experimental-modules. C'est l'avenir.

euh, en fait, ça vient d'être annoncé il y a quelques jours...

Trop tard, nous sommes tous passés à Jest.

Hé les gars, je veux juste m'assurer que cela est maintenu en vie. S'il vous plaît, faites-en une priorité absolue et merci pour tout votre excellent travail !

@luijar Ceci est en cours d'élaboration au # 4038

Nous avons publié hier une version expérimentale v7.0.0-esm1 : voir les notes de version .

C'est super à voir !

Puis-je demander cependant - le manque de référence au navigateur signifie-t-il que l'utilisation d'ESM n'est pas disponible sur le navigateur ou simplement que vous n'avez pas eu besoin de spécifier les versions du navigateur comme avec Node. Je pense qu'il pourrait être utile de mentionner dans les notes de version le statut des navigateurs (et s'ils ne sont pas pris en charge, quels pourraient être les plans pour leur prise en charge).

@brettz9
NodeJs ESM n'affecte en rien le navigateur Mocha. Les tests que vous exécutez dans votre navigateur ne sont pas chargés par NodeJs, vous devez le faire vous-même dans votre code HTML.

Si je me souviens bien, vous devez définir la balise $# <script> type="module" l'attribut type="module". Pour vos fichiers de test et pour le script Mocha, afin de conserver la séquence de chargement. ESM aurait dû fonctionner avec le navigateur pendant des années.

@juergba : oui, bien sûr, mais il faut un fichier de distribution d'exportation ESM pour pouvoir utiliser comme import mocha from '../node_modules/mocha/mocha-esm.js'; sans compilation - et pour ceux qui utilisent la compilation (par exemple, pour pouvoir simplement utiliser import mocha from 'mocha'; ), ils voudraient module dans package.json pour que les bundlers puissent découvrir automatiquement la version ESM.

moka est écrit en commonjs; nous ne pouvons pas mettre un champ "module" dans package.json. Mocha prendra en charge l'exécution de tests dans un nœud écrit en ESM.

Si vous ne vouliez pas refactoriser pour utiliser ESM en interne, vous devriez toujours pouvoir utiliser Rollup avec son plugin CommonJS et indiquer le fichier cible ESM afin de prendre en charge module (comme les offres Sinon et la plupart des packages de note que j'ai rencontré, jQuery étant la seule autre exception notable et ils ont refactorisé pour utiliser ESM).

J'ai créé un exemple de projet pour tester moka avec ESM. Je peux exécuter les tests avec succès, mais je n'ai pas (_encore_) pu exécuter la couverture avec nyc/istanbul. Votre aide sera la bienvenue.

@concatime Jusqu'à ce que nyc soit rendu compatible, vous pouvez utiliser c8 : https://www.npmjs.com/package/c8

c8 --all --include=lib/**/*.js --reporter=lcovonly node_modules/.bin/mocha --recursive

@cedx J'ai mis à jour mon référentiel de modèles et cela fonctionne. Soigné!

Nous avons implémenté le support ESM natif de Node dans Mocha v7.1.0.