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
{{ message }}
Repository navigation
Fall back to a user-configured directory when resolving imports #67354
Node.js doesn't support a user-configured fallback directory when trying to resolve imports. It only resolves those imports against a node_modules directory in the same (or ancestor) directory as the importing file. This current architecture falls short for standalone scripts, which don't have a node_modules directory around.
This artificial limitation hinders Node.js's ability to fulfill its goal to "Run JavaScript Everywhere".
What is the feature you are proposing to solve the problem?
Fall back to a user-configured directory when normal resolution fails
What alternatives have you considered?
Hardcoding absolute paths using the file:// protocol
fragile
not portable
A symlinked node_modules in the importing file's directory
overridden once npm install is executed
A symlinked node_modules in a shared ancestor directory
must be located at the filesystem root to cover every location
A register hook that retries from a specified directory after an ERR_MODULE_NOT_FOUND/MODULE_NOT_FOUND error
must be included in every importing file
doesn't work with static imports
isn't compatible with tooling (e.g., IDEs don't run it, so they treat the imported modules like unresolved ones)
This is a very intentional design choice. CJS has a deprecated env var for this, and it's proven to be a horrifically terrible idea to make the location of modules configurable, which is why ESM explicitly avoids doing so.
Standalone scripts can use SEA to package up a bundled file into a single executable; that's the path I'd suggest.
Activity
ljharb commentedon Nov 9, 2026
This is a very intentional design choice. CJS has a deprecated env var for this, and it's proven to be a horrifically terrible idea to make the location of modules configurable, which is why ESM explicitly avoids doing so.
Standalone scripts can use SEA to package up a bundled file into a single executable; that's the path I'd suggest.