추가 조사를 하기 전에 머릿속에 떠오른 초기 생각:

• Node 사람들이 CommonJS 모듈과의 하위 호환성을 허용하도록 특별히 변경된 표준을 기억하는 것 같습니다. 그것이 (여전히?) 사실이라면 결국 Mocha와 함께/모카와 아무 것도 할 필요 없이 지원될 것이라고 예상 합니다. (그리고 "결국"이란 Node의 릴리스 주기 속도를 고려할 때 "Mocha 변경보다 더 빠를 수도 있음"을 의미합니다. 이에 대한 자세한 설명은 아래 강조된 끝에서 두 번째를 참조하십시오.)
• 이것이 node --experimental-modules node_modules/mocha/bin/_mocha 처럼 실행되었다고 가정할 수 있습니까?
• .jsx 는 정확히 어떻게 관련되어 있습니까? 표시된 오류 예제는 .mjs 를 참조합니다. 게시된 내용에서 jsx 가 어디에 있는지 명확하지 않습니다.
• 또한 .mjs 파일 확장자가 필요한 Node의 초기 구현에 대해 들은 것이 어렴풋이 기억납니다. 그것이 (여전히?) 사실이고 .jsx 파일과 함께 import / export 를 사용하려고 하면 ( import .jsx $ .mjs $ 파일에 .jsx $ 파일이 있거나 import / export 가 포함된 $ .jsx 파일을 로드하는 경우 Mocha가 아니라 문제가 될 수 있습니까?
• 우리는 실험적 기능에 대한 변경 사항이 semver Major를 기다려야 하는 Mocha의 변경 사항을 요구하지 않도록 하는 방법을 찾아야 할 것입니다. 그렇지 않으면 더 오래 기다리지 않고는 현재 위치로 바로 돌아갈 수 있습니다 (Mocha의 주요 릴리스 주기는 Node와 같이 1년에 두 번으로 고정되어 있지 않기 때문입니다).
• 팀을 대신하지 않고 순전히 내 의견으로 말하면 새 모듈 형식이 이전 형식 으로 작성된 기존 라이브러리를 수정하지 않고 이전 모듈 형식과 상호 운용할 수 없다면 새 모듈 형식은 아직 준비되지 않은 것 입니다.

Node 사람들이 CommonJS 모듈과의 하위 호환성을 허용하도록 특별히 변경된 표준을 기억하는 것 같습니다. 그것이 (여전히?) 사실이라면 결국 Mocha와 함께/모카와 아무 것도 할 필요 없이 지원될 것이라고 예상합니다. (그리고 "결국"이란 Node의 릴리스 주기 속도를 고려할 때 "Mocha 변경보다 더 빠를 수도 있음"을 의미합니다. 이에 대한 자세한 설명은 아래 강조된 끝에서 두 번째를 참조하십시오.)

내 (작은) 연구에 따르면 적어도 지금은 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 파일을 로드하는 경우) 문제는 모카보다?

문제는 여기에서 누락된 것이 있을 수 있습니다. mocha는 require 를 사용하여 테스트를 로드합니다. import 를 통해 다른 모듈을 포함합니다. 이것은 첫 번째 요점과 관련하여 오류를 설명합니다.

우리는 실험적 기능에 대한 변경 사항이 semver Major를 기다려야 하는 Mocha의 변경 사항을 요구하지 않도록 하는 방법을 찾아야 할 것입니다. 그렇지 않으면 더 오래 기다리지 않고는 현재 위치로 바로 돌아갈 수 있습니다 (Mocha의 주요 릴리스 주기는 Node와 같이 1년에 두 번으로 고정되어 있지 않기 때문입니다).
팀을 대신하지 않고 순전히 내 의견으로 말하면 새 모듈 형식이 이전 형식으로 작성된 기존 라이브러리를 수정하지 않고 이전 모듈 형식과 상호 운용할 수 없다면 새 모듈 형식은 아직 준비되지 않은 것입니다.

이것이 답이 될까봐 두려웠고 이것이 최우선 순위가 아님을 이해합니다. 위의 오류 원인에 대한 내 가정이 맞다면 테스트의 진입점이 mjs 모듈이 될 수 있기 때문에 #956과 같은 것이 도움이 될 수 있습니다. 현재 모듈에서 import 를 지원하는 것은 nodejs 팀의 로드맵에 있는 것으로 보이지만 타임라인에 대해서는 명확하지 않습니다.

내 (작은) 연구에서 적어도 지금은 ECMAScript 모듈에서 require를 사용할 수 있지만 commonjs 모듈에서 가져올 수는 없는 것 같습니다.

현재 모듈에서 가져오기를 지원하는 nodejs 팀의 로드맵에 있는 것 같지만 타임라인에 대해서는 명확하지 않습니다.

명확히 하기 위해: "오래된"(일부 경우에는 현재 실험적이지 않은) 환경 import 는 구문 오류이며 분기 논리 또는 이와 유사한 것으로 피할 수 없으므로 Mocha가 필요로 하는 것은 다음과 같습니다. import 자체를 사용할 수 있지만 오히려 require 를 사용하여 새 형식을 사용하는(또는 사용하는 모듈을 사용하는) 모듈을 로드할 수 있습니다.

jsx는 오타이며 mjs를 의미하며 초기 게시물을 업데이트합니다.

덕분에 가능한 한 각도가 사라집니다!

위의 오류 원인에 대한 내 가정이 맞다면 테스트의 진입점이 다른 방법으로는 달성하기 어려운 commonjs가 아닌 mjs 모듈이 될 수 있으므로 #956과 같은 것이 도움이 될 수 있습니다.

Mocha가 전역 변수를 생성하지 않도록 하는 것은 불행히도 좀 더 불가사의한 내부 요소를 광범위하게 다시 작성하지 않고는 불가능합니다. 그러나 이제 "프로그래매틱" API를 통해 자신의 JS 진입점을 사용할 수 있습니다(이는 소스 파일 의 이전 위키 페이지 및 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

차이가 있는지 확인하기 위해 실제로 시도하지는 않았지만(최신 버전의 Node를 먼저 가져와야 함) 효과가 있는지 알려주세요...

우선 이에 대한 지원에 감사드립니다!

나는 이것을 시도했다

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

?

현재 Mocha에는 그런 기능이 없지만 해당 라인을 따라 무언가를 할 수 있습니다. addFile 는 run 함수에 의해 나중에 require 인 목록에 파일을 추가합니다. run 함수는 loadFiles 를 require 로 호출합니다.

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

당신이 하고 싶은 것은 require 대신 import 가 되어야 하는 파일에 대해 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에 있는 함수에 대한 호출이 있기 때문에).

한 단계 더 나아갈 수 있지만 가져온 테스트는 이제 설명( 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 호출의 순서로 로드된다는 사실을 이용하여 작동하게 만들 수 있다는 것을 발견했습니다. (링크하려는 코드에 설명된 대로 각 개별 파일의 이름이 필요한 리포터 또는 내보내기 인터페이스를 사용하는 경우 훨씬 더 중복되지만 원칙적으로는 작동합니다.) 위의 다른 사실 중 어느 것도 변경하지 않고 변경하려면 이마저도 전혀 불가능합니다. 하지만 지금은 이것이 당신이 해야 할 일이라고 생각합니다.

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

node --experimental-modules ./run.mjs

불행히도, ES 모듈이 작동하는 방식과 현재 Node가 허용하는 것을 감안할 때 이것이 우리가 할 수 있는 최선이라고 확신합니다.

다른 방식으로 생각해 보세요.

• import 는 구문입니다.
• require 는 함수입니다.

$ eval() 를 사용하지 않고 코드를 동적으로 실행할 수 없는 것과 마찬가지로 어떤 것도 동적으로 import 할 수 없습니다.

이 동작을 허용하는 3단계 제안 이 있지만 런타임에서 아직 제공하는지 확실하지 않습니다.

따라서 mocha 를 통해 실행할 때 Mocha에서 .mjs 파일을 가져올 수 있는 방법은 없습니다. @std/esm 을 추가하지 않고 require .mjs 확장. 그것은 실행 가능한 솔루션 일 수 있고 지원을 고려할 수 있는 것이지만 적어도 이 행동이 플래그 뒤에 있지 않을 때까지는 커뮤니티에서 토론(및 그러한 PR)이 필요할 것입니다.

import describe from 'mocha' 는 불행히도 이러한 종류의 문제(#956)에 대한 고유한 어려움으로 인해 우선 순위 목록에서 매우 낮습니다. node 로 실행하고 전역을 계속 사용하는 것이 가장 좋습니다.

실제로, 테스트를 로드하고 vm.runInContext 를 활용할 수 있다는 생각이 듭니다. 그러한 것이 모듈을 지원한다고 가정합니다. Node의 로딩 동작은 .mjs 확장에 연결되어 있고 vm.runInContext 는 string 을 예상하기 때문에 어떻게 가능한지 알 수 없으며 문서에는 이에 대해 언급된 내용이 없습니다. 어딘가에 문제가 있습니까?

(다시 말하지만 이것은 정확히 @std/esm 가 내부적으로 수행하는 작업일 수 있습니다!)

브라우저에서 트랜스파일러 없이 작동하는 모카 테스트가 있습니다. 아마도 이 문제에 도움이 될 것입니다.

모듈로 모카를 가져 오는 것이 아니라 스크립트로 가져 오는 것과 관련이 없습니다 ...

혼란스러워 죄송합니다. 브라우저에서 다릅니다.

Mocha가 ES 모듈에 있는 테스트를 실행할 수 있도록 하는 일에 대해 지지를 표하고 싶습니다. 그런 테스트를 작성하려고 하고 Node.js 모듈 로더에서 이상한 오류를 받은 후 여기에 도착했습니다. 저는 기본적으로 ES6 모듈을 지원하는 Node.js 9.5를 사용하고 있습니다.

현재 Node.js 9.5는 CommonJS 모듈이 ES6 모듈을 요구()하는 것을 허용하지 않습니다. 어쩌면 그들은 그것을 허용하는 방향으로 일하고 있을지도 모르겠습니다.

.mjs 확장자를 가진 ES6 모듈로 테스트를 작성하고 실행해 보았습니다. 로더에서 오류가 발생했습니다. mocha 명령이 require() 를 사용한 결과라고 가정하고 이것이 실패한 이유입니다.

.js 확장자로 테스트를 다시 실행하고 require() 를 사용하여 테스트할 모듈을 로드하려고 했습니다. 그것은 또한 로더에서 오류를 얻었습니다.

저는 Node.js 세계가 ES6 모듈로 이동하고 ES6 모듈을 지원하는 방법을 고려해야 한다고 생각합니다. Mocha는 이 세계에서 매우 인기 있는 도구이므로 Mocha 팀이 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일 이내에 더 이상의 댓글이나 활동이 없으면 이 문제를 닫겠습니다.
Mocha에 기여해주셔서 감사합니다!

이 문제는 여전히 관련이 있지만 ESM에 대한 기본 지원에 의존합니다. 브라우저에는 있지만 노드는 아직 없습니다.

그냥 놀다가 ESM/.mjs에 익숙해지고 장난감에 대한 테스트가 필요하다고 결정했습니다. mocha가 아직 공식적으로 .mjs 파일을 지원하지 않는다는 것을 깨닫고 저는 빠른 중간 모듈을 함께 진행합니다(누군가가 mocha에 대한 완전한 지원을 추가할 시간이 있을 때까지):

https://www.npmjs.com/package/mocha-esm
홍보/이슈 환영: 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', () => {
      ...
}

@오돌하
포크를 연결해 주셔서 감사합니다.
네이티브 ESM을 지원하는 PR 이 이미 있었지만 모듈 지원이 아직 실험적이기 때문에 닫혔습니다.

당신의 구현은 이것에 대한 지원을 추가하는 것이 쉬워야 한다는 것을 위안합니다. 우리는 이 기능을 간절히 기다리고 있습니다 :)

@demurgos :no_mouth: 예... 저 홍보는 제가 하고 나서 봤네요, d'oh 😃.

@harrysarson @boneskull
esm 패키지(이전 이름 @std/esm )는 이 커밋 에서 지원 .mjs 파일을 삭제했습니다.
.mjs 파일을 테스트하기 위해 더 이상 Mocha와 함께 사용할 수 없음을 의미합니다. 이에 대해서는 이번 호에서 설명합니다.

노드 또는 브라우저에서 안전하게 실행할 수 있도록 여전히 ES 모듈을 테스트할 수 있기를 원합니다.

현재 모듈 토론과 관련하여 .mjs 가 최종 결과에서 사용 가능해야 하며(유일한 솔루션이 아닐 수도 있지만 적어도 사용 가능함) import("./foo.mjs") 가 해당 ES 네임스페이스. CJS 모듈이 module.exports 에 해당하는 default 내보내기가 있는 모듈로 변환된다는 사실은 더 논쟁의 여지가 있지만 안전한 가정인 것 같습니다.

동적 import 를 사용하여 기본 ES 지원을 Mocha에 추가하는 것을 재고할 수 있습니까? 기능 플래그의 이름을 --experimental-es-modules (#3253에서)로 변경하여 이것이 현재 Node 지원의 발전에 의존한다는 것을 더 잘 알릴 수 있습니다.
기한에 따르면 최종 사양은 노드 12까지 도착하지 않으므로 현재 구현은 일정 시간 동안 유지됩니다(최종 제안의 비교적 안전한 하위 집합임).

@demurgos 저는 개인적으로 mocha에 대한 코드 구현을 커밋하기 전에 이것을 조금 더 기다리는 것을 선호합니다. 그러나 @boneskull 또는 @ScottFreeCode가 동의하지 않을 수 있습니까?

@demurgos

esm 패키지(이전 이름은 @std/esm)는 이 커밋에서 지원 .mjs 파일을 삭제했습니다.

esm 로더는 .mjs 에 대한 지원을 중단하지 않았습니다. 현재 --experimental-modules 구현을 따르고 require 로 .mjs 를 로드하려고 하면 오류가 발생합니다. 사용자는 ESM 구문 또는 동적 import() 을 사용하는 테스트 항목 파일에 대해 .mjs 또는 .js 의 후속 테스트 파일을 로드하는 데 여전히 .js 파일을 사용할 수 있습니다. esm 가 자체 테스트 를 수행하는 것처럼 .

기한에 따르면 최종 사양은 노드 12까지 도착하지 않으므로 현재 구현은 한동안 그대로 유지됩니다.

--experimental-modules 이 플래그가 지정되지 않은 상태로 착륙하는 데 정해진 시간은 없습니다. 노드 10의 지원 주기 _(향후 2년 중 언젠가)_에 도달할 수 있기를 희망하지만 확정된 것은 없습니다.

(그리고 최종 제안의 비교적 안전한 부분집합임).

현재 --experimental-modules 구현은 최종 제안과 호환되지 않을 수 있습니다. Node의 ESM 지원이 어떤 모습일지에 대해 몇 가지 논의가 있습니다. 일부 제안된 지침은 현재 실험적 구현과 호환되지 않습니다. --experimental-modules 에 대해 오늘 작성하는 코드를 어떻게 흔들느냐에 따라 최종 형식이 무엇이든 간에 작동하지 않을 수 있습니다.

esm 로더는 .mjs에 대한 지원을 중단하지 않았습니다.

제 요점은 esm 가 더 이상 .mjs 요구를 활성화하지 않으므로 .mjs 에 대해 Mocha의 테스트 검색을 더 이상 사용할 수 없다는 것입니다. 하지만 당신 말이 맞아요. 문서화되지 않았으므로 다른 사람들이 그것에 의존하더라도 실제로 브레이킹 체인지가 아닙니다.

마감일에 관해서는 이 문제 를 언급한 것입니다. 노드 11에 대한 시도와 노드 10 LTS로 이식될 수 있도록 노드 12에 대한 최종 구현이 있는 것 같습니다. 어떤 사람들은 그것이 더 빨리 일어나기를 바라고 다른 사람들은 서두르지 말라고 경고했습니다.

내 제안은 #3253을 병합하는 것입니다. 이것은 테스트 케이스를 로드하기 위해 require import(...) 를 사용하는 옵트인 메커니즘만 제공합니다. --experimental-modules 맥락에서 대부분 .mjs 에 적용될 것으로 예상하기 때문에 여전히 안전하다고 생각합니다. (네임스페이스 약속을 반환하는 .mjs 의 동적 가져오기는 유지될 가능성이 높습니다). 그러나 병합할 수 있는지 여부를 결정하고 너무 많이 추진하지 않도록 할게요.

다시 말하지만, 이 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

모카에서 플래그를 인식하지 못하기 때문에 NODE_OPTIONS 를 통과해야 합니다.

나는 여전히 mocha가 실험적인 ESM에 대한 더 나은 지원을 제공하기를 희망하지만 적어도 다른 도구 없이 오늘날 그것을 사용할 수 있는 방법이 있다는 것을 아는 것이 좋습니다.

@demurgos 이것은 당신이 찾은 좋은 작은 해결 방법입니다 :+1:.

mocha : smile: 과 함께 es 모듈을 사용하는 것이 (쉽지는 않더라도) 실제로 가능하다는 것을 보는 것이 좋습니다.

@demurgos 이 문제는 트랜스파일러를 사용하지 않고 ES6 스타일 테스트를 지원하는 것에 관한 것입니다. "빌드 타임"이란 무엇입니까? 테스트 진입점을 생성하는 데 사용하는 코드 는 트랜스파일러이며, 단지 특수화된 것입니다.

@rulatir
내가 빌드 도구를 사용한다고 언급했지만 이 도구는 이번 호에서 논의된 수준이 아닙니다. Mocha는 트랜스파일러에 의해 CJS로 낮아진 ESM이 아니라 기본 ESM으로 실행되고 있습니다.

내 메시지 참조:

빌드 시 가져오기 목록으로 진입점을 생성하지만 수동으로 작성하거나 거기에서 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에 기여해주셔서 감사합니다!

이 문제는 여전히 유효하며 종료하면 안 됩니다.

다가오는 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를 작성했습니다. fromSysPath from furi 을 사용할 수 있습니다. 변환은 모든 종류의 경로(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이 작동하지 않습니까?

나는 그것이 지금 최고의 솔루션이라는 데 확실히 동의합니다. 설정하기 가장 쉬운 솔루션이며 얼마 동안 출시되었습니다. 작동합니다. 제 경우에는 고유한 빌드 도구를 유지 관리하고 기본 ESM을 클래식 CJS 빌드의 대안으로 처리합니다. 기본 ESM에 대한 열망이 있음에도 불구하고 여전히 코드를 실행하는 유일한 방법으로 ESM을 사용하지 않는 것이 좋습니다. 결국 실험적입니다.stuck_out_ tongue:.

내 최근 메시지의 대부분은 기본 ESM을 사용하여 수행할 수 있는 작업을 공유하는 것입니다. 이것은 대부분 실험적인 작업이며 Node의 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 를 실행하고 보고서를 받을 수 있게 되면 이 문제가 해결된 것으로 간주합니다.

불행히도 현재로서는 Node가 ESM 지원을 파악할 때까지 기다려야 한다고 생각합니다. 확인을 해봐야겠지만 PR은 자동검출을 하지 않고 그냥 동적임포트로 모든 모듈(CJS나 ESM)만 임포트한 것 같아요. 구현은 모듈의 interop 스토리에 따라 달라집니다.

편집 : https://github.com/mochajs/mocha/pull/3253을 참조하고 있습니다. 모든 모듈을 ESM으로 로드할 수 있습니다(자동 감지 없음).

나는 비활성 문제를 감시하는 봇입니다.
이 문제에는 최근 활동이 없었으며 stale 레이블을 지정했습니다. 14일 이내에 더 이상의 댓글이나 활동이 없으면 이 문제를 닫겠습니다.
Mocha에 기여해주셔서 감사합니다!

노드 12에는 새로운 ESM 구현이 포함되어야 합니다. Mocha에서 ES 모듈을 어떻게 지원하는지 확인해보는 기회가 될 것입니다.

Mocha ESM을 사용할 때 GC 버그가 발생했지만 보고 및 확인되었으므로 수정해야 합니다( https://github.com/nodejs/node/issues/27492).

이 버그 외에도 위의 내 의견에 설명된 전략은 ESM과 함께 Mocha를 사용하는 데 여전히 작동합니다.

안녕하세요 Mocha 여러분, 좋은 도구를 만들고 유지해 주셔서 감사합니다!

이것은 참고용 의견일 뿐입니다. 지난 몇 달 동안 저는 아래와 같은 패치를 사용하여 Mocha와 * -test.mjs 작업을 해왔습니다. mocha test/*.mjs (트랜스파일러 또는 esm npm 모듈 없이)를 실행하는 데는 거의 문제가 없습니다.
https://gist.github.com/tadd/756d21bad38933c179f10e59bddee6b4

물론 이 패치는 Mocha 커미터를 위한 "프로덕션 준비"가 아닙니다. 이것은 가능한 한 빨리 테스트 코드에서 ESM을 사용하려는 Mocha 사용자를 위한 해킹일 뿐입니다.
--experimental-modules 옵션과 함께 Node.js v11을 사용했습니다. 현재 저는 v12를 사용 중이며 작동합니다.

다른 이야기지만 Node v12는 $#$ package.json $#$ 에 .cjs 확장과 "type" 필드를 도입했습니다. 이러한 점들도 고려되어야 할 것 같습니다.

안녕하세요 Mocha 여러분, 좋은 도구를 만들고 유지해 주셔서 감사합니다!

사실 저도 감사합니다 😄

loadFiles를 동기 상태로 유지하기 위해 다른 접근 방식을 취했습니다(아래 참조). 그것은 2 월부터 나를 위해 일했습니다. 다른 해킹과 달리 이것은 여전히 ​​c8 을 사용하여 모든 플래그, 검사/개발 도구 및 정확한 코드 검사를 허용합니다. 마지막 기능은 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 위의 댓글에서 Node 8부터 작동하는 솔루션을 게시했습니다. 다음은 기본 파일 URL 변환을 위해 Node 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 로 테스트를 실행합니다.

이 코드는 test.esm.js 를 commonjs 브리지로 사용하여 ESM 테스트를 로드하는 방식으로 작동합니다.

노드 12에는 IIAFE가 GC(nodejs/node#27492)에 의해 수집되는 문제가 보고되었으며, 다음 마이너 버전 중 하나에서 수정되어야 합니다(일부 해결 방법이 있을 수 있지만 아직 살펴보지는 않았습니다). 수정될 때까지 최신 Node 10 버전을 사용하는 것이 좋습니다.

오류가 있는 경우 Tar는 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 땅에 머물 수 있도록 하는 솔루션에 대한 내 요지를 참조하십시오_

@demurgos 10일 전에 게시한 Node 10.12에 대한 코드 스니펫에 감사드립니다!

Node 12.1을 실행 중이며 제대로 작동하는 것 같습니다. 이것이 곧 Mocha에 추가될 예정입니까, 아니면 Node 12에서 이 작업을 더 쉽게 수행할 수 있는 방법이 있습니까? 또한 이것을 --watch 모드에서 어떻게 사용합니까?

https://github.com/standard-things/esm 은 --require esm 와 함께 기본적으로 작동하는 것 같지만 다른 종속성을 버리는 것이 좋습니다. :) 감사합니다.

Mocha가 소스에서 ESM으로 전환하는 경우 Rollup은 CommonJS 및/또는 UMD뿐만 아니라 ESM 배포 파일도 제공할 수 있습니다.

여기서 또 다른 장점은 브라우저 HTML이 Mocha를 가져오기 위해 추가 스크립트 태그로 오염될 필요가 없다는 것입니다. 테스트 파일(또는 기본 테스트 진입 파일)은 가져오기를 수행할 수 있습니다(그리고 가져오기 경로만 추적하면 됩니다).

롤업용 CSS 플러그인을 사용하여 mocha.css 삽입을 허용하여 HTML 혼란을 최소화할 수 있습니다.

나는 비활성 문제를 감시하는 봇입니다.
이 문제에는 최근 활동이 없었으며 stale 레이블을 지정했습니다. 14일 이내에 더 이상의 댓글이나 활동이 없으면 이 문제를 닫겠습니다.
Mocha에 기여해주셔서 감사합니다!

나는 이것이 여전히 관련이 있다고 생각합니다.

(편집: ~Travis~) Node >=12.11.0에서 ES6 모듈로 Mocha를 실행할 수 있는 사람이 있습니까?
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 를 사용하는 경우 회문/커밋/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.js에서와 같이 브라우저 버전을 지정할 필요가 없다는 의미입니까? 릴리스 노트에서 브라우저 상태를 언급하는 것이 도움이 될 수 있다고 생각합니다(지원되지 않는 경우 지원 계획).

@brettz9
NodeJs ESM은 어떤 식으로든 Mocha 브라우저에 영향을 미치지 않습니다. 브라우저에서 실행하는 테스트는 NodeJ에 의해 로드되지 않으므로 HTML 코드에서 직접 수행해야 합니다.

제 기억이 맞다면 <script> 태그를 type="module" 속성으로 설정해야 합니다. 로드 순서를 유지하기 위해 테스트 파일과 Mocha 스크립트 모두에 대해. ESM은 수년 동안 브라우저와 함께 작업해야 했습니다.

@juergba : 예, 물론입니다. 하지만 컴파일 없이 import mocha from '../node_modules/mocha/mocha-esm.js'; 와 같은 것을 사용할 수 있도록 ESM 내보내기 배포 파일이 필요합니다. 그리고 컴파일을 사용하는 사람들을 위해(예: import mocha from 'mocha'; ), 번들러가 ESM 빌드를 자동으로 검색할 수 있도록 module in package.json 를 원할 것입니다.

모카는 commonjs로 작성되었습니다. package.json에 "module" 필드를 넣을 수 없습니다. Mocha는 ESM으로 작성된 노드에서 테스트 실행을 지원합니다.

ESM을 내부적으로 사용하도록 리팩토링하고 싶지 않은 경우에도 CommonJS 플러그인과 함께 Rollup을 사용할 수 있어야 하며 module 를 지원하기 위해 ESM 대상 파일을 지정할 수 있어야 합니다(예: Sinon 제안 및 대부분의 패키지 참고: jQuery는 유일한 다른 주목할만한 예외이며 ESM을 사용하도록 리팩토링되었습니다.

ESM으로 모카를 테스트하기 위한 샘플 프로젝트 를 만들었습니다. 테스트를 성공적으로 실행할 수 있지만 (_아직_) nyc/istanbul로 커버리지를 실행할 수 없었습니다. 당신의 도움을 환영합니다.

@concatime nyc 이 호환될 때까지 $# c8 를 사용할 수 있습니다. https://www.npmjs.com/package/c8

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

@cedx 템플릿 저장소를 업데이트했는데 작동합니다. 정돈 된!

Mocha v7.1.0에서 Node의 기본 ESM 지원을 구현했습니다.