bugfix in v1.18 breaks when a core module is not available in a given node version

[cruzdanilo]

v1.18 broke some eslint plugins inside vscode (node v12)

const { appendFile } = require('fs/promises');

gives the following errors:

- Unable to resolve path to module 'fs/promises'. eslint(import/no-unresolved)
- "fs/promises" is not found. eslint(node/no-missing-require)

when running via cli using node v14 there is no error

[ljharb]

fs/promises does not exist in node 12. It's only a core module in node 14+.

[ljharb]

vscode should be using whatever node you have installed - in your case, it should be using node 14 if you're running your project in node 14.

[cruzdanilo]

@ljharb this is a breaking change in a minor update

[ljharb]

In what way is it a breaking change?

1. For resolve, it's an additive change (added in v1.16.0, btw, not v1.18.0), since it now reports true for an additional core module
2. For eslint plugins (including eslint-plugin-import, which i maintain), new warnings are not semver-major, they are semver-minor, based on eslint's own semver policy.
3. In this case, it's clearly a bug fix, because in node 12, your code is broken, and these linting rules are catching your broken code.
4. eslint usage only matters on the CLI. breaking people in an IDE when the CLI works is a bug in the IDE, not in eslint or eslint plugins.

[cruzdanilo]

can't a ci build/deploy script run on a different node version from the production environment?
if this script stops on lint errors, wouldn't this error break it?

[ljharb]

They can, but certainly shouldn't.

resolve has always used "the current version of node" to determine what constitutes a core module; this may just be the first time you've run into it because there aren't often new core modules added.

[ljharb]

Put another way, any "fix" here would be to NEVER consider fs/promises a core module without a breaking change. In node 12, fs/promises has never actually been considered a core module by resolve or its dependents.

In other words, this isn't new breakage - in node 12, this code would never have passed the linter, as far as I can tell. Did it ever pass for you?

[cruzdanilo]

yes, fs/promises + resolve@1.17.0 + node@12 definitely pass

[ljharb]

oh hmm, you're right. That means that resolve v1.17 had a bug - fs/promises is only a core module in node v10.0.0 and v14+. This remains a bugfix, albeit a potentially disruptive one - the bug was that prior to v1.18, resolve incorrectly reported that every possible core module was in fact a core module, even if it wasn't in that version of node.

This bug was introduced in e5da77e, in resolve v1.13.0 (published in November 2019), in #203, and was inadvertently fixed by me when I extracted resolve's "is core" functionality into is-core-module, which began being used by resolve in v1.18.0.

Unfortunately, every bug fix is a breaking change for someone relying on the bug - in this case, resolve needs to match the behavior users were expecting before v1.13.0 broke them, and that's what v1.18.0 fixes.

[dlong500]

I can't tell if my problem relates to this issue or not, but I'm using node 15.10 with the latest version of eslint and get an Unable to resolve path to module for an import like import { stat, readdir } from 'fs/promises'. The odd thing is I'm finding almost nothing on Google on the topic (even though the promise-based import syntax is shown in the Node v15 docs).

EDIT I thought I had fixed the issue by wiping node_modes and the lock file, but I had also introduced an error in the eslint config file that prevented it from loading at all, so my issue still occurs.

[ljharb]

@dlong500 are you getting that issue inside your editor, or on the command line? for example, vscode ships its own copy of node, so that's the version that resolve would be using.

[dlong500]

@ljharb yes, it's in vscode, and I understand what you're saying, but shouldn't we be able to specify the node version used for linting? vscode is always going to be using an older version of node internally for itself, but my code isn't going to be running in vscode.