Skip to content
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

Stopped working on Node.js v10.24: "Error: Not supported" caused by ESM import #4652

Closed
4 tasks done
alexander-fenster opened this issue Jun 7, 2021 · 6 comments · Fixed by #4653
Closed
4 tasks done
Labels
area: node.js command-line-or-Node.js-specific area: usability concerning user experience or interface

Comments

@alexander-fenster
Copy link
Contributor

Prerequisites

  • Checked that your issue hasn't already been filed by cross-referencing issues with the faq label
  • Checked next-gen ES issues and syntax problems by using the same environment and/or transpiler configuration without Mocha to ensure it isn't just a feature that actually isn't supported in the environment in question or a bug in your code.
  • 'Smoke tested' the code to be tested by running it outside the real test suite to get a better sense of whether the problem is in the code under test, your usage of Mocha, or Mocha itself
  • Ensured that there is no discrepancy between the locally and globally installed versions of Mocha. You can find them with: node node_modules/.bin/mocha --version(Local) and mocha --version(Global). We recommend that you not install Mocha globally.

Description

In lib/esm-utils.js, hasStableEsmImplementation returns true on Node.js v10.24.1 even though it must only return true on versions >= 12.22.

Steps to Reproduce

In the cloned mocha repository:

$ node -e 'const path = require("path"); const utils = require("./lib/esm-utils"); utils.requireOrImport(path.resolve("./index.js"))'

Expected behavior: [What you expect to happen]

No error

Actual behavior: [What actually happens]

(node:22250) UnhandledPromiseRejectionWarning: Error: Not supported
    at formattedImport (/Users/fenster/repos/mocha/lib/esm-utils.js:7:31)
    at Object.exports.requireOrImport.hasStableEsmImplementation [as requireOrImport] (/Users/fenster/repos/mocha/lib/esm-utils.js:46:38)
    at [eval]:1:79
    at Script.runInThisContext (vm.js:122:20)
    at Object.runInThisContext (vm.js:329:38)
    at Object.<anonymous> ([eval]-wrapper:6:22)
    at Module._compile (internal/modules/cjs/loader.js:778:30)
    at evalScript (internal/bootstrap/node.js:590:27)
    at startup (internal/bootstrap/node.js:265:9)
    at bootstrapNodeJSCore (internal/bootstrap/node.js:623:3)

Reproduces how often: [What percentage of the time does it reproduce?]

100%

Versions

9.0.0

  • The output of mocha --version and node node_modules/.bin/mocha --version:
  • The output of node --version:
  • Your operating system
    • name and version:
    • architecture (32 or 64-bit):
  • Your shell (e.g., bash, zsh, PowerShell, cmd):
  • Your browser and version (if running browser tests):
  • Any third-party Mocha-related modules (and their versions):
  • Any code transpiler (e.g., TypeScript, CoffeeScript, Babel) being used (and its version):

Additional Information

@juergba
Copy link
Contributor

juergba commented Jun 7, 2021

In lib/esm-utils.js, hasStableEsmImplementation returns true on Node.js v10.24.1 even though it must only return true on versions >= 12.22.

We dropped support of Node v10 in Mocha v9.0.0 as a breaking change.

@alexander-fenster
Copy link
Contributor Author

@juergba I understand that :) My point here is that if it was hard to backport the code to keep it working on Node 10, it would've been a fair deal to drop it completely and not accept any fixes. In this particular case though, it's just a matter of a small (and correct) fix which might keep the code working on the older versions for the time being.

Of course we'll be able to pin our workflows to 8.x (since we do need to keep supporting Node 10 for a little bit longer), but - again - I personally don't like the idea of breaking the stuff that can still work. Up to you though :)

@juergba
Copy link
Contributor

juergba commented Jun 8, 2021

@alexander-fenster I like clear cuts, but could live with your change.

@giltayar cc

@williamdes
Copy link

williamdes added a commit to sudo-bot/gh-deployer that referenced this issue Jun 12, 2021
@williamdes
Copy link

williamdes commented Jun 12, 2021

I am on Node v12.16.2

You can see my migration to use back the module after upgrading to Mocha v9: sudo-bot/gh-deployer@3965e27

Error: Not supported
    at formattedImport (/mnt/Dev/@sudo/gh-deployer/node_modules/mocha/lib/esm-utils.js:7:31)
    at Object.implementationOfRequireOrImportForUnstableEsm [as requireOrImport] (/mnt/Dev/@sudo/gh-deployer/node_modules/mocha/lib/esm-utils.js:87:14)
    at Object.exports.loadFilesAsync (/mnt/Dev/@sudo/gh-deployer/node_modules/mocha/lib/esm-utils.js:71:34)
    at Mocha.loadFilesAsync (/mnt/Dev/@sudo/gh-deployer/node_modules/mocha/lib/mocha.js:467:19)
    at singleRun (/mnt/Dev/@sudo/gh-deployer/node_modules/mocha/lib/cli/run-helpers.js:125:15)
    at exports.runMocha (/mnt/Dev/@sudo/gh-deployer/node_modules/mocha/lib/cli/run-helpers.js:190:10)
    at Object.exports.handler (/mnt/Dev/@sudo/gh-deployer/node_modules/mocha/lib/cli/run.js:366:11)
    at /mnt/Dev/@sudo/gh-deployer/node_modules/yargs/build/index.cjs:443:71

williamdes added a commit to sudo-bot/gh-deployer that referenced this issue Jun 12, 2021
@juergba
Copy link
Contributor

juergba commented Jun 12, 2021

@williamdes this issue is about Mocha v9 and javascript.

As far as I can see you have had your issue 12 days ago, at that time Mocha v9 hasn't been published yet.
Furthermore you are on typescript and ts-node, sindresorhus is explaining in his guide what has to be done in this case.

Edit: I recommend to pin your sindresorhus dependency to a version before pure ESM. Otherwise you will have to invest some time to get through this experimental esm-loader-story. It's not really fun.

GerHobbelt added a commit to GerHobbelt/markdown-it-footnote that referenced this issue Jul 1, 2021
…y this ESM error does NOT pop up on the local (Windows) dev machines.

```
Error [ERR_REQUIRE_ESM]: Must use import to load ES Module: /home/circleci/project/test/test.js
require() of ES modules is not supported.
require() of /home/circleci/project/test/test.js from /home/circleci/project/node_modules/mocha/lib/esm-utils.js is an ES module file as it is a .js file whose nearest parent package.json contains "type": "module" which defines all .js files in that package scope as ES modules.
Instead rename test.js to end in .cjs, change the requiring code to use import(), or remove "type": "module" from /home/circleci/project/package.json.

    at Object.Module._extensions..js (internal/modules/cjs/loader.js:1102:13)
    at Module.load (internal/modules/cjs/loader.js:950:32)
    at Function.Module._load (internal/modules/cjs/loader.js:790:14)
    at Module.require (internal/modules/cjs/loader.js:974:19)
    at require (internal/modules/cjs/helpers.js:92:18)
    at Object.exports.requireOrImport (/home/circleci/project/node_modules/mocha/lib/esm-utils.js:54:18)
    at async Object.exports.loadFilesAsync (/home/circleci/project/node_modules/mocha/lib/esm-utils.js:73:20)
    at async singleRun (/home/circleci/project/node_modules/mocha/lib/cli/run-helpers.js:125:3)
    at async Object.exports.handler (/home/circleci/project/node_modules/mocha/lib/cli/run.js:366:5)
make: *** [Makefile:35: test] Error 1
npm ERR! code ELIFECYCLE
npm ERR! errno 2
npm ERR! @gerhobbelt/[email protected] test: `make test`
npm ERR! Exit status 2
npm ERR!
npm ERR! Failed at the @gerhobbelt/[email protected] test script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.

npm ERR! A complete log of this run can be found in:
npm ERR!     /home/circleci/.npm/_logs/2021-07-01T12_52_07_807Z-debug.log
```
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: node.js command-line-or-Node.js-specific area: usability concerning user experience or interface
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants