Respect NODE_PATH environment variable

[josephshen]

Respect NODE_PATH environment variable

💻 Examples

1. find .
   .
   ./src
   ./src/App.tsx
   ./src/index.html
   ./3rd
   ./3rd/web
   ./3rd/web/vender

2. pushd ./3rd/web/vender
   install modules npm install parcel react react-dom

3. export NODE_PATH="$(pwd)/3rd/web/vender/node_modules"

   run parcel like this node 3rd/web/vender/node_modules/parcel/lib/cli.js src/index.html

   • before this patch, parcel will complain "Failed to resolve XXXX"
   • after this patch, parcel will work fine with respect NODE_PATH setting for module resolving.

fix this #6111 (comment)

[devongovett]

Not sure this is a good idea. One problem is that an absolute path in NODE_PATH will make the cache non-portable, since it'll be different for each person that runs the build.

[mischnic]

Another data point: webpack/webpack#4479 (comment)

NODE_PATH should not be used. Even the node.js documentation discourage usage: nodejs.org/api/modules.html#modules_loading_from_the_global_folders

This is omitted by inten[tion].

[toastal]

NODE_PATH is still supported, but is less necessary now

This isn’t doesn’t sound like it’s discouraging rather than pointing out a many use cases won’t need it.

A use case that could benefit from it is Nix/Guix derivations where you can’t do network requests for npm install so often other tools can provide the packages for you on the $NODE_PATH. In these environments, you wouldn’t be using Parcel cache anyhow.

I just tried to use npmlock2nix to get my modules for $NODE_PATH then I couldn’t run parcel --no-cache … because it was claiming my plugins weren’t installed since I’m to using npm’s mechanism for resolution.