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

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

About this issue

Original URL
State: closed
Created 4 years ago
Comments: 17 (9 by maintainers)

Most upvoted comments

Just to follow up: I did figure out with the vscode eslint extension you can add an eslint.runtime setting to specify a node executable to use when running eslint. This is supposed to be a path, but just setting eslint.runtime: "node" appears to be enough to get eslint to use the version of node installed on the system and not the internal version used by vscode (it probably works because it looks at the system path variable which includes the external node binary). And yes, this does allow eslint to properly see fs/promises as a core module.

Thanks for the responses. It helped me to narrow down the root cause of my issue.

dlong500 on Mar 2, 2021

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

cruzdanilo on Oct 22, 2020

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 on Oct 22, 2020