Node: NODE_PATH in package.json

[dylanized]

I wish there was a way to add a folder or folders to the Node module path via package.json, instead of just thru the NODE_PATH env var.

Currently, a user can add a folder to the module path by running a script like this:

NODE_PATH=my_modules node index.js

This allows the user to load modules from my_modules without specifying the path, making the script cleaner and more portable.

I wish there was way to do this inside package.json, perhaps with a "path" array?

"path": [
  "my_modules"
]

By specifying the path inside the package.json instead of the CLI command, it would apply to any script within the package. Subsequently, NODE_PATH usage could be removed from NPM script commands.

Thanks for considering this!

[andrewgremlich]

Ya know, this idea doesn't seem that bad. It definitely seems like it could help make the package.json cleaner! As well adding this could cater more towards whomever has what preference.

[bnoordhuis]

I believe the general consensus among Node.js maintainers is that NODE_PATH was a mistake but is in too widespread use to actually remove. I doubt there's much enthusiasm for codifying it in package.json.

Ideally, there are fewer variables, not more, when trying to figure out where a module is loaded from.

edit: and another reason is that Node.js is fairly agnostic to the contents of package.json files, it only looks at the "main" property.

[dylanized]

If NODE_PATH is a mistake, then what is the recommended way to get rid of ../../../ paths for require statements? I find NODE_PATH essential for this purpose.

[demurgos]

NODE_PATH is considered a mistake because it makes it hard to find out which module is actually resolved. You can't resolve the modules statically without this runtime parameter (it can break bundlers for example). NODE_PATH can't be removed from the commonjs loader, but is actually removed in the current experimental ESM loader.

../../.. involves zero magic and is compatible with the web, depending on your situation it may be better to keep it. If you want to get rid of it, the recommended way is to use npm link or yarn link (npm has some issues with it, should be sorted out in version 7). Usually long relative paths go in one direction, some leaf module imports stuff from core parts of the app. The solution can be as simple as keeping these core module in a sub-directory; or splitting them in their own project and publishing them to a registry (npm or private).
An other solution is to register your own require handler an programmatically deal with module's resolution.

Longer term, the ESM working group is working on supporting loaders with custom resolution. There's also a proposal for package maps to declaratively associate modules with paths, but I'm not sure if Node would support it (it's targeted at browsers).

[Trott]

This conversation seems to have run its course and it is unlikely this feature will be added to Node.js. Thanks for the request. I'm going to close this at this time.