[no-unresolved]: Unable to resolve path to module with node: protocol specifier

[karlhorky]

Hi there, thanks for this plugin, super useful! 👍

Ran into an issue when using the new node: prefix for builtin / core modules (currently in v16, but will be backported): import/no-unresolved cannot resolve the path to the module:

import fs from 'node:fs';
                ~~~~~~~
                   ^---- Unable to resolve path to module 'node:fs'  eslint(import/no-unresolved)

[ljharb]

Indeed; the new protocol support isn’t added to resolve yet. Please file an issue there; I’ll get to it as soon as i can.

[karlhorky]

Great! ...uh where would issues to resolve be submitted? In ESLint core repo? https://github.com/eslint/eslint

[ljharb]

resolve is https://github.com/browserify/resolve but it's actually in https://github.com/inspect-js/is-core-module now, and I'm already working on it :-) so no worries.

Can you cite a reference for where it will be backported? I'm pretty sure the addition of node: was considered semver-major.

[karlhorky]

Ah ok, thanks :)

Here's where I read from @jasnell about the backporting at least to v14 ("hopefully soon" "it'll take a while"): https://twitter.com/jasnell/status/1385239259838222336

[ljharb]

the "take a while" was referring to when it will be safe for library authors to use that syntax :-) "hopefully" is what describes the backporting.

[karlhorky]

Ah right, misread this one, good point!

[ljharb]

is-core-module v2.3.0 has been released, which should address the problem.

[karlhorky]

Hmm, just upgraded all versions of the transitive deps on is-core-module to 2.3.0 and still getting this reported from import/no-unresolved... 🤔

[ljharb]

Is eslint running on node 16? Perhaps you’re in vscode, and it’s using its bundled copy of node?

[karlhorky]

Ah yeah, in VSCode ESLint extension, it's still using Node 12:

ESLint server running in node v12.18.3

But on the command line, all is good! 🙌

[andreavaccari]

@ljharb I'm running eslint v7.32.0 on node v14.16.0 and I'm still getting import/no-unresolved errors.

Is this expected to work on v14 or is it necessary to upgrade to v16?

[ljharb]

@andreavaccari the node: prefix does not work at all on node 14. so yes, if you want them to resolve, you need to be on node 16 both when you run eslint and also in production.

[bmish]

Support for node: was backported to Node v14.13.1 and v12.20.0: https://nodejs.org/api/esm.html#esm_node_imports

[ljharb]

@bmish aha, well then that's what i was missing :-) i can update is-core-module shortly to account for that.

[sverweij]

☝️ what @bmish says - but only for ESM. For CJS node 14.17.5 and node 12.22.1 still barf with cannot find module 'node:os' when running console.log(require("node:os").cpus()).

[ljharb]

ahhh, that's more complicated then. is-core-module is part of resolve, which only applies to CJS - and this plugin is not written for native ESM, it just works for it when specifiers also work in both.

In that case, there's nothing I can really do about it until resolve supports ESM, which is a ways off.

[andreavaccari]

Thanks for clarifying the situation! I reverted to the traditional imports and turned off unicorn/prefer-node-protocol.

[ljharb]

I'd suggest keeping that rule off anyways; the advantage to using node: is close to zero, and the downsides are huge (because it hurts backwards compatibility)

[TriStarGod]

@ljharb

When I try import ... from "node:fs"; it fails with

Unable to resolve path to module 'node:fs'. eslint(import/no-unresolved)

node: v16.13.2
"typescript": "^4.5.5"
"eslint": "^8.7.0"
"eslint-plugin-import": "^2.25.4"

I reinstalled "eslint-plugin-import" and its package file claims its using "is-core-module": "^2.8.0". I'm not using unicorn but plan to in the future.

How can I troubleshoot this problem?

[ljharb]

@TriStarGod is this on the command line, or in your editor? vscode bundles its own node 12, i believe.

[TriStarGod]

@ljharb Its in the vscode editor

[ljharb]

@TriStarGod so that's your problem. On the command line, it will work fine. That means your "fix" is either "don't use node: as a prefix, because it adds zero value to do so anyways", or "configure vscode to use your system's node instead of the node it bundles".

[TriStarGod]

@ljharb My vscode version is 1.63.2 and its using Node.js 14.16.0 . I believe Node.js 14 is also suppose to support node: .

Doesn't node: enforce using node specific package files?

[ljharb]

@TriStarGod that support was added in node v14.18, so v14.16 is too old for that.

No, if you import from fs that's always node's core fs module - using node:fs offers precisely zero additional guarantees, altho it may be a less ambiguous signal if you're using broken tooling that doesn't assume node's de-facto standard conventions.

[karlhorky]

@TriStarGod you're probably looking for the following setting in your VS Code settings.json (this enables your system version of Node.js):

"eslint.runtime": "node",

[TriStarGod]

@karlhorky I tried it and "eslint.runtime": "C:\Program Files\nodejs\node.exe" but both didn't work. I'll take @ljharb advice and not even use it since there isn't any benefit.

[acidoxee]

Sorry to reignite the discussion, but this rule still seems to throw for CJS when requiring built-in modules with the node: protocol, despite its support having been added in Node v14.18.0.

I'm using Node v14.19.1, and when using const path = require('node:path'), the rule errors out with Unable to resolve path to module 'node:path'. Switching to Node v16.14.2 works, for instance.

Any chance of it being revisited for Node >=14.18? 🙏

[ljharb]

@acidoxee i've got lots of tests in is-core-module that this already works. Where does the rule error out - on the terminal or in an IDE?

[acidoxee]

I've got both my terminal and IDE running the same Node version, and yielding the same error. Given the previous problems people had with bad IDE config, I ran ESLint from the terminal to be sure not to bother you for the same mistake, and I can confirm I'm having the same error.

I'll try to setup a minimal project to try and reproduce the error on the same Node and package versions.

[ljharb]

@acidoxee thanks; can you also confirm you have the latest version of is-core-module in your graph? It's possible your lockfile has you stuck on an older one.

[acidoxee]

There's indeed a bunch of different versions of it in my lockfile because of several packages that require them, but the version present at the very root of my node_modules folder is 2.8.1. This does seems to be the version eslint-plugin-import is using if I'm not mistaken?

As there's no is-core-module folder in node_modules/eslint-plugin-import/node_modules, but there's one at the root node_modules (the 2.8.1 one), I also believe this should be the proper version required by eslint-plugin-import at runtime?

[ljharb]

yep, that sounds right. i just released v2.9.0 but that shouldn't affect this. If you could file a new issue that'd be great.

[acidoxee]

Sure, I'll continue this tomorrow and keep you updated. Thanks for your help!

[acidoxee]

Bad news, I couldn't reproduce the error with a minimal setup. My current ESLint config has a lot more plugins, configs and overrides than the example I was trying to set up, which seems to work great despite having exactly the same Node and package versions (I verified them manually in the lockfile and in my node_modules).

I don't really know what could make the rule fail in my current full-size setup, which is configured exactly the same, regarding the import plugin at least 😕 I absolutely can't downsize my current project bit by bit, because it's a huge monorepo with 30+ packages where ESLint was completely absent, so removing each piece to try the rule again would take forever.

I'll put this on the side for a while since I can't afford to spend much more time on this. Thanks for your help anyway @ljharb and for your reactivity, I'll ping you someday if I ever figure it out!

[karlhorky]

If it's a monorepo, you may have a central yarn.lock or package-lock.json file that contains the older versions of is-core-module, which you may be able to manually upgrade - for example, upgrading a version in yarn.lock by hand like this: https://www.youtube.com/watch?v=iOYTpHRzL0A