-
-
Notifications
You must be signed in to change notification settings - Fork 3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make native Node ESM support configurable #4853
Comments
@tbranyen I haven't really understood your request, but it seems very weird to me to configure a project as ESM (via Have you noted this in Babel's docs?
Have you tried this: babel-register-esm? @giltayar cc |
@juergba ah I missed that in the babel register docs 👍. This may be a non-issue for Mocha in that case. |
If you'd like to disable ESM, just don't put But the ecosystem is slowly but inexorably moving to native ESM, so I would definitely investigate moving to ESM. If you need on the fly babel transpilation, like npm install babel-register-esm
mocha --loader babel-register-esm testfile.js |
@giltayar @juergba I've been able to confirm my problem using plain Node and @babel/register as well (no mocha). Shame, because all my other tooling still works since they don't "shadow" the node process like Mocha does. I use the export * from './dist/es/lite.js'; The rest of the project is not necessarily "Node ESM". Given that this is not a uniquely Mocha problem, I think it's safe to close. I will investigate using a Node ESM loader to allow extension-less imports as that seems to be the only real blocker ATM. |
Looks like Node provides an option to support extension-less imports via https://nodejs.org/api/esm.html#customizing-esm-specifier-resolution-algorithm: I set the following config in {
"node-option": [
"experimental-specifier-resolution=node"
]
} |
I'm not sure how to use or configure ESLint yet, I have yet to try it out myself. I'm going to upgrade their versions to the latest releases though. This actually made things work very easily as ESM out of the box! Extra awesome! I thought I was going to have to configure a bunch more to get it working. Turns out Mocha supports it, it's Jest that doesn't. Or something along those lines when I tried it last. I think that was for JSMediaTags I was getting stuck with those kinds of issues. I didn't end up using these links to set things up, but it helped me get to the right place. The plain dependencies fixed the issue itself, it seems. mochajs/mocha#4853 https://daveschinkel.medium.com/setting-up-mocha-js-to-run-typescript-42f3099450eb https://stackblitz.com/edit/node-pawwmm https://mochajs.org/#serial-mode https://stackoverflow.com/questions/54805319/mocha-error-no-test-files-found-test-npm-err-test-failed
Is your feature request related to a problem or a nice-to-have?? Please describe.
Relates to: #4038
Currently unable to use
"type": "module"
in my mono-repo package as then Mocha runs all tests assuming native node, instead of using the configured@babel/register
extensions loader. There seems to be a conflation that because a package is designated as native Node ESM, that means the tests should run that way. There is a big distinction in my case.I import my code using the extension-less form:
(See build failure in Additional context below)
Describe the solution you'd like
I would like to see an option to be able to disable Mocha's Node interpretation, regardless of
.mjs
or"type": "module"
in the rootpackage.json
.Something like:
Describe alternatives you've considered
Additional context
The text was updated successfully, but these errors were encountered: