Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
Look for node_modules in any recursive parent directory #44
It turns out that when using
Do you think you could write a few tests for this, @ariofrio? That would be awesome! I think a few unit tests for
moved this from 🐣 New PR / Untriaged
to ⏳ Waiting for Review
in Apache Cordova: Tooling Pull Requests
Sep 5, 2018
Working on this now. Not sure what a unit test for
I have in mind an "integration" test that creates this directory structure:
And then tries to run pathToInstalledPackage to find
What do you think?
Update: Committed a version of this. Verified locally that the new tests fail on master. The first test succeeds because it tests finding the package in the current directory, which already worked.
The tests look good to me on a first glance
I never expected
One last thing: it would be nice to add a test that shows that globally installed modules will be taken into account too. Not sure how to best test this, but maybe you have an idea?
Huh, is taking into account globally installed modules expected behavior?
Seems like it would be error-prone, since running the same command on a different environment without that globally installed module would fail.
Not sure if resolve provides that functionality, anyway, reading the docs.
While I agree that taking global modules into account might be problematic, I would have thought
Any way: all the more reason to assert the presence/absence of this behavior in the current implementation.
Good point about needing to test it either way.
Research and links about globally-installed modules
At least on my environment, requiring a module that's installed globally doesn't work.
It seems that it's not supposed to work, unless NODE_PATH is set 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
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(), but they don't use it with whole packages.
Bottom line, globally installed modules probably shouldn't work on node, 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 suggests we can.
Supporting NODE_PATH would make cordova-fetch fully compatible with npm resolution algorithm AFAIK, and the test for it seems straightforward.
Added NODE_PATH support and tests.
This is the code that generates those GLOBAL_FOLDERS. It's straightforward to replicate this functionality in cordova-fetch, but the way it finds the node_prefix has changed because the node binary moved, and I don't know if it could in the future.
All of these options have drawbacks, and supporting GLOBAL_FOLDERS would be "mostly for historic reasons". @raphinesse, up to you whether to support them and which option has the best trade-offs for the cordova project.
As far as testing global modules, I only see two ways of testing it: