Jest: Bitte erwägen Sie, native Unterstützung für ES-Module hinzuzufügen

Jest hat seine eigene require Implementierung (https://github.com/facebook/jest/blob/master/packages/jest-runtime/src/index.js), also wäre es viel komplizierter als nur Unterstützung der Syntax und standardmäßiger Blick auf .mjs . Ich bin auch dagegen, experimentelle Flags zu aktivieren.

Es könnte möglich sein, import / export automatisch zu transpilieren, aber die Implementierung der Semantik ist ein riesiges Unterfangen und wird wahrscheinlich wegen der Unterstützung für Knoten 6 für ein Jahr blockiert.

Ich stimme SimenB zu. Wir brauchen eine Reihe von Hooks vom Node-Team, damit dies zusammen mit dem vm-Modul funktioniert. Ich denke jedoch, dass wir dies in der Zwischenzeit unterstützen sollten, aber nicht, indem wir die vollständige native Implementierung spiegeln, sondern indem wir babel verwenden und es so kompilieren, dass es innerhalb von babel-jest . Ich denke, für Testzwecke wird dies gut funktionieren und wir müssen nicht die gleichen Garantien bieten, die die Node Runtime sowieso bieten muss.

Also einfach babel-plugin-transform-es2015-modules-commonjs & babel-plugin-dynamic-import-node zu babel-jest hinzufügen?

Ja, das dachte ich mir.

Leute, was ist mit der Integration von https://github.com/standard-things/esm ? Es ist schnell und verwaltet viele Randfälle.

@TrySound wie würde das konkret aussehen? Können Sie einen Prototyp erstellen?

Wir haben immer noch unsere eigene Anforderungsimplementierung (benötigt für Mocks), daher glaube ich nicht, dass das viel helfen würde.

Und wir müssen sowohl mit den Regeln von Node als auch mit den Regeln des Browsers arbeiten.

Ich würde mich sehr über eine Korrektur freuen und es funktioniert perfekt für uns :D

@std/esm sollte anscheinend nur mit Scherz funktionieren: https://twitter.com/jdalton/status/930257653292400640

Könnte jemand es versuchen und mit einer PR für die Dokumente zurückkommen? 🙂

Ich vermute, Benutzer würden gerne überall Unterstützung haben, aber ich habe festgestellt, dass dies nur für Abhängigkeiten von Testdateien funktioniert.

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

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

Es ist besser, aber nicht ideal.

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

Also einfach babel-plugin-transform-es2015-modules-commonjs & babel-plugin-dynamic-import-node zu babel-jest hinzufügen?

Ich glaube nicht, dass dies eine großartige Lösung ist, da keine Überprüfungen auf "fehlende Exporte" durchgeführt werden, die bei ES-Modulen so wertvoll sind. Zum Beispiel habe ich in React Repo angefangen, Build häufiger auszuführen, nur weil Rollup diese Fehler findet, aber Jest mit es2015-modules-commonjs nicht.

@std/esm sollte anscheinend nur mit Scherz funktionieren

Es wäre ziemlich toll, etwas Zeit in ihre Interop zu investieren. Ziemlich sicher, dass diese Hacky-Lösung irgendwann kaputt geht: https://stackoverflow.com/questions/46433678/specify-code-to-run-before-any-jest-setup-happens. Aber wenn es nur darum geht, etwas auf der Seite von Jest zu entlarven, wäre es cool, wenn es unterstützt wird.

@SimenB , meiner Meinung nach wäre der sofortige Schritt nicht zu komplex. Dringend ist, dass die Leute mit dem .mjs-Modul arbeiten können, auch wenn babel hinter der Testszene hilft. Andernfalls müssen die Leute möglicherweise eine andere Testlösung finden, wenn sie .mjs verwenden möchten.

1. Korrigieren Sie die testMatch-Eigenschaft, damit die .mjs-Datei gefunden werden kann
   (Derzeit funktioniert es nicht, selbst die Regex scheint bereits korrekt zu sein, vielleicht gibt es irgendwo einen harten Code, der die .mjs-Erweiterung ablehnt)
2. Übergeben Sie das Flag --experimental-modules, wenn Sie node.js ausführen, damit es nativ ausgeführt wird
3. Jest sollte .mjs genauso behandeln wie .js heute (zB in jest require) -- die import-Anweisungen sind bereits heute in .js erlaubt, müssen also nur die Erweiterung .mjs zulassen.

Die endgültige Lösung mag komplex sein und braucht Zeit, aber sie ist unvermeidlich, oder?

Hallo, hat jemand diesen Fehler beheben können?

Wir verwenden .mjs mit der Option "node --experimental-modules". Irgendeine Problemumgehung?

Wir verwenden .mjs mit der Option "node --experimental-modules". Irgendeine Problemumgehung?

Das ist experimentell und nicht vollständig ausgearbeitet. Es gibt immer noch viel Aufruhr mit grundlegenden Dingen, wie zum Beispiel dem Importieren eines eingebauten Moduls, noch in der Luft. Projekte wie AVA haben damit begonnen, die Verwendung von @std/esm als ihre Loader-Pipeline zuzulassen, falls verwendet (um Babel zu umgehen). Vielleicht könnte Scherz einen ähnlichen Ansatz verfolgen.

Die Unterstützung von @std/esm ist etwas, was wir tun möchten. Hilfe bei der Umsetzung ist mehr als willkommen!

@SimenB Kannst du manchmal in Hangouts chatten?

Hallo @SimenB 👋

Ein esm Benutzer hat esm + Jest-Demo beigesteuert und ich dachte, es könnte ein guter Ausgangspunkt sein, um einen offizielleren Kuhpfad zu erstellen.

Aktualisieren:

Die Demo von esm + Jest wurde mit grundlegender Unterstützung für die Zuordnung von Modulnamen aktualisiert.

Das ist ziemlich toll! Danke für das Teilen.

Wir müssen herausfinden, wo die Integration sein soll. Wie würde es mit CSS-Dateien (oder anderen Nicht-Js-Assets) umgehen? Soll es nur eine Transformation sein? Was ist mit der integrierten Babel-Transformation? Wie sollte sich Jest bei den ankommenden Ladern verhalten, wenn es etwas beeinflusst?

Es scheint, als ob es für einen Community-Beitrag esm -aktivierten alternativen Scherzläufer (oder eine inoffizielle / experimentelle Flagge) einen Vorteil geben könnte, damit wir bei so etwas vorankommen können. Wäre da Interesse von jest Team?

require ist nicht in einem Runner implementiert, sondern in der Laufzeit selbst. Jeder Beitrag, um es steckbar zu machen, ist sehr willkommen (Ref #848).

Ich bin mir sicher, wenn Sie den Beispielcode @jdalton verlinkt bekommen, um ohne Probleme (oder nahe daran) zu funktionieren, sollte es einfach genug sein, um den esm-Loader hinter einer Flagge im Scherz selbst zu laden. Eine Sache, die ich als Problem sehe, ist, dass es das echte module global haben will, nicht das gefälschte, das wir erschaffen. Sie sind sich nicht sicher, ob Module zwischen den Tests auslaufen können? Ich weiß nicht, was esm damit unter der Haube macht. Es kann auch nicht mit Mocks umgehen, also würden Mocks mit import immer noch kaputt gehen

Möglicherweise müssen nur einige Anpassungen vorgenommen werden, wie Jest CJS anzapft. Wenn Sie beispielsweise das module Objekt verspotten, könnte es anstelle eines einfachen Objekts require("module") und dann module.require umschließen/überschreiben, um Anfragen abzufangen und nach Bedarf zu jonglieren.

Aktualisieren:

Ich arbeite jetzt daran, Jest out of the box mit esm zu aktivieren (wobei Jest hoffentlich nichts anders machen muss) . Ich werde am Wochenende weiter experimentieren, aber die ersten Anzeichen sehen gut aus.

@jdalton Irgendein Update mit der esm Kompatibilität?

Hallo @JasonCust , wow, mein Kommentar hat einige Aufmerksamkeit erregt!

Ich habe Fortschritte bei der Identifizierung der erforderlichen Arbeit gemacht, um den Jest-Support in esm . In meinen Experimenten habe ich Jest-Lade- und Auswertungstests in ESM geschrieben. Die auf der esm Loaderseite erforderliche Arbeit besteht darin, die Art und Weise, wie wir mit vm.Script umgehen, allgemeiner zu gestalten. Im Moment haken wir das hauptsächlich für den REPL-Einsatz ein, der ein einzelnes Modul voraussetzt. Wir müssen das etwas allgemeiner machen, damit der Jest-Support herauskommt. Es sieht nicht so aus, als müsste Jest etwas ändern. Die Überarbeitung unserer vm.Script Unterstützung steht noch auf meiner TODO und wird noch in Angriff genommen, bevor ich Dinge wie die experimentelle WASM-Unterstützung veröffentliche. Im Moment habe ich Bugs beseitigt, die im Zusammenhang mit verbessertem APM und Mocking-Support aufgetaucht sind.

Danke für das Update @jdalton, denn ich freue mich, esm mit Jest nutzen zu können. Um Sie nicht zu stören, während Sie an diesen Dingen arbeiten, gibt es eine Aufgabe für esm , die wir zusammen mit dem Fortschritt verfolgen können?

Sie können diesen Thread weiterhin abonnieren oder dem Repo folgen. Jest-Support wird in der Version v3.1.0 enthalten sein, sodass Sie nach dieser Version Ausschau halten können.

@jdalton Gibt es Neuigkeiten zur Unterstützung von Jest in esm?

Hallo @deepj!

Es steht immer noch auf meiner Liste und die Punkte, die ich anpacken kann, bevor dies erledigt ist, schrumpfen. Ich habe die zusätzliche Jest-Unterstützung für das Testen von esm Modulen in Jest verbessert _(obwohl CJS in Jest-Tests)_. Es gibt immer noch nichts, was die Implementierung auf der Seite von Jest kritisch blockiert _(also keine Arbeit für sie)_. Microsoft, mein Arbeitgeber, ist auch ein starker Jest-Benutzer, daher ist es eines meiner täglichen Ziele, dies ebenfalls zu verbessern. Ich hoffe, es bald in Angriff zu nehmen.

@jdalton Gut zu wissen. Und danke für deine Arbeit. Ich schätze es!

Freue mich sehr auf dieses Feature :speak_no_evil:

Ich habe in den letzten zwei Stunden versucht, diese Funktion zum Laufen zu bringen. Es gibt so viele Teillösungen, halb dokumentierte Antworten, die sich alle voneinander unterscheiden... Früher war es einfach, node.js-Pakete zu testen.

Also einfach babel-plugin-transform-es2015-modules-commonjs & babel-plugin-dynamic-import-node zu babel-jest hinzufügen?

Was ist mit dieser Idee passiert? Gibt es Probleme bei der Umsetzung?

Hallo @jdalton. Ich habe mich gefragt, ob Sie uns über den Status dieses Problems auf dem Laufenden halten könnten. Tut mir leid, wenn ich dich störe, aber darauf warte ich noch eine Weile, und es wäre besser, wenn wir mindestens für das letzte/nächste halbe Jahr ein Update erhalten. Dankeschön :)

Hallo @SurenAt93!

Vielen Dank für Ihre Geduld. Ich hoffe, bis Ende des Monats eine Veröffentlichung mit Jest-Unterstützung zu haben. Damit geben Sie esm als Jest- Transformation an .

Cool. Wie unterscheidet sich diese Transformation von Babel?

@kenotron

Mit der Option transform Jest kann ich den esm Loader seitlich laden. Während es also auch die Quelle technisch transformiert, verkabelt es auch den esm Loader.

Wenn die Frage mehr ist, was ist der Unterschied zwischen Babel und esm . Babel ist eine Sammlung von Paketen, die den Quellcode transformiert, eines der Ziele könnte die ESM-Syntax sein. Der esm Loader ist ein Zero Dependency Loader, der die Laufzeitumgebung simuliert. esm unterstützt also Dinge wie dynamisches import() , besteht relevante Test262- Spezifikationen (zeitliche Totzonen, Live-Bindungen, Vorabfehler usw.) und unterstützt das Laden einer Mischung aus CJS/ESM/WASM in Geschmack nach Konfiguration.

@jdalton Vielen Dank für

@tomheller ;)

Ich habe in den letzten zwei Stunden versucht, diese Funktion zum Laufen zu bringen. Es gibt so viele Teillösungen, halb dokumentierte Antworten, die sich alle voneinander unterscheiden... Früher war es einfach, node.js-Pakete zu testen.

Ich stimme zu.

Ich habe ein einfaches Vue-Projekt erstellt, das auch das Problem manifestiert.
https://github.com/igasparetto/vue-jest-test
Ich konnte es nicht zum Laufen bringen.

Ich habe die Anweisungen auf den folgenden Seiten befolgt:

• https://vuejs.org/v2/guide/unit-testing.html
• https://medium.com/@kevin_peters/unit -testing-vue-js-components-with-jest-86e14ef499da
• Bitte lesen Sie diesen Thread: https://github.com/vuejs/vue-cli/issues/1584

Meine Maschine (nicht sicher, ob es eine Rolle spielen sollte):

• Windows 10 Pro 64-Bit
• Knoten v8.9.4
• Vue: 3.2.3
• npm: 6.5.0

@kenotron

Mit der Option transform Jest kann ich den esm Loader seitlich laden. Während es also auch die Quelle technisch transformiert, verkabelt es auch den esm Loader.

Wenn die Frage mehr ist, was ist der Unterschied zwischen Babel und esm . Babel ist eine Sammlung von Paketen, die den Quellcode transformiert, eines der Ziele könnte die ESM-Syntax sein. Der esm Loader ist ein Zero Dependency Loader, der die Laufzeitumgebung simuliert. esm unterstützt also Dinge wie dynamisches import() , besteht relevante Test262- Spezifikationen (zeitliche Totzonen, Live-Bindungen, Vorabfehler usw.) und unterstützt das Laden einer Mischung aus CJS/ESM/WASM in Geschmack nach Konfiguration.

@kenotron könnten Sie uns bitte ein Update geben?

@igasparetto , es ist die Arbeit von @jdalton , die dies ermöglichen sollte. Diese Lösung hatte ich noch nicht ausprobiert.

Der letzte Status dort ist meiner Meinung nach: https://twitter.com/jdalton/status/1080627279124934661

Ja! Tut mir leid, dass es länger dauert, als ich wollte. Vor Ort habe ich jetzt alle relevanten test262 Tests bestanden. Während ich diese erstellt habe, sind die Szenario-Tests zum Spott verrutscht, sodass ich sie wieder aufheben muss, bevor ich sie veröffentlichen kann. Es ist nicht unüberwindbar, es dauert nur ein bisschen. Ich präsentiere am 16. Januar auf der npm tink esm für seine ESM-Syntaxunterstützung frühzeitig

16.01. und hoffe auf eine Veröffentlichung bis dahin

@jdalton Ich hoffe, die Präsentation ist gut

Haben Sie bitte ein Update zu dieser Version?

@igasparetto Es ist in https://github.com/standard-things/esm/issues/97#issuecomment -454985896 und in https://github.com/standard-things/esm/issues/706 ☺️

Ich hinterlasse hier einen kleinen "Datenpunkt", um Ihnen bei Ihrer Planung zu helfen. Mir ist klar, dass Sie alle Ihre Zeit und Ihre Fähigkeiten investieren, um dieses Problem anzugehen. Da ich selbst Entwickler bin, schätze ich Ihren Beitrag.

Ich habe den größten Teil des gestrigen, nicht weniger als einen Samstag, damit verbracht, mich mit Javascript-Modulen sowohl auf der Client- als auch auf der Serverseite auf den neuesten Stand zu bringen. ESM, CommonJS, AMD, was für ein verwirrendes Durcheinander. Ich war nie in der Lage, einen Scherztest zu erhalten, um mit ESM zu arbeiten, das ein (Knoten-)Modul mit einer .mjs-Erweiterung lädt. Ich konnte das gleiche Modul erfolgreich clientseitig laden. Ich könnte einen Knoten "Client" erstellen, der das Modul mit einer Importanweisung verwendet. Ich konnte jest nicht richtig konfigurieren, um dieselbe Importanweisung zu verwenden, mit oder ohne Babel, mit oder ohne esm. Ich wechselte schließlich zu ava und habe es einfach nach einem Rezept auf ihrer Website zum Laufen gebracht. Ja, ich habe ein Rezept befolgt, ich verstehe die Maschinen, die alle Teile zum Funktionieren gebracht haben, nicht vollständig. Aber immerhin kann ich jetzt ESM-Laden von Javascript-Modulen und zugehörigen Unit-Tests schreiben. Ich denke. Ich extrapoliere auf der Grundlage eines einzigen Erfolgs. Sie haben auch ein Rezept, um ava mit webstorm zu verbinden. Aber immerhin präsentieren sie Normalsterblichen wie mir Rezepte.

Mir ist auch klar, dass sich diese Nachricht so lesen wird, als würde ich jammern (was ich zum Teil bin). Ich sehe die ganze Arbeit, die in Scherz geflossen ist. Aber diese Sache mit der ESM-Unterstützung ist für mich ein Killer und ein Dealbreaker. Ich dachte, Sie würden sich über Feedback freuen, aber wenn nicht, ignorieren Sie dies oder bitten Sie mich, es zu löschen, und ich werde es tun.

Gibt es Neuigkeiten im Hinblick auf die Unterstützung neuer Module in der Version v12 ?

@dandv Ich habe untersucht, ob Jest native ES-Module in Knoten 12 unterstützen kann. Dazu verwendet Jest die vm.SourceTextModule API, die erfordert, dass einige CLI-Flags an node :

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

Die API ist auch super-low-level.

TBD.

Diskussion in https://github.com/nodejs/node/issues/27387

Update: wurde angewiesen zu warten, bis das Design des Modulladers von Node gesperrt ist. In der Zwischenzeit könnte standard-things/esm#706 die beste Wahl sein.

jest ist eine sehr schöne Testbibliothek. Unterstützung für esm wirklich alles, was es braucht, um vollständig zu sein!

Update: wurde angewiesen zu warten, bis das Design des Modulladers von Node gesperrt ist. In der Zwischenzeit könnte standard-things/esm#706 die beste

mit Scherz geht das leider nicht.

@jdalton Wir verwenden lodash-es , den ES Module Exports-Build von lodash. Unser Projekt ist ein Angular v7-Projekt, das Webpack v4 unter der Haube als Bundle verwendet. Für diejenigen, die es nicht wissen, lodash-es ist mit Webpack v4 baumschüttelbar! ( ◔ ౪◔)⊃━☆ﾟ.*・.

Leider bereitet uns dies Probleme, da Jest noch keine ES-Modul-Unterstützung bietet. Wir hoffen, dass diese Funktion bald Teil von Jest sein wird. Weiß jemand zufällig, wie man

Jest scheitert mit der Fehlermeldung:

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

    SyntaxError: Unexpected token export

Unsere jest.config.js

Wir verwenden auch das jest-preset-angular npm-Paket.

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

Leider bereitet uns dies Probleme, da Jest noch keine ES-Modul-Unterstützung bietet. Wir hoffen, dass diese Funktion bald Teil von Jest sein wird. Weiß jemand zufällig, wie man , mit Jest zusammenzuarbeiten?

Sagen Sie Jest, dass er lodash-es bei der Transformation nicht ignorieren soll:

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

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

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

@haraldrudell Gemäß der Anweisung ist nicht klar, wie das Paket verwendet wird, es heißt: Erstellen Sie eine Datei neben package.json namens jest.config.js content module.exports = require('jest-esnext') , aber was ist, wenn ich bereits eine Konfiguration habe? Wie integriert man?

das ist die verwendete Datei

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

Sie könnten in der Lage sein , den Inhalt zu ersetzen _default mit dem einem von Ihrem jest.config.js

Hallo Leute,
node 12.13.0 LTS's endlich veröffentlicht... irgendwelche Neuigkeiten zu diesem Thema?

@mtsmachado8 Ich fürchte, das v8-Team braucht in dieser Angelegenheit noch einige Zeit, da ich sehe, dass ESM-Module immer noch als experimentell gekennzeichnet werden ... sie sind vielleicht auf der Roadmap dafür gescheitert.

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

Für ungeflagte ESM ist dieser PR vorhanden
https://github.com/nodejs/node/pull/29866

@azder @haraldrudell Also im Grunde führen Sie in Ihrer Lösung die Babel-Transformation für alle JS-Dateien durch, einschließlich derer in node_modules ?

In meinem Fall musste ich Ihr Preset direkt verwenden, da ich nicht gefunden habe, wie man den Transformator so konfiguriert:

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

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

Node hat jetzt standardmäßig die Modulunterstützung umgeschaltet

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

Die Standardunterstützung für ECMAScript-Module landete in 13.2.0

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

Wir werden nicht daran arbeiten, bis die Lader verfügbar sind. Ohne sie hat Node nicht die Haken, die Jest braucht, um die richtige Unterstützung zu bieten. Siehe https://medium.com/@nodejs/announcing -core-node-js-support-for-ecmascript-modules-c5d6dc29b663 (ich kann nicht direkt auf den Abschnitt verlinken, aber es ist der Abschnitt "In Arbeit" unten)

Für diejenigen, die native Module verwenden und jest verwenden möchten.
Während Sie daran arbeiten, schlage ich eine schnelle Lösung für Knoten v. 13.2.0 vor:
babel-plugin-transform-default-import
Verwendung (in _package.json_):

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

Libs müssen installiert werden:
npm i --save-dev @babel/core @babel/preset-env babel-plugin-transform-default-import

Hinweis: Sie müssen babel-plugin-transform-default-import möglicherweise nicht verwenden, wenn Sie keine Libs haben, die Babel namens export haben (oder Sie verwenden es nicht)

@infodusha Super :) . Danke dafür.

In meinem Projekt funktioniert es ohne die Plugins:

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

babel.config.js (dieser musste so benannt werden, nicht .babelrc ):

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

    plugins: [],
};

Der Trick besteht darin, Dateien in Verzeichnisse aufzuteilen und die entsprechenden package.json darin zu verwenden:

in test dir habe ich verwendet

{
  "type": "commonjs"
}

während in src dir:

{
  "type": "module"
}

@azder Aber wenn Sie ein Paket importieren, das in nativen Modulen einen Commonjs-Namensimport bereitstellt, müssen Sie es mit dem Standardimport importieren und in Babel müssen Sie den benannten Import verwenden. Wahrscheinlich haben Sie keine Pakete wie diese oder Pakete, die den Export von es6 ermöglichen, aber nicht alle Pakete sind morgen dafür bereit

@infodusha Wahrscheinlich habe ich keine was jetzt? Haben Sie versucht, was ich geschrieben habe, und Probleme damit gefunden, oder gehen Sie einfach davon aus, dass ich Probleme bei der Verwendung habe?

Geben Sie ein tatsächliches Beispiel an, da mir nicht klar ist, was Sie mit "Importpaket, das Commonjs namens import in nativen Modulen bereitstellt" meinen.

Bisher hatte ich keine Probleme, alle Dateien mit der Dateierweiterung .js schreiben, wobei sich im Verzeichnis ./src "type":"module" und das Verzeichnis "type":"commonjs" ./test "type":"commonjs" damit:

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

Das liegt daran, dass Jest ES-Module stillschweigend in CommonJS- Code

Folgendes sollte meiner Meinung nach ES-Module nativ testen:

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

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

@azder das sind Workarounds.

Erstellen Sie ein Verzeichnis mymodule mit package.son type=module und zwei Dateien darin: first.js und second.js .
Dann versuchen Sie es mit import { first } from "mymodule";

Sie benötigen das Feld exports im json, um Node ESM zu verwenden, und kein Paket hat es heutzutage (dh: lodash).

Ihr Beispiel scheint zu funktionieren, aber es bricht ab, sobald eines von some-module.js oder another-module.js versucht, import ein benanntes Modul zu knacken: Sie werden kaskadieren.

@damianobarbati Sie _ NEED _ "type": "module" in package.json , ohne diese werden alle .js Dateien in Ihrem Modul als CommonJS geladen.

exports wird nur verwendet, um zu begrenzen, was externen Verbrauchern offengelegt wird, und für bedingte Exporte hat es absolut keinen Einfluss darauf, ob .js Dateien als CommonJS oder ESM geparst werden.

@damianobarbati du

Das liegt daran, dass Jest ES-Module stillschweigend in CommonJS-Code transpiliert.

Ja, ich verlasse mich auf Jest-Macken, das ist der Grund, warum ich babel.config.js ohne auch nur Babel zu den devDependencies hinzuzufügen

@damianobarbati

Bitte beachten Sie , habe ich ein Arbeitsprojekt, in dem ich verwende Jest transpiled, während das src - Verzeichnis hat den Modultyp, Note, ./src nicht die Wurzel , wo die babel - Konfigurationsdatei ist (dh ein CJS ist wegen Macken).

Außerdem haben Sie Recht, da ich nichts von NPM importiere, das CJS ist, da ich denke, dass NPM (oder die Paketautoren) nicht ganz bereit für Mix-and-Match sind.

Das Ziel in meinem Projekt ist es, nur ESM zu haben (um das Werkzeugfett zu reduzieren), also ist Jest die einzige Ausnahme, die von selbst transpiliert wird.

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

@damianobarbati

So ähnlich, hier das Projekt https://github.com/azder/clip . Beachten Sie, dass es in meinen package.json keine "Abhängigkeiten" gibt, wie im letzten Satz des Blog-Post-Auszuges beschrieben. Ich habe mich entschieden, ESM- und CJS-Module von NPM nicht zu mischen.

Auf diese Weise transpiliert es für die Bedürfnisse von Jest, was von meinen ESM-Modulen benötigt wird, aber vielleicht wird mehr Babel-Konfiguration benötigt, um mit dem node_modules Verzeichnis umzugehen.

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

Derzeit ist es nicht möglich, ein Paket zu erstellen, das sowohl über require('pkg') als auch über import 'pkg' verwendet werden kann. Es gibt Bemühungen, dies zu beheben, und können Änderungen an den oben genannten Punkten nach sich ziehen. Insbesondere kann Node.js ein anderes Feld als „main“ auswählen, um den Einstiegspunkt für das ES-Modul eines Pakets zu definieren. Obwohl uns bewusst ist, dass die Community das Feld „module“ angenommen hat, ist es unwahrscheinlich, dass Node.js dieses Feld übernimmt, da viele der mit „module“ veröffentlichten Pakete ES-Modul-JavaScript enthalten, das in Node.js möglicherweise nicht ausgewertet wird (weil Erweiterungen werden von Dateinamen weggelassen oder der Code enthält require-Anweisungen usw.). Bitte veröffentlichen Sie keine ES-Modulpakete, die von Node.js verwendet werden sollen, bis dies behoben ist.

Bitte beachten Sie #9430, das ich gerade geöffnet habe, um den Support in Jest zu verfolgen. Ich werde dieses Thema zur Diskussion offen halten.

@SimenB das ist ein gutes Zeichen! Dies und die Erwähnung von Modulen in den Versionshinweisen von Jest 25 lassen hoffen, die Unterstützung früher zu sehen.

@SimenB Wenn ich mich richtig erinnere, konnte Jest keine NPM-Pakete verwenden, die nur als ESM veröffentlicht wurden, was dazu führte, dass Babel auch für einige node_modules Pakete aktiviert wurde. Hat sich das geändert?

Sie müssen den Import/Export transpilieren, bis die Unterstützung eintrifft, sowohl der Benutzer- als auch der Bibliothekscode

@SimenB :

Sie müssen den Import/Export transpilieren, bis die Unterstützung eintrifft, sowohl der Benutzer- als auch der Bibliothekscode

Für unseren Fall ist der bisher beste Weg, da alle unsere Pakete /es/ dir haben, aber das ist zerbrechlich und passt möglicherweise nicht für andere Projekte:

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

Jest holt diese Pakete ohne Transformation trotz type: module , genau wie Sie gesagt haben.

Sie müssen den Import/Export transpilieren, bis die Unterstützung eintrifft, sowohl der Benutzer- als auch der Bibliothekscode

Gibt es dazu einen groben Zeitplan?
ab Knoten 14 Release:

Wir glauben, dass die aktuelle Implementierung ein zukunftssicheres Modell für die Entwicklung von ESM-Modulen bietet, das den Weg zu universellem JavaScript ebnet. Bitte lesen Sie mehr in unserer Dokumentation.

Die ESM-Implementierung in Node.js ist noch experimentell, aber wir glauben, dass wir sehr nahe daran sind, ESM in Node.js als „stabil“ bezeichnen zu können. Das Entfernen der Warnung ist ein großer Schritt in diese Richtung.

Daher zögere ich, NPM-Pakete (die möglicherweise von Tests verwendet werden, die das JEST-Testframework implementieren) viel länger mit commonJS zu exportieren.

Wir liefern eine experimentelle Version von Jest 25.4. Eine ganze Reihe von Fehlerbehebungen in 25.5, aber es ist immer noch nicht dort, wo es sein sollte. Sie können den Fortschritt in #9430 verfolgen