さらに調査を行う前の、頭のてっぺんからの最初の考え：

• 私は、Nodeの人々がCommonJSモジュールとの下位互換性を可能にするために特に標準を変更したことを思い出しているようです。 それが（まだ？）本当なら、モカと一緒に/モカに対して何もする必要なしに、最終的にはサポートされると思います。 （そして、「最終的に」とは、ノードのリリースサイクルの速度を考えると、「モカの変更よりもおそらくさらに速い」という意味です。これについての詳細な説明については、以下の強調された最後から2番目を参照してください。）
• これはnode --experimental-modules node_modules/mocha/bin/_mochaのように実行されたと思いますか？
• .jsxはどの程度正確に関係していますか？ 示されているエラーの例は.mjsを参照していることがわかります。 投稿された内容から、 jsxがどこにあるかは不明です。
• また、 .mjsファイル拡張子を必要とするNodeの最初の実装について聞いたことを漠然と思い出します。 それが（まだ？）本当であり、 import / exportを.jsxファイルで使用しようとしている場合（ import .jsxいずれか） .mjsファイルに入れるか、$ import / exportを含む$ .jsxファイルをロードする場合、それがモカではなく問題になる可能性がありますか？
• 実験的な機能への変更が、semver majorを待たなければならないMochaへの変更を必要としないようにする方法を考え出す必要があります。そうしないと、さらに長く待つことを除いて、現在の場所に戻ってしまう可能性があります。 （モカのメジャーリリースサイクルは、ノードのように年に2回にロックされていないため）。
• チームを代表するのではなく、純粋に私自身の意見から言えば、新しいモジュール形式が古い形式で記述された既存のライブラリを変更せずに古いモジュール形式と相互運用できない場合、新しいモジュール形式はまだ準備ができていません。

私は、Nodeの人々がCommonJSモジュールとの下位互換性を可能にするために特に標準を変更したことを思い出しているようです。 それが（まだ？）本当なら、モカと一緒に/モカに対して何もする必要なしに、最終的にはサポートされると思います。 （そして、「最終的に」とは、ノードのリリースサイクルの速度を考えると、「モカの変更よりもおそらくさらに速い」という意味です。これについての詳細な説明については、以下の強調された最後から2番目を参照してください。）

私の（少しの）調査から、少なくとも今のところ、ECMAScriptモジュールからのrequireは使用できますが、commonjsモジュールからのimportは使用できないようです。

これはnode--experimental-modules node_modules / mocha / bin / _mochaのように実行されたと想定できますか？
.jsxはどの程度正確に関係していますか？ 示されているエラーの例は.mjsを参照していることがわかります。 何が投稿されているのか、jsxがどこにあるのかは不明です。

はい、 --experimental-modulesで実行されました。 jsxはタイプミスです。つまり、 mjsは、最初の投稿を更新します。

また、.mjsファイル拡張子を必要とするNodeの最初の実装について聞いたことを漠然と思い出します。 それが（まだ？）真実であり、.jsxファイルでインポート/エクスポートを使用しようとしている場合（.mjsファイルに.jsxファイルをインポートするか、インポート/エクスポートを含む.jsxファイルをロードする）、モカではなく問題になりますか？

問題は、モカがrequireを使用してテストをロードすることであるように思われます（私はモカの専門家ではなく、より多くのユーザーであるため、少なくとも私の現在の仮定です）。 importを介して他のモジュールが含まれます。 これは最初のポイントと併せてエラーを説明します。

実験的な機能への変更が、semver majorを待たなければならないMochaへの変更を必要としないようにする方法を考え出す必要があります。そうしないと、さらに長く待つことを除いて、現在の場所に戻ってしまう可能性があります。 （モカのメジャーリリースサイクルは、ノードのように年に2回にロックされていないため）。
チームを代表するのではなく、純粋に私自身の意見から言えば、新しいモジュール形式が古い形式で記述された既存のライブラリを変更せずに古いモジュール形式と相互運用できない場合、新しいモジュール形式はまだ準備ができていません。

これが答えになるのではないかと心配しましたが、これが最優先事項ではないことを理解しています。 上記のエラーの原因の私の仮定が正しければ、テストのエントリポイントはcommonjsではなくmjsモジュールである可能性があるため、＃956のようなものが役立つ可能性があります。 現在のモジュールからimportをサポートすることは、nodejsチームのロードマップにあるようですが、タイムラインについては明確ではありません。

私の（少しの）調査から、少なくとも今のところ、ECMAScriptモジュールからrequireを使用することは許可されていますが、commonjsモジュールからインポートすることは許可されていないようです。

現在のモジュールからのインポートをサポートすることはnodejsチームのロードマップにあるようですが、タイムラインについては明確ではありません。

明確にするために：「古い」（場合によっては現在の非実験的な）環境では、 importは構文エラーであり、分岐ロジックなどでは回避できないため、Mochaが必要とするのはそうではありませんimport自体を使用できるようにするためではなく、 requireを使用して、新しい形式を使用する（または使用するモジュールを使用する）モジュールをロードできるようにするため。

jsxはタイプミスです。つまり、mjsは、最初の投稿を更新します。

おかげで、それは1つの可能な角度を排除します！

上記のエラーの原因の私の仮定が正しければ、テストのエントリポイントはcommonjsではなくmjsモジュールである可能性があるため、＃956のようなものが役立つ可能性があります。

残念ながら、モカがグローバル変数を作成しないようにすることは、より難解な内部構造のいくつかを大幅に書き直すことなしには不可能です（私はそれを自分で理解しようとしましたが、理解できませんでした😿）; ただし、独自のJSエントリポイントを使用できるようになったのは、「プログラマティック」API（古いwikiページとソースファイルのJSDocコメント以外では文書化されていない可能性がありますが、公式にはサポートされています）です。

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

私は実際にそれが違いを生むかどうかを確認するためにそれを試していません（最初にノードの最新バージョンを取得する必要があります）が、それがあなたのために働くかどうか私に知らせてください...

まずはご支援ありがとうございます！

私はこれを試しました

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

したがって、基本的にノードエントリポイントをECMAScriptモジュールにしました。

node --experimental-modules --harmony ./runner.mjs経由で実行します

私は得る

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

Mochaが必要としているのは、 import自体を使用できるようにすることではなく、新しい形式を使用する（または使用するモジュールを使用する）モジュールをロードするためにrequireを使用できるようにすることです。

現在、ノードでは使用できません。 importを介してインポートしたモジュールでのみrequireを使用できます。 mocha.addFile('./test/frontend/components/global/test.mjs');を回避し、代わりにテストをインポートして、インポートしたスクリプトを次のように追加する方法はありますか？

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

？

現時点ではモカにはそのような機能はありませんが、それらに沿って何かを行うことができます。 addFileは、ファイルをリストに追加するだけで、後で$ run関数によってrequire dになります。 run関数は、 loadFilesをrequireに呼び出します。

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

あなたがしたいのは、 require importを編集する必要があるファイルの場合です。dはaddFileを呼び出さないでください（したがって、Mochaはrequireを試みません。 run ）、代わりにrunを呼び出す前に、 loadFilesにあるようなコードを呼び出しますが、 require importを使用しますrequire 。 importの使用にこれを妨げる制限があるかどうかは頭の中で思い出せませんが、可能であれば、次のように見えると思います。

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

また、 https：//github.com/mochajs/mocha/blob/master/bin/_mochaがMochaのプログラムAPIを使用して、他のオプションを提供する方法や、Mochaのファイルルックアップ機能などを使用する方法を理解する方法も確認できます。 あまりよく整理されていませんが、コマンドラインインターフェイスが行うことはすべてそこにあります（直接またはMochaのプログラムAPIの関数への呼び出しがあるため）。

さらに一歩進むことができますが、インポートされたテストは、describe（ ReferenceError: describe is not defined ）について知らないと文句を言います。 それを注入する適切な方法は何ですか？ 私が行った場合

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

TypeError: describe is not a functionと文句を言う

それで、私のディストリビューションはついにNodeJS 8.5を手に入れました、そして私はこれで遊んで、私が持っていたいくつかのハンチを確認する機会がありましたが、私がチェックできるようになるまで述べたくありませんでした：

1. スクリプト/モジュールファイルに名前をハードコーディングせずにESモジュールをロードする方法が見つかりません。 つまり、Mochaは、他のESとCommonJSのセマンティクスに関係なく、コマンドラインインターフェイスを介してそれらをロードすることはできません。 それが変わったら、知りたいと思います。 （ESモジュールが変数requireを介してロードできるように変更された場合、おそらく何も変更する必要はありませんが、モジュールがどのように機能するかについては、それが発生するまで確実に言うことはできないと思います。 。）
2. Mochaはpre-requireイベントエミッションでインターフェースをセットアップしますが（モジュールが最初にロードされたときではなく、選択されたインターフェースはnew Mochaインスタンスに固有です）、新しいモジュールシステムは実際に依存関係ツリーを解析します依存関係を依存するモジュールの前にロードするため、 describeが定義されていない理由は、テストモジュールがロードされるまでMochaが依存関係を設定しないためです。 つまり、これを実現するには複雑になります（ただし、 require(file)が許可され、その特定の行で依存関係が読み込まれるまで、できれば同期して、他に何も変更する必要がない場合を除きます）。 ）。

しかし、 import edモジュールがimport呼び出しの順序でロードされるという事実を利用することで、それを機能させることができることを発見しました。 （リンクしようとしているコードで説明されているように、Exportsインターフェイスまたは個々のファイルの名前を必要とするレポーターを使用すると、はるかに冗長になりますが、原則として機能します。）上記の他の事実を変更せずに変更するには、これでさえまったく不可能です。 しかし今のところ、これはあなたがしなければならないことだと思います。

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

node --experimental-modules ./run.mjs

残念ながら、ESモジュールの動作方法と、現時点でNodeが許可していることを考えると、これが最善の方法であると確信しています。

別の方法で考えてください。

• importは構文です。
• requireは関数です。

たとえば、 eval()を使用せずにコードを動的に実行できないのと同様に、動的にimportを実行することはできません。

この動作を可能にするこのステージ3の提案がありますが、ランタイムがまだそれを出荷しているかどうかはわかりません。

そのため、 mochaを介して実行する場合、Mochaが.mjsファイルをインポートするには、おそらく@ std / esmを追加し、 .mjsを含むファイルにrequire実装を使用する必要があります。 .mjs拡張子。 それは実行可能な解決策であり、私たちがサポートすることを検討できるものかもしれませんが、少なくともこの行動が旗の後ろにない限り、議論（およびそのようなPR）はコミュニティから来る必要があるでしょう。

import describe from 'mocha'は、残念ながら、この種のものに固有の難しさのために、優先順位リストでかなり低くなっています（＃956）。 nodeで実行し、グローバルの消費に固執するのが最善です。

実際、そのようなものがモジュールをサポートしていると仮定すると、テストをロードしてvm.runInContextを活用できると思います。 ノードの読み込み動作は.mjs拡張子に関連付けられており、 vm.runInContextは文字列を想定しているため、どのようにできるかはわかりません。ドキュメントにはこれについて何も記載されていません。 多分どこかの問題？

（繰り返しになりますが、これは@std/esmが内部で行うこととまったく同じかもしれません！）

ブラウザでトランスパイラーなしで動作するモカテストがあります。 多分それはこの問題に役立ちます。

モカをモジュールとしてではなく、スクリプトとして取り込むので、これは関係ありません...

すみません、混乱しました。 ブラウザでは違います。

MochaがESモジュールにあるテストを実行できるようにするためのサポートの投票に参加したいと思います。 そのようなテストを書き込もうとして、Node.jsモジュールローダーから奇妙なエラーが発生した後、私はここに着陸しました。 ES6モジュールをネイティブにサポートするNode.js9.5を使用しています。

現在のところ、Node.js 9.5では、CommonJSモジュールがES6モジュールをrequire（）することはできません。 多分彼らはそれを許す方向に働いているのかもしれません、私にはわかりません。

.mjs拡張子の付いたES6モジュールとしてテストを作成し、実行しようとしました。 ローダーからエラーが発生しました- mochaコマンドでrequire()が使用されると思いますが、それが失敗した理由です。

.js拡張子を使用してテストをやり直し、 require()を使用してテスト対象のモジュールをロードしようとしました。 ローダーからもエラーが発生しました。

Node.jsの世界では、ES6モジュールへの移行方法とサポート方法を検討する必要があると思います。 モカはこの世界で非常に人気のあるツールであるため、モカチームがES6モジュールをサポートする方法を検討するのが最善です。

フォローアップするには...熟考して検索した後、このシーケンスを回避策として機能させることができました。

テストスクリプトに.js拡張子を付けて名前を付けます（CommonJSスクリプトにします）

次に、これをテストスクリプトに追加します。

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

次に、ESモジュールを次のようにrequire()できます。

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

@robogeekまたは、コマンドラインから@std/esmプリローダーを使用する方がよい場合もあるため、回避策でスペックファイルを乱雑にする必要はなく、 .mjsの拡張子を付けることができます。

mocha -r @std/esm spec.mjs

動的インポートは、 --harmony-dynamic-importフラグの後ろにノードv9.6が付属しています。 動的インポートにより、mochaはトランスパイラーを必要とせずにes6モジュールに含まれるテストをロードできます。

@harrysarson箱から出して動作することはありません。 Mochaはcjsモジュールとrequireを使用します。 importの非同期性を処理するために、いくつかの追加のグルーコードを使用して、cjsを使用してテストファイルを作成する必要があります。 それとも私は何かが足りないのですか？

私は、問題がないかどうかを監視するボットです。
この問題には最近のアクティビティはありません。 staleというラベルを付けています。 14日以内に、これ以上のコメントやアクティビティがない場合は、この問題をクローズします。
モカに貢献してくれてありがとう！

この問題は依然として関連していますが、ESMのネイティブサポートに依存しています。 ブラウザにはそれがありますが、ノードはまだありません。

私はただ遊んでいて、ESM / .mjsに慣れていて、おもちゃのテストが必要だと判断しました。 モカがまだ公式に.mjsファイルをサポートしていないことに気付いたので、私は簡単な暫定モジュールを一緒にやりました（誰かがモカに完全なサポートを追加する時間があるまで）：

https://www.npmjs.com/package/mocha-esm
PR /問題を歓迎します： https ：//github.com/stefanpenner/mocha-esm

そこにはもっと良いものがあるかもしれませんが、一緒にやり遂げるのは楽しかったです。 だから\ o /

動的インポートをサポートするためにmocha自体をフォークすることにしました（上記のいくつかのアイデアに基づいていますが、他の方法で実行することはできませんでした）。

これは、たとえばnode --experimental-modules --harmony-dynamic-import test.mjsを使用して実行できることを意味します

次に、 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);
  });
});

この最小限をサポートするためにmochaの変更を維持し、潜在的なPRのためにこれを適切に統合する時間がなく、専用のnpmモジュールを追加しませんでしたが、このフォークをgithubから直接インストールできます"mocha": "git+https://[email protected]/odolha/mocha" 。

mochaはPromiseを提供する関数を期待しているため、このアプローチを使用して、動的インポートだけでなく、任意の非同期方法でファイルをロードできることに注意してください。

編集

コンテキストを注入できないため、このアプローチではテストを純粋なスクリプトにすることはできないことを忘れました。その代わりに、次のことを行う必要があります。

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

@odolha
フォークをリンクしていただきありがとうございます。
ネイティブESMをサポートするPRはすでにありましたが、モジュールのサポートはまだ実験段階であるため、閉鎖されました。

あなたの実装は、これに対するサポートを追加するのは簡単なはずだと私を慰めます。 この機能を待ち望んでいる人はたくさんいます:)

@demurgos ：no_mouth：ええ...私は自分のことをした後、そのPRを見ただけです、d'oh😃。

@harrysarson @boneskull
esmパッケージ（以前の名前@std/esm ）は、このコミットでサポート.mjsファイルを削除しました。
これは、Mochaで.mjsファイルをテストするためにそれを使用することができなくなったことを意味します。 これについては、この号で説明します。

ESモジュールをテストして、ノードまたはブラウザーで安全に実行できるようにしたいのですが。

現在のモジュールの議論に関しては、 .mjsが最終結果で利用可能である必要があり（おそらく唯一の解決策ではないが、少なくとも利用可能である）、 import("./foo.mjs")は対応するES名前空間。 CJSモジュールがmodule.exports defaultエクスポートを持つモジュールに変換されるという事実はもっと議論されていますが、それは安全な仮定のようです。

動的importを使用してネイティブESサポートをモカに追加することを再検討することは可能でしょうか？ 機能フラグの名前を--experimental-es-modules （＃3253から）に変更して、これがノードのサポートの現在の進歩に依存していることをより適切に示すことができます。
締め切りによると、最終仕様はノード12まで到達しないため、現在の実装はしばらくの間そこに残ります（そして、最終提案の比較的安全なサブセットです）。

@demurgos私は個人的に、モカのコード実装にコミットする前に、これをもう少し待つことを好みます。 しかし、おそらく@boneskullまたは@ScottFreeCodeは同意しませんか？

@demurgos

esmパッケージ（以前の名前は@ std / esm）は、このコミットでサポート.mjsファイルを削除しました。

esmローダーは.mjsのサポートを終了しませんでした。 現在の--experimental-modulesの実装に従い、 require $を使用して$ .mjsを読み込もうとすると、エラーがスローされます。 ユーザーは、ESM構文または動的import()を使用するテストエントリファイルに.jsファイルを使用して、 .mjsまたは.jsの後続のテストファイルをロードできます。 esmが独自のテストに対して行うように。

締め切りによると、最終的な仕様はノード12まで到達しないため、現在の実装はしばらくの間そこに残ります

--experimental-modulesがフラグなしで着陸するための決まった時間はありません。 希望は、ノード10のサポートサイクルのいつか（つまり、今後2年間のいつか）_に着陸できることですが、何も決まっていないのです。

（そして、最終提案の比較的安全なサブセットです）。

現在の--experimental-modulesの実装は、最終的な提案と互換性がない可能性があります。 NodeでのESMサポートがどのようになるかについてはいくつかの議論があります。 いくつかの提案された方向性は、現在の実験的実装と互換性がありません。 今日書いたコードを--experimental-modulesでどのように振る舞うかによっては、最終的な形式が何であれ、機能しない場合があります。

esmローダーは.mjsのサポートを終了しませんでした。

私のポイントは、 esmでは.mjsを要求できなくなったため、 .mjsでMochaのテスト検出を使用できなくなったことです。 しかし、あなたは正しいです、それは文書化されていなかったので、他の人々がそれに依存したとしても、それは実際には重大な変更ではありません。

締め切りについては、この号を参考にしました。 ノード11とノード12の最終的な実装が試みられているようで、ノード10LTSに移植できます。 それがもっと早く起こることを望む人もいれば、急がないように警告する人もいます。

私の提案は＃3253をマージすることです。 これは、テストケースをロードするためにrequire import(...)を使用するオプトインメカニズムのみを提供します。 --experimental-modulesのコンテキストでは、ほとんどの場合.mjsに適用されると思いますので、それでも安全だと思います。 （名前空間promiseを返す.mjsの動的インポートは残る可能性があります）。 しかし、私はあなたがそれをマージして、それを過度にプッシュすることを避けることができるかどうかをあなたに決めさせます。

繰り返しになりますが、このPRの主な理由は、このPRがないと、Mochaのテスト検出を使用できなくなりますが、@ jdaltonによって上記で説明された回避策を使用する必要があるためです。 （ .jsエントリポイントと手動インポート）

私の提案は＃3253をマージすることです。

3253にはかなりの数の欠陥がありましたが、そのままマージするのは間違いなく良い考えではありません。

@jdaltonの例に従って、 esmパッケージ（純粋なNode + Mocha）なしでネイティブESMをテストするための小さなワークフローを設定しました。
非同期テスト定義（ --delayを使用）と--experimental-modulesを使用します。

現在、_mocha_はCJSのみをインポートでき、CJSは動的import()疑似関数を使用してのみESMをインポートできます。 そこで、次のCJSエントリポイント（名前は.jsで終わる）を生成します。これにより、仕様ファイルがインポートされ、テストの実行がトリガーされます。

test.esm.js ：

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

（ビルド時にインポートのリストを使用してエントリポイントを生成しますが、手動で作成するか、そこでglobを使用できます。）

次に、次のコマンドで実行します。

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

フラグがmochaによって認識されないため、 NODE_OPTIONSを通過する必要があります。

モカが実験的なESMをより良くサポートしてくれることを願っていますが、少なくとも、他のツールなしで今日それを使用する方法があることを知っておくのはいいことです。

@demurgosこれはあなたが見つけたちょっとした回避策です：+1:。

mocha： smile：でesモジュールを使用することが実際に可能である（簡単ではないにしても）ことを確認するのは良いことです。

@demurgosこの問題は、トランスパイラーを使用せずにES6スタイルのテストをサポートすることに関するものです。 「ビルド時間」とは何ですか？ テストエントリポイントを生成するために使用するコードはトランスパイラーであり、特殊なものです。

@rulatir
ビルドツールを使用していると述べましたが、これらはこの号で説明したレベルではありません。MochaはネイティブESMで実行されており、トランスパイラーによってESMがCJSに下げられたわけではありません。

私のメッセージを参照してください：

ビルド時にインポートのリストを使用してエントリポイントを生成しますが、手動で作成するか、そこでglobを使用できます。

インポートを（1）静的に定義し、（2）自分でリストを維持しないようにするため、ビルドステップを使用しました。

スペックファイルが数個しかない場合は、（2）を削除しても問題ありません。1〜2個のスペックファイルをインポートするエントリポイントを用意するだけです。
（1）はすでにテストファイルの特定の要件であるため、ほとんどの場合「必要なもの」であり、実行時にglobを使用できます（私のようなビルド時間の代わりに）。 これは、核となるアイデアを理解すれば、最終的には重要ではない詳細にすぎません。

実行時にmjsスペックファイルを見つける単純なコピーアンドペーストソリューションのようなものが必要な場合は、次の例を参照してください。

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

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

NODE_OPTIONS="--experimental-modules" mocha --delay test.esm.jsで実行します。
ご覧のとおり、ビルドはまったくありませんが、コードにもう少しノイズがあります。

私は、問題がないかどうかを監視するボットです。
この問題には最近のアクティビティはありません。 staleというラベルを付けています。 14日以内に、これ以上のコメントやアクティビティがない場合は、この問題をクローズします。
モカに貢献してくれてありがとう！

この問題は引き続き有効であり、クローズしないでください。

今後のmocha@6リリースでは、ホワイトリストに登録された--experimental-modulesフラグが設定され、ES6モジュールをより簡単に試すことができます。 v6より前にマイナーリリースまたはパッチリリースを行うことは可能ですか？ 私は現在、イスタンブールの代わりにV8デバッガーを使用する新しいカバレッジツールを完成させており、MochaおよびES6モジュールでテストしたいと考えています（package.jsonでgit依存関係を使用する必要はありません）。

@demurgos

このようにしようとすると...

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

私は得る

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

しかし、私がこのように走ると...

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

それは私が欠けているものを完璧に実行しますか？

@ demurgos @ bcoeと調整する必要があります。 https://github.com/bcoe/c8を参照してください

@demurgosでマイナーリリースをカットするには、v5.2.0以降のすべての非ブレーク変更をブランチにチェリーピックして、それらをCHANGELOGにコンパイルする必要があります。 あなたまたは他の誰かがその仕事を喜んで行う場合は、リリースをカットすることができます。

fwiw Node.jsのストーリーがまっすぐになるまで、 --experimental-modulesを超えるesmをお勧めします。 それはかなりの待ち時間になります。

@boneskull
ハハ、ありがとう。 私は7月からすでにc8に取り組んでいます（このリポジトリでたくさんのPRと問題を開きました）。 同意しない設計上の決定もあるため、ほとんどの依存関係を共有しようとし（たとえば、マージアルゴリズムを作成しました）、別のツールc88を公開することにしました。 今週の終わりに動作するようになり、現在ライブラリでテストしています。 CIのネイティブESMとモカで使用できます。 文書化して修正するにはまだ時間が必要ですが、1月に準備が整うはずです）。

@jrgleason
私は頭のてっぺんの上にコードを書きました。 ここでの問題は、 globSyncが./または../で始まらない相対パスを返すことであるようです。 ./を前に付けることをお勧めします。単純な相対パスで機能するはずです。
また、動的インポートでは相対URLが使用されることにも注意してください。 # 、 ? 、およびその他の特殊文字は異なる方法で処理される場合があります。 堅固なソリューションが必要な場合は、モジュールの絶対パスを解決してから、ファイルURLに変換する必要があります。 カバレッジに関する作業の一環として、絶対パスとURLの間で変換するlibを作成しました。 furi fromSysPathを使用することをお勧めします。 変換では、あらゆる種類のパス（Windows名前空間やUNCパスも含む）を処理する必要があります。

完全な例は次のようになります。

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

つまり、 mocha --require esmはうまく機能しませんか？ 本当に自動検出が必要ですか？ それは難しいように聞こえ、オーバーヘッドを追加します...

@demurgosでマイナーリリースをカットするには、v5.2.0以降のすべての非ブレーク変更をブランチにチェリーピックして、それらをCHANGELOGにコンパイルする必要があります。 あなたまたは他の誰かがその仕事を喜んで行う場合は、リリースをカットすることができます。

提案してくれてありがとう。 NODE_OPTIONS --experimental-modulesを取得することはまだ可能であるため、優先度は高くありません（また、gitツリーがチェリーピックコミットを複雑にする可能性があります）。 他の依存関係で発生している問題をなんとか解決できれば、これに時間を費やすことができるかどうかを確認します。 それまでの間、私はv6のマイルストーンに注目しています。

fwiw Node.jsのストーリーがまっすぐになるまで、 --experimental-modulesよりも$ esmをお勧めします。 それはかなりの待ち時間になります。
つまり、mocha --require esmは機能しませんか？

私はそれが今のところ最良の解決策であることに間違いなく同意します：それはセットアップするのが最も簡単な解決策であり、しばらくの間出回っています：それは機能します。 私の場合、私は独自のビルドツールを維持しており、従来のCJSビルドの代わりにネイティブESMを処理しています。 ネイティブESMに本当に熱心ですが、コードを実行する唯一の方法として使用しないことをお勧めします。結局のところ、これは実験的なものです：stuck_out_tongue :。

私の最近のメッセージのほとんどは、ネイティブESMを使用して実行できることを共有することに関するものです。 これは主に実験的な作業であり、ノードのESMが安定したときに変更する必要があると思います。 長期的には、 esmパッケージを必要としないソリューションを持つことには利点があります。 これが私の理由です：

• 必要なツールの量を減らします（複雑さを減らし、理解するための構成を減らします）
• 実際のESMとesmの間には、エッジケース（評価エラー、サイクル、ロードエラー、非同期/動的モジュール、wasmなど）に関していくつかの違いがある場合があります。 同形コードを作成する場合、動作の相違の原因となる可能性のあるものを減らす方が安全な場合があります。 これもネイティブカバレッジに関連しています。 esmを使用すると、V8はトランスパイルされた出力を確認するため、ソースマップを処理する必要があります（ c8ではまだサポートされていませんが、PRを準備しています。彼らはc88で動作します）。 デバッグ時に他の違いも表示される場合があります。
• コードを動的にトランスパイルする必要がなくなり、パフォーマンスの向上に役立ちます。

本当に自動検出が必要ですか？ それは難しいように聞こえ、オーバーヘッドを追加します...

どの自動検出を参照しているかわかりません。 今年初めに送られたPRと関係がありますか？

編集：話し合いたい場合は、ノードツールのSlack（主に#c8チャネルでアクティブ）にも参加しています。

@demurgos私は人々がここで何を望んでいるかについて少し混乱していたと思います。 ともかく...

NODE_OPTIONS=--experimental-modulesがMocha v6.0.0で--experimental-modulesがサポートされるまで機能する場合、この問題に対して他に行うべき作業はありますか？ それが私が欠けているものです。

この問題は、ネイティブESM（「トランスパイラーを使用しないES6スタイルのテスト」）がすぐに機能するまで、またはCJSが現在機能するのと同じくらい簡単に機能するまで開いたままになると思います。

--delayとNODE_OPTIONS=--experimental-modulesで投稿したソリューションは、適切なサポートよりも回避策です。 mocha **/*.spec.mjsを実行してレポートを取得できるようになったら、この問題は修正されたと思います。

残念ながら、今のところ、ノードがESMサポートを理解するのを待つ必要があると感じています。 確認する必要がありますが、PRは自動検出を使用せず、動的インポートを使用してすべてのモジュール（CJSまたはESM）をインポートしただけだと思います。 実装は、モジュールの相互運用ストーリーに依存します。

編集： https：//github.com/mochajs/mocha/pull/3253を参照しています。 すべてのモジュールをESMとしてロードできます（自動検出なし）。

私は、問題がないかどうかを監視するボットです。
この問題には最近のアクティビティはありません。 staleというラベルを付けています。 14日以内に、これ以上のコメントやアクティビティがない場合は、この問題をクローズします。
モカに貢献してくれてありがとう！

ノード12には、新しいESM実装が含まれている必要があります。 モカでESモジュールをサポートする方法を確認する機会になります。

Mocha ESMを使用しているときにGCのバグが発生しましたが、報告および確認されているため、修正する必要があります： https：//github.com/nodejs/node/issues/27492。

このバグのほかに、上記の私のコメントで説明されている戦略は、ESMでモカを使用するために引き続き機能します。

こんにちはモカの人々、素敵なツールを作成して維持してくれてありがとう！

これは参考までのコメントです。 過去数ヶ月間、私は以下のようなパッチを使用して、モカと* -test.mjsに取り組んできました。 mocha test/*.mjsを実行するのにほとんど問題はありません（トランスパイラーまたはesm npmモジュールなしで）。
https://gist.github.com/tadd/756d21bad38933c179f10e59bddee6b4

もちろん、このパッチはMochaコミッターにとって「本番環境対応」ではありません。 これは、テストコードでESMをできるだけ早く使用したいMochaユーザーにとっては単なるハックです。
私は--experimental-modulesオプションでNode.jsv11を使用しました。 現在、私はv12を使用しており、動作します。

別の話ですが、ノードv12では$＃$ package.json $＃$に.cjs拡張機能と"type"フィールドが導入されました。 これらも考慮する必要があるようです。

こんにちはモカの人々、素敵なツールを作成して維持してくれてありがとう！

確かに、そして私も感謝したいと思います😄

loadFilesの同期を維持するために、別のアプローチを採用しました。以下を参照してください。 それは2月以来私のために働いています。 他のいくつかのハックとは異なり、これにより、 c8を使用して、すべてのフラグ、検査/ devtools、および正確なコードカバレッジが可能になります。 esmパッケージにはファイルごとに異なるオフセットがあるため、この最後の機能がネイティブESMを本当に必要とする理由です。 （モジュールのエクスポートが一覧表示され、混乱を招きます）。

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

こんにちは！ これは、ネイティブES6プロジェクトに依存するコード（ lit-elementなど）をテストする場合にも必要です。 それ以外の場合は、次のようにスローされます。

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

これに対する回避策があるかどうかはわかりませんが、現在、ES6ネイティブフレームワークでMochaを使用する方法はないと思います。

@heruan上記のコメントで、ノード8以降に機能するソリューションを投稿しました。 ネイティブファイルのURL変換にノード10.12が必要な更新バージョンは次のとおりです。

次のtest.esm.jsファイルを追加します。

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

次に、 mocha --experimental-modules --delay test.esm.jsを使用してテストを実行します。

このコードは、ESMテストをロードするためのcommonjsブリッジとしてtest.esm.jsを使用することで機能します。

ノード12には、IIAFEがGC（nodejs / node＃27492）によって収集されるという問題が報告されています。次のマイナーバージョンのいずれかで修正する必要があります（いくつかの回避策があるかもしれませんが、まだ調べていません）。 修正されるまで、最新のNode10バージョンを使用することをお勧めします。

エラーが発生した場合、TharはUnhandledPromiseRejectionWarning警告をトリガーします。 console.errorをチェーンするか、エラーを処理することをお勧めします。

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)

_これがrequire importを使用していることは知っていますが、ESMの土地にとどまることができる解決策については私の要点を参照してください_

@demurgos10日前に投稿したNode10.12のコードスニペットをありがとう！

ノード12.1を実行していますが、正常に動作しているようです。 これはすぐにモカに追加されますか、それともノード12でこれを行うさらに簡単な方法はありますか？ また、これを--watchモードで使用するにはどうすればよいですか？

https://github.com/standard-things/esmは--require esmですぐに機能するようですが、別の依存関係を捨てるのは素晴らしいことです:)ありがとう。

MochaがソースでESMに切り替える場合、RollupはESM配布ファイルとCommonJSおよび/またはUMDファイルを提供できます。

ここでのもう1つの利点は、Mochaを取り込むためにブラウザのHTMLを追加のスクリプトタグで汚染する必要がないことです。 テストファイル（またはメインのテストエントランスファイル）はインポートを実行できます（変数がどこから来ているかを把握する限り、テストファイル内の「魔法」を回避できます。インポートパスをトレースするだけで済みます）。

ロールアップ用のCSSプラグインを使用して、 mocha.cssを挿入できるようにし、HTMLの乱雑さの必要性をさらに最小限に抑えることができます。

私は、問題がないかどうかを監視するボットです。
この問題には最近のアクティビティはありません。 staleというラベルを付けています。 14日以内に、これ以上のコメントやアクティビティがない場合は、この問題をクローズします。
モカに貢献してくれてありがとう！

これはまだ関係があると思います。

誰かがES6モジュールでMochaを（編集：〜Travis〜）ノード> = 12.11.0で実行できましたか？
12.10.0では、正常に設定されたようです。
mocha-run.js

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

次に、 mocha --experimental-modules --delay ./mocha-run.jsは魅力のように機能します。

しかし、なんらかの理由で、12.11.0では、 --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ノード12.11.1でESモジュールを使用してmochaを実行しています。

__mocha-run.js__

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

ただし、監視モードは機能していません。 mochaはファイルの変更を待ちますが、ファイルが変更された後は別のテスト実行を実行しません。

@vansllyラッキーあなた;）
Node 12.12.0（https://travis-ci.org/Palindrom/Palindrom/builds/597771311#L450）と、上記で提案したmocha-run.js （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 、、は引き続き同じエラーをスローします

これがまだ問題であるということはクレイジーです！ ESMは--experimental-modulesの背後に隠されなくなりました。 これが未来です。

えーと、実は数日前に発表されたばかりです...

遅すぎます—私たちは皆Jestに切り替えました。

やあみんな、これが生きていることを確認したいだけです。 これを最優先にしてください、そしてすべての素晴らしい仕事に感謝します！

@luijarこれは＃4038で作業中です

昨日、実験的なリリースv7.0.0-esm1を公開しました。リリースノートを参照してください。

これは見るのが素晴らしいです！

ただし、質問できますか？ブラウザーへの参照がないということは、ブラウザーでESMを使用できないことを意味するのでしょうか、それとも単にNodeのようにブラウザーのバージョンを指定する必要がないことを意味するのでしょうか。 リリースノートでブラウザのステータス（サポートされていない場合は、サポートの計画）について言及すると役立つと思います。

@ brettz9
NodeJsESMはMochaブラウザにまったく影響を与えません。 ブラウザで実行するテストはNodeJによって読み込まれません。これは、HTMLコードで自分で行う必要があります。

よく覚えているなら、 <script>タグをtype="module"属性に設定する必要があります。 ロードシーケンスを維持するために、テストファイルとMochaスクリプトの両方に対して。 ESMは何年もの間ブラウザで動作しているはずです。

@juergba ：はい、確かですが、コンパイルせずにimport mocha from '../node_modules/mocha/mocha-esm.js';などを使用できるように、ESMエクスポート配布ファイルが必要です。コンパイルを使用する場合（たとえば、 import mocha from 'mocha';だけを使用できるようにするため）。 package.jsonにmoduleが必要です。

mochaはcommonjsで書かれています。 package.jsonに「モジュール」フィールドを配置することはできません。 Mochaは、ESMで記述されたノードでのテストの実行をサポートします。

ESMを内部で使用するためにリファクタリングしたくない場合でも、 moduleをサポートするためにCommonJSプラグインでRollupを使用し、ESMターゲットファイルを指定できるはずです（Sinonオファーや私が遭遇したことに注意してください。jQueryは他の唯一の注目すべき例外であり、ESMを使用するようにリファクタリングされています）。

ESMでmochaをテストするためのサンプルプロジェクトを作成しました。 テストは正常に実行できましたが、（_まだ_）nyc / istanbulでカバレッジを実行できませんでした。 あなたの助けは大歓迎です。

@concatime nycが互換性を持つようになるまで、 c8を使用できます： https ：//www.npmjs.com/package/c8

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

@cedxテンプレートリポジトリを更新しましたが、機能します。 きちんとした！

ノードのネイティブESMサポートをMochav7.1.0に実装しました。