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

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)

About this issue

Original URL
State: closed
Created 3 years ago
Reactions: 7
Comments: 35 (23 by maintainers)

Commits related to this issue

Add ESLint Node.js runtime config To avoid issues like this: https://github.com/benmosher/eslint-plugin-import/issues/2031#issuecomment-826160498 — committed to upleveled/system-setup by karlhorky 3 years ago
Add ESLint Node.js runtime config To avoid issues like this: https://github.com/benmosher/eslint-plugin-import/issues/2031#issuecomment-826160498 — committed to gruvector/system-setup by gruvector 3 years ago

Most upvoted comments

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! 🙌

karlhorky on Apr 24, 2021

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

karlhorky on Apr 20, 2022

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!

acidoxee on Apr 20, 2022

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

acidoxee on Apr 19, 2022

@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.

TriStarGod on Jan 27, 2022

@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",

karlhorky on Jan 26, 2022

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)

ljharb on Sep 2, 2021

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

andreavaccari on Sep 2, 2021

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

bmish on Sep 2, 2021

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

ljharb on Apr 24, 2021

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.

ljharb on Apr 24, 2021