Good point about needing to test it either way. At least on my environment, requiring a module that's installed globally doesn't work.
It seems that it's [not supposed to work](https://stackoverflow.com/a/15646750/237285), unless [NODE_PATH is set](https://nodejs.org/api/modules.html#modules_loading_from_the_global_folders) or the package is installed to a fixed set of three GLOBAL_FOLDERS (on Ubuntu using the nodesource distribution, globally installed modules don't go into any of them, but into /usr/lib/node_modules). A grep through the source code seems to indicate that `resolve` doesn't read NODE_PATH or check the GLOBAL_FOLDERS, but expects them to be passed as the `paths` argument. So to achieve full fidelity, we'd probably need to pass NODE_PATH and those three directories to resolve. Even then, in common cases globally installed modules won't be accessible. Certainly doable. Looking for use-cases to work off of, it seems RisingStack and other [use NODE_PATH to avoid relative paths in require()](https://blog.risingstack.com/node-js-best-practices-part-2/), but they don't use it with whole packages. --- Bottom line, globally installed modules *probably* shouldn't work, but it depends on whether the node environment is setup to install global packages to one of GLOBAL_FOLDERS. I don't know if we can assume that modern distributions avoid that, though [this thread](https://github.com/creationix/nvm/issues/586) suggests we can. Supporting NODE_PATH would make cordova-fetch fully compatible with npm resolution algorithm AFAIK, and the test for it seems straightforward. [ Full content available at: https://github.com/apache/cordova-fetch/pull/44 ] This message was relayed via gitbox.apache.org for [email protected]
