Erste Gedanken aus dem Kopf, bevor ich weiter recherchiere:

• Ich erinnere mich, dass die Node-Leute den Standard speziell geändert haben, um eine Abwärtskompatibilität mit CommonJS-Modulen zu ermöglichen. Wenn das (immer noch?) wahr ist, dann würde ich erwarten , dass es schließlich unterstützt wird, ohne dass irgendetwas mit/mit Mocha zu tun haben muss. (Und mit „irgendwann“ meine ich „möglicherweise sogar schneller als Mocha-Änderungen“, angesichts der Geschwindigkeit des Veröffentlichungszyklus von Node; siehe das hervorgehobene, vorletzte unten für eine detailliertere Erklärung dazu.)
• Kann ich davon ausgehen, dass dies wie node --experimental-modules node_modules/mocha/bin/_mocha ausgeführt wurde?
• Wie genau ist .jsx beteiligt? Ich sehe, dass sich das gezeigte Fehlerbeispiel auf .mjs bezieht; Es ist unklar, was gepostet wurde, wo sich die jsx befinden.
• Ich erinnere mich auch vage daran, von der ersten Implementierung von Node gehört zu haben, die die Dateierweiterung .mjs erforderte; wenn das (immer noch?) stimmt, und wenn Sie versuchen, import / export mit einer .jsx -Datei zu verwenden (entweder import eine .jsx -Datei in .mjs -Datei oder Laden einer .jsx -Datei, die import / export enthält), könnte das eher das Problem sein als Mocha?
• Wir müssten einen Weg finden, um sicherzustellen, dass Änderungen an der experimentellen Funktion keine Änderungen an Mocha erfordern, die auf ein Semver Major warten müssten – andernfalls könnten Sie genau dort landen, wo wir jetzt sind, außer noch länger zu warten (da der Hauptveröffentlichungszyklus von Mocha nicht wie der von Node auf zweimal im Jahr festgelegt ist).
• Ich spreche nur von meiner eigenen Meinung und nicht im Namen des Teams, wenn das neue Modulformat nicht mit dem alten Modulformat zusammenarbeiten kann, ohne Änderungen an bestehenden Bibliotheken vorzunehmen, die im alten Format geschrieben wurden, dann ist das neue Modulformat noch nicht fertig .

Ich erinnere mich, dass die Node-Leute den Standard speziell geändert haben, um eine Abwärtskompatibilität mit CommonJS-Modulen zu ermöglichen. Wenn das (immer noch?) wahr ist, dann würde ich erwarten, dass es schließlich unterstützt wird, ohne dass irgendetwas mit/mit Mocha zu tun haben muss. (Und mit „irgendwann“ meine ich „möglicherweise sogar schneller als Mocha-Änderungen“, angesichts der Geschwindigkeit des Veröffentlichungszyklus von Node; siehe das hervorgehobene, vorletzte unten für eine detailliertere Erklärung dazu.)

Aus meiner (kleinen) Recherche geht hervor, dass es zumindest vorerst erlaubt ist, require aus einem ECMAScript-Modul zu verwenden, aber nicht import aus einem commonjs-Modul.

Kann ich davon ausgehen, dass dies wie node --experimental-modules node_modules/mocha/bin/_mocha ausgeführt wurde?
Wie genau ist .jsx beteiligt? Ich sehe, dass sich das angezeigte Fehlerbeispiel auf .mjs bezieht; Es ist unklar, was gepostet wurde, wo sich das jsx befindet.

Ja, es wurde mit --experimental-modules ausgeführt. jsx ist ein Tippfehler, ich meinte mjs , wird den ersten Beitrag aktualisieren.

Ich erinnere mich auch vage, gehört zu haben, dass die anfängliche Implementierung von Node die Dateierweiterung .mjs erforderte; wenn das (immer noch?) wahr ist und wenn Sie versuchen, Import/Export mit einer .jsx-Datei zu verwenden (entweder Importieren einer .jsx-Datei in .mjs-Datei oder Laden einer .jsx-Datei, die Import/Export enthält), könnte das das Thema sein, anstatt Mokka?

Das Problem scheint zu sein, und ich könnte hier etwas vermissen, dass Mocha require verwendet, um den Test zu laden (das ist zumindest meine derzeitige Annahme, da ich kein Mokka-Experte, eher ein Benutzer bin), was dann enthält andere Module über import . Dies in Verbindung mit dem ersten Punkt würde den Fehler erklären.

Wir müssten einen Weg finden, um sicherzustellen, dass Änderungen an der experimentellen Funktion keine Änderungen an Mocha erfordern, die auf ein Semver Major warten müssten – andernfalls könnten Sie genau dort landen, wo wir jetzt sind, außer noch länger zu warten (da der Hauptveröffentlichungszyklus von Mocha nicht wie der von Node auf zweimal im Jahr festgelegt ist).
Ich spreche nur von meiner eigenen Meinung und nicht im Namen des Teams, wenn das neue Modulformat nicht mit dem alten Modulformat zusammenarbeiten kann, ohne Änderungen an bestehenden Bibliotheken vorzunehmen, die im alten Format geschrieben wurden, dann ist das neue Modulformat noch nicht fertig.

Ich hatte Angst, dass dies die Antwort sein würde, und ich verstehe, dass dies keine oberste Priorität hat. Wenn meine Annahme der obigen Fehlerursache richtig ist, könnte so etwas wie #956 helfen, da der Einstiegspunkt des Tests ein mjs -Modul sein könnte und nicht Commonjs, was sonst wahrscheinlich schwer zu erreichen ist. Es scheint auf der Roadmap des nodejs-Teams zu stehen, import aus aktuellen Modulen zu unterstützen, jedoch sind die Zeitpläne nicht klar.

Aus meiner (kleinen) Recherche geht hervor, dass es zumindest vorerst erlaubt ist, require aus einem ECMAScript-Modul zu verwenden, aber nicht aus einem commonjs-Modul zu importieren.

Es scheint auf der Roadmap des nodejs-Teams zu stehen, den Import aus aktuellen Modulen zu unterstützen, jedoch sind die Zeitpläne nicht klar.

Zur Verdeutlichung: Da in "älteren" (in einigen Fällen aktuellen, nicht experimentellen) Umgebungen import ein Syntaxfehler ist, der nicht mit Verzweigungslogik oder ähnlichem vermieden werden kann, braucht Mocha keinen import selbst verwenden zu können, sondern require verwenden zu können, um Module zu laden, die das neue Format verwenden (oder Module verwenden, die dieses verwenden).

jsx ist ein Tippfehler, ich meinte mjs , wird den ursprünglichen Beitrag aktualisieren.

Danke, das eliminiert einen möglichen Winkel!

Wenn meine Annahme der obigen Fehlerursache richtig ist, könnte so etwas wie #956 helfen, da der Einstiegspunkt des Tests eher ein mjs-Modul als commonjs sein könnte, was sonst wahrscheinlich schwer zu erreichen ist.

Mocha dazu zu bringen, keine globalen Variablen zu erstellen, ist leider nicht möglich, ohne einige der arkaneren Interna umfassend umzuschreiben (ich habe es selbst versucht und konnte es nicht herausfinden 😿); Die Verwendung Ihres eigenen JS-Einstiegspunkts ist jetzt jedoch über die "programmatische" API möglich (die außerhalb einer alten Wiki-Seite und der JSDoc-Kommentare in den Quelldateien möglicherweise nicht dokumentiert ist, aber offiziell unterstützt wird):

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

Ich habe das nicht wirklich ausprobiert, um zu sehen, ob es einen Unterschied macht (muss zuerst die neueste Version von Node holen), aber lassen Sie mich wissen, ob es für Sie funktioniert ...

Zunächst einmal vielen Dank für Ihre diesbezügliche Unterstützung!

Ich habe das versucht

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

Also im Grunde den Node-Einstiegspunkt zu einem ECMAScript-Modul gemacht.

Ich führe es über node --experimental-modules --harmony ./runner.mjs aus

Ich bekomme

(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)

was Mocha braucht, ist nicht in der Lage zu sein, import selbst zu verwenden, sondern in der Lage zu sein, require zu verwenden, um Module zu laden, die das neue Format verwenden (oder die Module verwenden, die das neue Format verwenden).

Das ist leider derzeit in node nicht möglich, Sie können require nur in Modulen verwenden, die Sie über import importiert haben. Gibt es eine Möglichkeit, mocha.addFile('./test/frontend/components/global/test.mjs'); zu vermeiden und stattdessen den Test zu importieren und das importierte Skript so hinzuzufügen

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

?

Momentan gibt es in Mocha keine solche Funktion, aber Sie können etwas in dieser Richtung tun. addFile fügt die Datei einfach an eine Liste an, die später von der run -Funktion require d wird. Die Funktion run ruft loadFiles bis require :

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

Was Sie tun möchten, ist für alle Dateien, die import statt require $ ed werden müssen, nicht addFile aufzurufen (damit Mocha nicht versucht, require it on run ) und rufen Sie stattdessen vor dem Aufruf run einen Code auf, der dem in loadFiles , aber import anstelle von require verwendet import gibt, die dies verhindern würden, aber wenn es überhaupt möglich ist, stelle ich mir vor, dass es ziemlich nah aussehen würde:

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

Sie können sich auch ansehen, wie https://github.com/mochajs/mocha/blob/master/bin/_mocha die programmatische API von Mocha verwendet, um ein Gefühl dafür zu bekommen, wie andere Optionen bereitgestellt und Dinge wie die Dateisuchfunktion von Mocha verwendet werden. Es ist nicht sehr gut organisiert, aber alles, was die Befehlszeilenschnittstelle tut, ist dort enthalten (entweder direkt oder weil darin ein Aufruf an die Funktionen in der programmatischen API von Mocha ist).

Ich kann noch einen Schritt weiter gehen, aber der importierte Test beschwert sich jetzt, dass er die Beschreibung nicht kennt ( ReferenceError: describe is not defined ). Wie wird es richtig injiziert? Wenn ich mache

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

es beschwert sich TypeError: describe is not a function

Also, meine Distribution hat endlich NodeJS 8.5 bekommen, und ich hatte die Gelegenheit, damit zu spielen und ein paar Vermutungen zu bestätigen, die ich hatte, aber nicht sagen wollte, bis ich es überprüfen konnte:

1. Ich kann keine Möglichkeit finden, ein ES-Modul zu laden, ohne seinen Namen in einer Skript-/Moduldatei fest zu codieren. Das bedeutet, dass Mocha sie nicht über die Befehlszeilenschnittstelle laden kann, egal was wir tun und unabhängig von anderen ES- vs. CommonJS-Semantiken. Ob und wann sich das ändert, werden wir wissen wollen, denke ich. (Wenn es sich so ändert, dass das ES-Modul über eine Variable require geladen werden kann, müssen wir wahrscheinlich nichts ändern, aber ich glaube nicht, dass wir etwas darüber sagen können, wie Module funktionieren, bis es passiert .)
2. Während Mocha die Schnittstelle in der pre-require -Ereignisausgabe einrichtet (nicht wenn das Modul zum ersten Mal geladen wird; die gewählte Schnittstelle ist spezifisch für die new Mocha -Instanz), analysiert das neue Modulsystem tatsächlich den Abhängigkeitsbaum und lädt Abhängigkeiten vor den Modulen, die von ihnen abhängen. Der Grund dafür, dass describe nicht definiert ist, liegt darin, dass Mocha es nicht einrichtet, bis die Testmodule geladen sind. Das bedeutet, dass es kompliziert sein wird, dies überhaupt zu erreichen (wiederum, es sei denn und bis require(file) erlaubt ist und die Abhängigkeit in dieser bestimmten Zeile lädt, vorzugsweise synchron, damit wir nichts anderes ändern müssen ).

Ich habe jedoch entdeckt, dass ich es zum Laufen bringen kann, indem ich die Tatsache ausnutze, dass import Ed-Module in der Reihenfolge der import -Aufrufe geladen werden. (Es wäre viel überflüssiger, wenn Sie die Exportschnittstelle oder einen Reporter verwenden, der den Namen jeder einzelnen Datei benötigt, wie in dem Code beschrieben, den ich gleich verlinken werde, aber im Prinzip funktioniert es.) Wenn das so wäre zu ändern, ohne dass sich einer der anderen oben genannten Tatsachen ändert, dann wäre selbst dies überhaupt nicht möglich. Aber im Moment denke ich, das ist, was Sie tun müssten.

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

node --experimental-modules ./run.mjs

Leider bin ich mir ziemlich sicher, dass dies das Beste ist, was wir tun können, wenn man bedenkt, wie ES-Module funktionieren und was Node derzeit zulässt.

Stell es dir anders vor:

• import ist Syntax.
• require ist eine Funktion.

Sie können nichts dynamisch import ausführen, ebenso wie Sie keinen Code ohne die Verwendung von beispielsweise eval() dynamisch ausführen können.

Es gibt diesen Stufe-3-Vorschlag , der dieses Verhalten zulassen würde, aber ich bin mir nicht sicher, ob Laufzeiten ihn bereits ausliefern.

Daher gibt es für Mocha keine Möglichkeit, eine .mjs -Datei zu importieren, wenn es über mocha läuft, ohne vielleicht @std/esm hinzuzufügen und seine require -Implementierung für Dateien mit dem .mjs -Erweiterung. Das mag eine praktikable Lösung sein und etwas, das wir unterstützen könnten, aber eine Diskussion (und eine solche PR) müsste wahrscheinlich von der Community kommen, zumindest bis dieses Verhalten nicht hinter einer Flagge steht.

import describe from 'mocha' steht leider ziemlich weit unten auf der Prioritätenliste, aufgrund der damit verbundenen Schwierigkeiten (#956). Am besten läuft man mit node und bleibt dabei, die Globals zu konsumieren.

Tatsächlich kommt mir in den Sinn, dass wir die Tests laden und vm.runInContext nutzen könnten, vorausgesetzt, so etwas unterstützt Module. Da das Ladeverhalten von Node an die .mjs -Erweiterung gebunden ist und vm.runInContext eine Zeichenfolge erwartet, sehen Sie nicht, wie dies möglich wäre – und in den Dokumenten wird nichts darüber erwähnt. Vielleicht irgendwo ein Problem?

(Andererseits könnte dies genau das sein, was @std/esm unter der Haube macht!)

Ich habe Mocha-Tests , die ohne Transpiler in einem Browser funktionieren . Vielleicht hilft es bei diesem Problem.

das hat nichts damit zu tun, da Sie Mocha nicht als Modul einbinden, sondern als Skript ...

Entschuldigung, ich bin selbst verwirrt. Anders sieht es bei einem Browser aus.

Ich möchte mich mit einem Votum dafür äußern, etwas zu tun, das es Mocha ermöglicht, Tests in einem ES-Modul durchzuführen. Ich bin hier gelandet, nachdem ich versucht hatte, einen solchen Test zu schreiben, und einen Weirdo-Fehler vom Modullader von Node.js erhalten hatte. Ich verwende Node.js 9.5, das ES6-Module nativ unterstützt.

Derzeit erlaubt Node.js 9.5 einem CommonJS-Modul nicht, ein ES6-Modul zu require(). Vielleicht arbeiten sie in die Richtung, das zuzulassen, ich weiß es nicht.

Ich habe den Test als ES6-Modul mit der Erweiterung .mjs geschrieben und versucht, ihn auszuführen. Ich habe den Fehler vom Ladeprogramm erhalten - ich nehme an, dass der Befehl mocha zur Verwendung require() führt und deshalb fehlgeschlagen ist.

Wiederholen Sie den Test mit der Erweiterung .js und versuchen Sie, das zu testende Modul mit require() zu laden. Das hat auch den Fehler vom Loader bekommen.

Ich bin der Meinung, dass die Node.js-Welt überlegen muss, wie sie zu ES6-Modulen wechseln und diese unterstützen. Da Mocha ein sehr beliebtes Tool auf dieser Welt ist, wäre es am besten, wenn das Mocha-Team darüber nachdenkt, wie ES6-Module unterstützt werden können.

Um nachzufassen ... Nach einigem Grübeln und Suchen konnte ich diese Sequenz als Workaround zum Laufen bringen.

Benennen Sie das Testskript mit der Erweiterung .js (wodurch es zu einem CommonJS-Skript wird)

Fügen Sie dann dies in das Testskript ein:

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

Dann kann ich ein ES-Modul so require() machen:

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

@robogeek Oder es könnte sogar noch besser sein, den @std/esm -Preloader von der Befehlszeile aus zu verwenden, damit Sie Ihre Spezifikationsdateien nicht mit Problemumgehungen überladen müssen und .mjs -Erweiterungen haben können.

mocha -r @std/esm spec.mjs

Der dynamische Import wird mit Knoten v9.6 hinter dem Flag --harmony-dynamic-import ausgeliefert. Dynamische Importe ermöglichen es Mocha, Tests zu laden, die in es6-Modulen enthalten sind, ohne dass ein Transpiler erforderlich ist.

@harrysarson Es wird nicht sofort funktionieren. Mocha verwendet cjs-Module und require , Sie müssten die Testdateien mit cjs schreiben, mit etwas zusätzlichem Glue-Code, um die asynchrone Natur von import zu handhaben. Oder übersehe ich etwas?

Ich bin ein Bot, der Probleme auf Inaktivität überwacht.
Für dieses Problem gab es in letzter Zeit keine Aktivitäten, und ich bezeichne es stale . Wenn es in 14 Tagen keine weiteren Kommentare oder Aktivitäten gibt, werde ich dieses Problem schließen.
Vielen Dank für Ihren Beitrag zu Mocha!

Das Problem ist immer noch relevant, hängt jedoch von der nativen Unterstützung für ESM ab. Browser haben es, Node noch nicht.

Ich spielte nur herum, machte mich mit ESM/.mjs vertraut und entschied, dass ich Tests für mein Spielzeug brauchte. Da ich feststelle, dass mocha .mjs -Dateien noch nicht offiziell unterstützt, habe ich zusammen ein kurzes Zwischenmodul durchgearbeitet (bis jemand Zeit hat, Mocha die volle Unterstützung hinzuzufügen):

https://www.npmjs.com/package/mocha-esm
PRs/Issues willkommen: https://github.com/stefanpenner/mocha-esm

Vielleicht gibt es da draußen etwas Besseres, aber es hat Spaß gemacht, es gemeinsam durchzuziehen. also \o/

Ich habe mich entschieden, mocha selbst zu forken, um dynamische Importe zu unterstützen (basierend auf einigen Ideen oben, aber ich konnte es auf keine andere Weise zum Laufen bringen).

Das bedeutet, dass Sie zB mit node --experimental-modules --harmony-dynamic-import test.mjs laufen können

Dann in 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);
  });
});

Ich habe die Änderungen in mocha beibehalten, um dies minimal zu unterstützen , und ich hatte weder Zeit, dies für eine potenzielle PR richtig zu integrieren, noch habe ich ein spezielles npm-Modul hinzugefügt, aber Sie können diesen Fork direkt von github installieren "mocha": "git+https://[email protected]/odolha/mocha" .

Beachten Sie, dass Sie diesen Ansatz verwenden können, um Dateien auf jede gewünschte asynchrone Weise zu laden, nicht nur über dynamischen Import, da Mocha eine Funktion erwartet, die ein Versprechen bereitstellt.

BEARBEITEN

Ich habe vergessen zu erwähnen, dass Ihre Tests bei diesem Ansatz keine reinen Skripte sein können, da wir keinen Kontext einfügen können. Stattdessen müssen Sie Folgendes tun:

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

@odolha
Danke für die Verlinkung deines Forks.
Es gab bereits eine PR zur Unterstützung von nativem ESM , die jedoch geschlossen wurde, da die Modulunterstützung noch experimentell ist.

Ihre Implementierung tröstet mich, dass das Hinzufügen von Unterstützung dafür einfach sein sollte. Wir sind viele, die gespannt auf dieses Feature warten :)

@demurgos :no_mouth: ja... Ich habe gerade diese PR gesehen, nachdem ich mein eigenes Ding gemacht hatte, d'oh 😃.

@harrysarson @boneskull
Das esm -Paket (früher @std/esm genannt) hat .mjs -Unterstützungsdateien in diesem Commit gelöscht.
Das bedeutet, dass es nicht mehr möglich ist, es mit Mocha zu verwenden, um .mjs -Dateien zu testen. Darüber wird in dieser Ausgabe diskutiert.

Ich möchte immer noch in der Lage sein, ES-Module zu testen, damit ich sie sicher in Node oder Browsern ausführen kann.

In Bezug auf die aktuellen Moduldiskussionen besteht Konsens darüber, dass .mjs im Endergebnis verfügbar sein sollten (vielleicht nicht als einzige Lösung, aber zumindest verfügbar) und dass import("./foo.mjs") ein Versprechen für das zurückgeben wird entsprechenden ES-Namensraum. Die Tatsache, dass CJS-Module in ein Modul mit einem default -Export konvertiert werden, der module.exports entspricht, wird mehr diskutiert, scheint aber eine sichere Annahme zu sein.

Wäre es möglich, das Hinzufügen nativer ES-Unterstützung mit dynamischem import zu Mocha zu überdenken? Das Feature-Flag könnte in --experimental-es-modules (von #3253) umbenannt werden, um besser zu signalisieren, dass dies von der aktuellen Weiterentwicklung der Node-Unterstützung abhängt.
Gemäß den Fristen würde die endgültige Spezifikation nicht vor Knoten 12 landen, sodass die aktuelle Implementierung dort für einige Zeit verbleiben wird (und eine relativ sichere Teilmenge des endgültigen Vorschlags ist).

@demurgos Ich persönlich ziehe es vor, ein wenig länger darauf zu warten, bevor ich mich zu Code-Implementierungen auf Mocha verpflichte. Aber vielleicht sind @boneskull oder @ScottFreeCode anderer Meinung?

@demurgos

Das esm-Paket (früher @std/esm genannt) hat unterstützende .mjs-Dateien in diesem Commit abgelegt.

Der esm Loader hat die Unterstützung für .mjs nicht eingestellt. Wir folgen einfach der aktuellen Implementierung --experimental-modules und geben einen Fehler aus, wenn wir versuchen, .mjs mit require zu laden. Benutzer können weiterhin eine .js -Datei für ihre Testeintragsdatei verwenden, die ESM-Syntax oder dynamisches import() verwendet, um nachfolgende Testdateien von .mjs oder .js $ zu laden wie es esm für seine eigenen Tests tut.

Gemäß den Fristen würde die endgültige Spezifikation nicht vor Node 12 landen, sodass die aktuelle Implementierung dort noch einige Zeit verbleiben wird

Es gibt keine festgelegte Zeit für --experimental-modules , um ohne Flagge zu landen. Die Hoffnung ist, dass es irgendwann im Support-Zyklus von Node 10 landen kann _(also irgendwann in den nächsten 2 Jahren)_, aber es ist nichts in Stein gemeißelt.

(und ist eine relativ sichere Teilmenge des endgültigen Vorschlags).

Die aktuelle --experimental-modules -Implementierung ist möglicherweise nicht mit dem endgültigen Vorschlag kompatibel. Es gibt mehrere Diskussionen darüber, wie die ESM-Unterstützung in Node aussehen wird. Einige vorgeschlagene Richtungen sind mit der aktuellen experimentellen Implementierung nicht kompatibel. Je nachdem, wie die Dinge funktionieren, funktioniert der Code, den Sie heute für --experimental-modules schreiben, möglicherweise nicht mit der endgültigen Form.

Der esm-Loader hat die Unterstützung für .mjs nicht eingestellt.

Mein Punkt ist, dass esm das Erfordernis .mjs #$ nicht mehr ermöglicht, sodass Sie die Testerkennung von Mocha nicht mehr für .mjs verwenden können. Aber Sie haben Recht, es wurde nicht dokumentiert, also ist es nicht wirklich eine bahnbrechende Änderung, selbst wenn andere Leute sich darauf verlassen haben.

Bezüglich der Fristen bezog ich mich auf dieses Problem . Es scheint einen Versuch für Node 11 und eine endgültige Implementierung für Node 12 zu geben, damit es auf Node 10 LTS portiert werden kann. Einige wünschten sich, es würde früher passieren, andere warnten davor, es zu überstürzen.

Mein Vorschlag ist, #3253 zusammenzuführen. Dies bietet nur einen Opt-in-Mechanismus, um import(...) anstelle von require zum Laden der Testfälle zu verwenden. Da ich erwarte, dass es hauptsächlich für .mjs im Kontext von --experimental-modules angewendet wird, denke ich immer noch, dass es sicher ist. (Der dynamische Import von .mjs , der ein Namensraumversprechen zurückgibt, wird wahrscheinlich bestehen bleiben). Aber ich überlasse es Ihnen, zu entscheiden, ob Sie es zusammenführen können, und vermeiden Sie es, zu viel darauf zu drängen.

Auch hier ist der Hauptgrund für diesen PR, dass Sie ohne ihn die Testerkennung von Mocha nicht mehr verwenden können, sondern den oben von @jdalton beschriebenen Workaround verwenden müssen. ( .js Einstiegspunkt und manuelle Importe)

Mein Vorschlag ist, #3253 zusammenzuführen.

3253 hatte ein paar Mängel, es ist definitiv keine gute Idee, es so zusammenzuführen, wie es ist.

Nach dem @jdalton- Beispiel habe ich einen kleinen Workflow eingerichtet, um natives ESM ohne das esm -Paket (reines Node + Mocha) zu testen.
Ich verwende asynchrone Testdefinitionen (mit --delay ) und --experimental-modules .

Derzeit kann _mocha_ nur CJS importieren, und CJS kann ESM nur mithilfe der dynamischen Pseudofunktion import() importieren. Also generiere ich den folgenden CJS-Einstiegspunkt (sein Name endet mit .js ), der die Spezifikationsdateien importiert und die Testausführung auslöst:

test.esm.js :

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

(Ich generiere den Einstiegspunkt mit der Liste der Importe zur Build-Zeit, aber Sie können ihn manuell schreiben oder dort glob verwenden.)

Ich führe es dann mit dem folgenden Befehl aus:

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

Ich muss NODE_OPTIONS passieren, weil das Flag von Mocha nicht erkannt wird.

Ich hoffe immer noch, dass Mocha experimentelles ESM besser unterstützt, aber zumindest ist es schön zu wissen, dass es heute eine Möglichkeit gibt, es ohne andere Tools zu verwenden.

@demurgos , das ist eine nette kleine Problemumgehung, die Sie gefunden haben: +1:.

Es ist gut zu sehen, dass es tatsächlich möglich (wenn auch nicht einfach) ist, es-Module mit mocha : smile: zu verwenden.

@demurgos In diesem Problem geht es um die Unterstützung von Tests im ES6-Stil ohne Transpiler-Nutzung . Was ist "Bauzeit"? Der Code, den Sie zum Generieren der Test-Einstiegspunkte verwenden, ist ein Transpiler, nur ein spezialisierter.

@rulatir
Ich habe erwähnt, dass ich Build-Tools verwende, aber sie entsprechen nicht dem in dieser Ausgabe diskutierten Niveau: Mocha läuft mit nativem ESM, nicht mit ESM, das durch einen Transpiler auf CJS herabgesetzt wurde.

Siehe meine Nachricht:

Ich generiere den Einstiegspunkt mit der Liste der Importe zur Build-Zeit, aber Sie können ihn manuell schreiben oder dort glob verwenden.

Ich habe einen Erstellungsschritt verwendet, weil ich möchte, dass meine Importe (1) statisch definiert sind und (2) die Liste nicht selbst pflegen.

Wenn Sie nur wenige Spezifikationsdateien haben, ist das Löschen von (2) in Ordnung: Haben Sie einfach einen Einstiegspunkt, der Ihre 1-2 Spezifikationsdateien importiert.
(1) ist bereits eine spezifische Anforderung für Testdateien, daher ist es meistens nur eine "nice-to-have"-Sache und Sie können zur Laufzeit glob verwenden (anstelle der Build-Zeit wie ich). Dies ist nur ein Detail, das am Ende keine Rolle spielt, wenn Sie die Kernidee verstanden haben.

Wenn Sie nur so etwas wie eine einfache Lösung zum Kopieren und Einfügen wünschen, um die mjs-Spezifikationsdateien zur Laufzeit zu finden, finden Sie hier ein Beispiel:

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

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

Führen Sie es mit NODE_OPTIONS="--experimental-modules" mocha --delay test.esm.js aus.
Wie Sie sehen, überhaupt kein Build, aber etwas mehr Rauschen im Code.

Ich bin ein Bot, der Probleme auf Inaktivität überwacht.
Für dieses Problem gab es in letzter Zeit keine Aktivitäten, und ich bezeichne es stale . Wenn es in 14 Tagen keine weiteren Kommentare oder Aktivitäten gibt, werde ich dieses Problem schließen.
Vielen Dank für Ihren Beitrag zu Mocha!

Dieses Problem ist immer noch gültig und sollte nicht geschlossen werden.

Die kommende Version mocha@6 wird das Flag --experimental-modules auf der weißen Liste haben, das es ermöglicht, einfacher mit ES6-Modulen zu experimentieren. Wäre es möglich, eine Neben- oder Patchversion vor der v6 zu haben? Ich finalisiere derzeit ein neues Coverage-Tool, das den V8-Debugger anstelle von Istanbul verwendet, und möchte es mit Mocha- und ES6-Modulen testen (ohne eine Git-Abhängigkeit in meiner package.json verwenden zu müssen).

@demurgos

Wenn ich es so versuche...

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

Ich bekomme

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

Aber wenn ich so laufe...

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

Es läuft perfekt, was vermisse ich?

@demurgos Sie sollten sich mit @bcoe abstimmen; siehe https://github.com/bcoe/c8

@demurgos Um eine Nebenversion zu kürzen, müssten wir alle nicht brechenden Änderungen seit v5.2.0 in einen Zweig packen und sie in das CHANGELOG kompilieren. Wenn Sie oder jemand anderes bereit ist, diese Arbeit zu erledigen, können wir die Freigabe kürzen.

fwiw Ich empfehle esm über --experimental-modules , bis Node.js seine Geschichte klar hat. das wird eine beträchtliche Wartezeit sein.

@ Knochenschädel
Haha danke. Ich arbeite bereits seit Juli um c8 herum (ich habe eine Reihe von PRs und Ausgaben zu diesem Repo geöffnet). Es gibt auch einige Designentscheidungen, bei denen wir uns nicht einig sind, also versuchen wir, die meisten Abhängigkeiten zu teilen (ich habe zum Beispiel den Zusammenführungsalgorithmus geschrieben) und entschieden, dass ich ein anderes Tool veröffentlichen werde: c88 . Ich habe es dieses Wochenende zum Laufen gebracht und teste es jetzt in meinen Bibliotheken. Ich kann es mit nativem ESM und Mocha in CI verwenden. Ich brauche noch etwas Zeit, um es zu dokumentieren und zu reparieren, aber es sollte im Januar fertig sein).

@jrgleason
Ich habe den Code oben von der Spitze meines Kopfes geschrieben. Es scheint, dass das Problem hier darin besteht, dass globSync relative Pfade zurückgibt, die nicht mit ./ oder ../ beginnen. Vielleicht möchten Sie ihm ./ voranstellen: Es sollte mit einfachen relativen Pfaden funktionieren.
Beachten Sie auch, dass dynamische Importe relative URLs verwenden: # , ? und andere Sonderzeichen können unterschiedlich behandelt werden. Wenn Sie eine felsenfeste Lösung wünschen, sollten Sie den absoluten Pfad des Moduls auflösen und ihn dann in eine Datei-URL konvertieren. Als Teil meiner Arbeit an der Abdeckung habe ich eine Bibliothek geschrieben, um zwischen absoluten Pfaden und URLs zu konvertieren: Sie können fromSysPath von furi verwenden. Konvertierungen sollten alle Arten von Pfaden verarbeiten (sogar die Windows-Namespaces und UNC-Pfade ...).

So könnte ein vollständiges Beispiel aussehen:

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

Ich meine, funktioniert mocha --require esm nicht einfach ? Brauchen wir wirklich eine automatische Erkennung? Das klingt schwierig und fügt Overhead hinzu ...

@demurgos Um eine Nebenversion zu kürzen, müssten wir alle nicht brechenden Änderungen seit v5.2.0 in einen Zweig packen und sie in das CHANGELOG kompilieren. Wenn Sie oder jemand anderes bereit ist, diese Arbeit zu erledigen, können wir die Freigabe kürzen.

Danke für den Vorschlag. Es ist immer noch möglich, --experimental-modules mit NODE_OPTIONS zu bekommen, also hat es keine hohe Priorität (und es kann den Git-Baum erschweren, Commits zu picken). Wenn ich es schaffe, die Probleme zu schließen, die ich mit anderen Abhängigkeiten habe, werde ich sehen, ob ich etwas Zeit damit verbringen kann. In der Zwischenzeit behalte ich einfach den v6-Meilenstein im Auge.

fwiw Ich empfehle esm statt --experimental-modules , bis Node.js seine Geschichte klar hat. das wird eine beträchtliche Wartezeit sein.
Ich meine, funktioniert Mokka --erfordert esm nicht einfach?

Ich stimme definitiv zu, dass es im Moment die beste Lösung ist: Es ist die am einfachsten einzurichtende Lösung und seit einiger Zeit nicht mehr verfügbar: Es funktioniert. In meinem Fall pflege ich meine eigenen Build-Tools und arbeite mit nativem ESM als Alternative zu klassischen CJS-Builds. Obwohl ich sehr gespannt auf natives ESM bin, empfehle ich dennoch, es nicht als einzige Möglichkeit zum Ausführen Ihres Codes zu verwenden: Es ist immerhin experimentell :stuck_out_tongue :.

In den meisten meiner letzten Nachrichten geht es darum, zu teilen, was mit nativem ESM getan werden kann. Dies ist hauptsächlich experimentelle Arbeit und ich gehe davon aus, dass ich sie ändern muss, wenn das ESM von Node stabil wird. Langfristig hat es Vorteile, eine Lösung zu haben, die das esm -Paket nicht erfordert. Hier sind meine Gründe:

• Es reduziert die Menge der benötigten Tools (geringere Komplexität, weniger zu verstehende Konfiguration)
• Es kann einige Unterschiede zwischen echtem ESM und esm in Randfällen geben (Auswertungsfehler, Zyklen, Ladefehler, asynchrone/dynamische Module, Wasm usw.). Beim Schreiben von isomorphem Code kann es sicherer sein, jede mögliche Quelle von Verhaltensabweichungen zu reduzieren. Dies hängt auch irgendwie mit der nativen Abdeckung zusammen: Mit esm sieht V8 die transpilierte Ausgabe, sodass Sie sich mit Quellkarten befassen müssen (noch nicht von c8 unterstützt, aber ich bereite eine PR vor, sie arbeiten an c88 ). Beim Debuggen können auch andere Unterschiede auftreten.
• Es vermeidet, den Code dynamisch transpilieren zu müssen, und hilft, die Leistung zu verbessern.

Brauchen wir wirklich eine automatische Erkennung? Das klingt schwierig und fügt Overhead hinzu ...

Ich bin mir nicht sicher, auf welche automatische Erkennung Sie sich beziehen. Bezieht es sich auf die PR, die Anfang dieses Jahres verschickt wurde?

Bearbeiten : Ich bin auch auf dem Node-Tooling Slack (meistens aktiv auf dem #c8 -Kanal), wenn Sie diskutieren möchten.

@demurgos Ich glaube, ich war etwas verwirrt darüber, was die Leute hier wollten. Ohnehin...

Wenn NODE_OPTIONS=--experimental-modules funktioniert, bis --experimental-modules in Mocha v6.0.0 unterstützt wird, gibt es dann noch weitere Maßnahmen zur Behebung dieses Problems? Das fehlt mir.

Ich gehe davon aus, dass dieses Problem offen bleiben sollte, bis natives ESM ("ES6-Stiltests ohne Transpiler-Nutzung") sofort einsatzbereit / so einfach funktioniert, wie CJS derzeit funktioniert.

Die Lösung, die ich mit --delay und NODE_OPTIONS=--experimental-modules gepostet habe, ist eher eine Problemumgehung als ein richtiger Support. Ich würde dieses Problem als behoben betrachten, sobald Sie in der Lage sind, mocha **/*.spec.mjs auszuführen und einen Bericht zu erhalten.

Leider habe ich im Moment das Gefühl, dass wir noch darauf warten müssen, dass Node die ESM-Unterstützung herausfindet. Ich müsste das überprüfen, aber ich denke, dass der PR keine automatische Erkennung verwendet hat, sondern einfach jedes Modul (CJS oder ESM) mit dynamischen Importen importiert hat. Die Implementierung hängt von der Interop-Story für Module ab.

Bearbeiten : Ich beziehe mich auf https://github.com/mochajs/mocha/pull/3253. Es erlaubt alle Module als ESM zu laden (keine automatische Erkennung).

Ich bin ein Bot, der Probleme auf Inaktivität überwacht.
Für dieses Problem gab es in letzter Zeit keine Aktivitäten, und ich bezeichne es stale . Wenn es in 14 Tagen keine weiteren Kommentare oder Aktivitäten gibt, werde ich dieses Problem schließen.
Vielen Dank für Ihren Beitrag zu Mocha!

Knoten 12 sollte die neue ESM-Implementierung enthalten. Es wird die Gelegenheit sein, zu prüfen, wie ES-Module in Mocha unterstützt werden können.

Bei der Verwendung von Mocha und ESM bin ich auf einen GC-Fehler gestoßen, aber er wird gemeldet und bestätigt, sodass er behoben werden sollte: https://github.com/nodejs/node/issues/27492.

Abgesehen von diesem Fehler funktioniert die in meinem obigen Kommentar beschriebene Strategie immer noch, um Mocha mit ESM zu verwenden.

Hallo Mocha-Leute, vielen Dank, dass Sie ein nettes Tool erstellt und gepflegt haben!

Dies ist nur ein FYI-Kommentar. In den letzten Monaten habe ich an Mocha und * -test.mjs gearbeitet und die Patches wie unten verwendet. Es ist fast kein Problem, mocha test/*.mjs auszuführen (ohne Transpiler oder esm npm-Modul).
https://gist.github.com/tadd/756d21bad38933c179f10e59bddee6b4

Natürlich ist dieser Patch für Mocha-Committer nicht "produktionsreif"; Dies ist nur ein Hack für Mocha-Benutzer, die ESM so schnell wie möglich in Testcodes verwenden möchten.
Ich habe Node.js v11 mit der Option --experimental-modules verwendet. Aktuell bin ich mit v12 und funktioniert auch.

Es ist eine andere Geschichte, aber Node v12 hat die Erweiterung .cjs und das Feld "type" in package.json eingeführt. Es scheint, dass diese auch berücksichtigt werden müssen.

Hallo Mocha-Leute, vielen Dank, dass Sie ein nettes Tool erstellt und gepflegt haben!

In der Tat, und ich möchte mich auch bedanken 😄

Ich habe einen anderen Ansatz gewählt, damit loadFiles synchron bleibt, siehe unten. Bei mir funktioniert es seit Februar. Im Gegensatz zu einigen anderen Hacks erlaubt dies immer noch alle Flags, Inspektions-/Entwicklungstools und eine genaue Codeabdeckung mit c8 . Diese letzte Funktion ist der Grund, warum ich wirklich natives ESM benötige, da das esm -Paket unterschiedliche Offsets für jede Datei hat. (Die Exporte des Moduls werden aufgelistet und verwirren Istanbul).

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

Hallo! Dies ist auch erforderlich, um Code zu testen, der von einem nativen ES6-Projekt abhängt, z. B. lit-element . Ansonsten wirft es so:

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)
    ...

Ich weiß nicht, ob es dafür eine Problemumgehung gibt, aber derzeit glaube ich nicht, dass es eine Möglichkeit gibt, Mocha mit dem nativen ES6-Framework zu verwenden.

@heruan Ich habe in den Kommentaren oben eine Lösung gepostet, die seit Node 8 funktioniert. Hier ist eine aktualisierte Version, die Node 10.12 für native Datei-URL-Konvertierungen erfordert:

Fügen Sie die folgende test.esm.js -Datei hinzu:

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

Führen Sie dann die Tests mit mocha --experimental-modules --delay test.esm.js aus.

Dieser Code funktioniert mit test.esm.js als Commonjs-Bridge zum Laden der ESM-Tests.

Knoten 12 hat ein gemeldetes Problem, bei dem das IIAFE vom GC erfasst wird (nodejs/node#27492), es sollte in einer der nächsten Nebenversionen behoben werden (es kann einige Problemumgehungen geben, aber ich habe mich noch nicht damit befasst). Ich empfehle, die neueste Version von Node 10 zu verwenden, bis es behoben ist.

Thar löst eine UnhandledPromiseRejectionWarning -Warnung aus, wenn ein Fehler auftritt. Verketten Sie besser ein console.error oder behandeln Sie den Fehler anderweitig.

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)

_Ich weiß, dass hier import statt require verwendet werden, aber sehen Sie sich meine Zusammenfassung für eine Lösung an, mit der Sie im ESM-Land bleiben_

@demurgos Vielen Dank für das Code-Snippet für Node 10.12, das Sie vor zehn Tagen gepostet haben!

Ich verwende Node 12.1 und es scheint gut zu funktionieren. Wird dies bald zu Mocha hinzugefügt, oder gibt es einen noch einfacheren Weg, dies mit Node 12 zu tun? Wie verwende ich das auch im --watch -Modus?

https://github.com/standard-things/esm scheint mit --require esm sofort einsatzbereit zu sein, aber es wäre großartig, eine andere Abhängigkeit loszuwerden :) Danke.

Wenn Mocha im Quellcode zu ESM wechseln würde, könnte Rollup eine ESM-Distributionsdatei sowie eine CommonJS- und/oder UMD-Datei bereitstellen.

Ein weiterer Vorteil besteht darin, dass Browser-HTML nicht mit zusätzlichen Skript-Tags verschmutzt werden muss, um Mocha einzubinden. Die Testdateien (oder die Haupttesteingangsdatei) könnten den Import durchführen (und "Magie" in den Testdateien vermeiden, um herauszufinden, woher die Variablen kommen - es müssen nur die Importpfade verfolgt werden).

Man kann auch CSS-Plugins für Rollup verwenden, um das Einfügen mocha.css zu ermöglichen, wodurch die Notwendigkeit für HTML-Unordnung weiter minimiert wird.

Ich bin ein Bot, der Probleme auf Inaktivität überwacht.
Für dieses Problem gab es in letzter Zeit keine Aktivitäten, und ich bezeichne es stale . Wenn es in 14 Tagen keine weiteren Kommentare oder Aktivitäten gibt, werde ich dieses Problem schließen.
Vielen Dank für Ihren Beitrag zu Mocha!

Ich denke, das ist immer noch relevant.

Konnte jemand Mocha mit ES6-Modulen auf (edit: ~Travis~) Node>=12.11.0 ausführen?
Am 12.10.0 scheint ich es erfolgreich eingerichtet zu haben:
mocha-run.js

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

Dann funktioniert mocha --experimental-modules --delay ./mocha-run.js wie ein Zauber.

Aber aus irgendeinem unbekannten Grund verhält es sich am 12.11.0 so, als ob es keinen --delay -Parameter geben würde:

>  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 Ich führe Mocha mit ES-Modulen auf Knoten 12.11.1 aus:

__mocha-run.js__

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

Der Uhrmodus funktioniert jedoch nicht. mocha wartet auf Dateiänderungen, führt aber keinen weiteren Testlauf durch, nachdem eine Datei geändert wurde.

@vanslly Glück gehabt ;)
Für mich mit Node 12.12.0 (https://travis-ci.org/Palindrom/Palindrom/builds/597771311#L450) und mocha-run.js wie oben vorgeschlagen (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 , wirft immer noch den gleichen Fehler

Dass das immer noch ein Thema ist, ist Wahnsinn! ESM ist nicht mehr hinter --experimental-modules versteckt. Das ist die Zukunft.

ähm, eigentlich wurde es erst vor ein paar Tagen angekündigt...

Zu spät – wir sind alle auf Jest umgestiegen.

Hey Leute, ich möchte nur sicherstellen, dass das am Leben bleibt. Bitte machen Sie dies zur obersten Priorität und vielen Dank für all die großartige Arbeit!

@luijar Daran wird bei #4038 gearbeitet

Wir haben gestern eine experimentelle Version v7.0.0-esm1 veröffentlicht: siehe Versionshinweise .

Das ist toll zu sehen!

Darf ich fragen, ob der fehlende Verweis auf den Browser bedeutet, dass die ESM-Nutzung im Browser nicht verfügbar ist oder dass Sie lediglich keine Browserversionen wie bei Node angeben mussten. Ich denke, es könnte hilfreich sein, in den Versionshinweisen den Status für Browser zu erwähnen (und falls nicht unterstützt, was die Pläne für seine Unterstützung sein könnten).

@brettz9
NodeJs ESM wirkt sich in keiner Weise auf den Mocha-Browser aus. Die Tests, die Sie in Ihrem Browser ausführen, werden nicht von NodeJs geladen, das müssen Sie selbst in Ihrem HTML-Code tun.

Wenn ich mich recht erinnere, müssen Sie das Tag $#$ <script> type="module" setzen. Sowohl für Ihre Testdateien als auch für das Mocha-Skript, um die Ladereihenfolge beizubehalten. ESM soll seit Jahren mit dem Browser arbeiten.

@juergba : ja, sicher, aber man braucht eine ESM-Exportverteilungsdatei, damit man etwa import mocha from '../node_modules/mocha/mocha-esm.js'; ohne Kompilierung verwenden kann - und für diejenigen, die die Kompilierung verwenden (z. B. um nur import mocha from 'mocha'; verwenden zu können module in package.json , damit die Bundler den ESM-Build automatisch erkennen können.

mocha wird allgemein geschrieben; Wir können kein „Modul“-Feld in die Datei „package.json“ einfügen. Mocha unterstützt das Ausführen von Tests in Knoten, die in ESM geschrieben sind.

Wenn Sie ESM nicht intern verwenden möchten, sollten Sie Rollup dennoch mit seinem CommonJS-Plugin verwenden und die ESM-Zieldatei angeben können, um module zu unterstützen (wie Sinon-Angebote und die meisten Pakete von Beachten Sie, dass jQuery die einzige andere bemerkenswerte Ausnahme ist und sie auf die Verwendung von ESM umgestaltet wurden).

Ich habe ein Beispielprojekt erstellt, um Mocha mit ESM zu testen. Ich kann die Tests erfolgreich durchführen, war aber (_noch_) nicht in der Lage, die Abdeckung mit NYC/Istanbul durchzuführen. Ihre Hilfe ist willkommen.

@concatime Bis nyc kompatibel gemacht ist, können Sie c8 verwenden: https://www.npmjs.com/package/c8

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

@cedx Ich habe mein Vorlagenrepo aktualisiert und es funktioniert. Sauber!

Wir haben die native ESM-Unterstützung von Node in Mocha v7.1.0 implementiert.