You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Short description: resolve fails to handle Node.js' imports field style imports.
Steps to reproduce:
Add a simple entry to imports fields to package.json:
+ "imports": {+ "#src/*": "./src/*"+ },
Create a src/module-1.js file
Call resolve (async or sync) with #src/module-1.js argument
Expected behaviour: resolve() returns the full path of the module
Actual behaviour: resolve() throws an error
Minimal reproducible example: I created the resolve-nodejs-import StackBlitz project to showcase the issue with some guiding. Running npm start should execute the script and show the behaviour of resolve() in various circumstances.
This project is very minimal and doesn't utilise any bundler but instead relies on Node.js' module resolution and imports field. By this, the imports are non-relative paths with TypeScript style import aliases. For example the src/lib/word-resolver.mjs file has the following dependencies (at L3-6):
This works just fine on run, I don't experience any side-effects by calling pnpm start.
I decided to upgrade ESLint to v9 and after tinkering the config file, I received a lot of errors from import's no-unresolved rule when I ran eslint.
After some investigation I realised the issue lies deeper at resolve, as it doesn't unfold module names starting with a #. I believe the issue is at the check where the module's nature is determined:
varmoduleError=newError("Cannot find module '"+x+"' from '"+parent+"'");
moduleError.code='MODULE_NOT_FOUND';
cb(moduleError);
}
});
Closing thoughts
The issue is not related to ESLint v9, but I mistakenly didn't include eslint-plugin-import to my .eslintrc.json's extends field (at L7-10) and only realised the mistake on update.
I can understand if you believe it's out of the scope of this package, although I'd think the imports field feature would be supported. In that case a possible workaround for me is to wrap eslint-import-resolver-node and transform imports starting with # to project relative paths.
However, if you believe it's worth fixing it, I'd also volunteer to provide a change-set for review!
The text was updated successfully, but these errors were encountered:
Imports fields is not supported
Overview
Short description: resolve fails to handle Node.js' imports field style imports.
Steps to reproduce:
package.json
:src/module-1.js
file#src/module-1.js
argumentExpected behaviour:
resolve()
returns the full path of the moduleActual behaviour:
resolve()
throws an errorMinimal reproducible example: I created the resolve-nodejs-import StackBlitz project to showcase the issue with some guiding. Running
npm start
should execute the script and show the behaviour ofresolve()
in various circumstances.Context
I'm using the resolve package as a transitive dependency of eslint-plugin-import for a small project I created, wordoftheday.
This project is very minimal and doesn't utilise any bundler but instead relies on Node.js' module resolution and imports field. By this, the imports are non-relative paths with TypeScript style import aliases. For example the
src/lib/word-resolver.mjs
file has the following dependencies (at L3-6):This works just fine on run, I don't experience any side-effects by calling
pnpm start
.I decided to upgrade ESLint to v9 and after tinkering the config file, I received a lot of errors from import's no-unresolved rule when I ran
eslint
.After some investigation I realised the issue lies deeper at resolve, as it doesn't unfold module names starting with a
#
. I believe the issue is at the check where the module's nature is determined:resolve/lib/sync.js
Lines 101 to 111 in fd788d9
resolve/lib/async.js
Lines 141 to 164 in fd788d9
Closing thoughts
The issue is not related to ESLint v9, but I mistakenly didn't include eslint-plugin-import to my
.eslintrc.json
's extends field (at L7-10) and only realised the mistake on update.I can understand if you believe it's out of the scope of this package, although I'd think the imports field feature would be supported. In that case a possible workaround for me is to wrap eslint-import-resolver-node and transform imports starting with
#
to project relative paths.However, if you believe it's worth fixing it, I'd also volunteer to provide a change-set for review!
The text was updated successfully, but these errors were encountered: