Closed jedwards1211 closed 10 months ago
You can continue to use v4, which will continue to be commonjs, and maintenance will continue while a significant user base remains on v4.
If you want to migrate to ESM, then v5 is ready for you when you do.
I’m closing this issue as we’re confident in the choice we have made, and so there’s nothing to action here. Despite the issue being closed, I encourage further discussion here. If you have any concerns please continue, but I want to reaffirm: v5 will continue to be ESM only, and v4 will continue to be supported while it still sees heavy use.
Have you explicitly encouraged plugin authors (chai-as-promised
etc) to continue to maintain a commonjs version for the time being? Commonjs users won't really be well supported unless common plugins are part of the effort.
The core team has limited bandwidth, and ultimately it is up to plugin authors to distribute and maintain their code as they see fit.
This may or may not be related to this.
Upgrading from v4 to v5, when running tests using npx mocha -r ts-node/register --reporter list --recursive src/test/**
, may get you an error like:
TypeError [ERR_UNKNOWN_FILE_EXTENSION]: Unknown file extension ".ts" for /path/to/src/test/domain.ts
at new NodeError (node:internal/errors:387:5)
at Object.getFileProtocolModuleFormat [as file:] (node:internal/modules/esm/get_format:75:11)
at defaultGetFormat (node:internal/modules/esm/get_format:117:38)
at defaultLoad (node:internal/modules/esm/load:81:20)
at nextLoad (node:internal/modules/esm/loader:163:28)
at ESMLoader.load (node:internal/modules/esm/loader:605:26)
at ESMLoader.moduleProvider (node:internal/modules/esm/loader:457:22)
at new ModuleJob (node:internal/modules/esm/module_job:63:26)
at ESMLoader.#createModuleJob (node:internal/modules/esm/loader:480:17)
at ESMLoader.getModuleJob (node:internal/modules/esm/loader:434:34)
at async Promise.all (index 0)
at async ESMLoader.import (node:internal/modules/esm/loader:530:24)
at async importModuleDynamicallyWrapper (node:internal/vm/module:438:15)
at async formattedImport (/path/to/node_modules/mocha/lib/nodejs/esm-utils.js:9:14)
at async Object.exports.requireOrImport (/path/to/node_modules/mocha/lib/nodejs/esm-utils.js:42:28)
at async Object.exports.loadFilesAsync (/path/to/node_modules/mocha/lib/nodejs/esm-utils.js:100:20)
at async singleRun (/path/to/node_modules/mocha/lib/cli/run-helpers.js:125:3)
at async Object.exports.handler (/path/to/node_modules/mocha/lib/cli/run.js:370:5)
Solution: downgrade to chai@4.x
.
@bamse16 it will be the same
if you use loader: "ts-node/esm"
in mocharc
, instead of -r ts-node/register
(or as well as), it may solve it
basically -r
is for "require" (commonjs), whereas loader
is for ESM
Mocha's support for TypeScript with ESM is still experimental (still!!): https://github.com/mochajs/mocha-examples/issues/47
ESM loaders are only at release candidate status in the current Node LTS (20): https://nodejs.org/dist/latest-v20.x/docs/api/module.html#customization-hooks
Furthermore it doesn't seem like a majority of npm packages are likely to become pure ESM anytime soon: https://lannonbr.com/blog/esm-checker-postmortem/
I think that's a sufficient example why it's just too soon for the entire ecosystem to move to pure ESM. Many projects will be unable to migrate to a pure-ESM version of Chai for a long time. I may be the first person to complain about this but I know others are soon to follow.