Suggestion - npm run should search ancestor directories, like require('foo')

[danielearwicker]

What's the feature?

I'm using npm/node as my JS "build system" within a broader multi-language project. I have little islands of JS (sanity!) at various places in a big source tree.

Near the root of this tree I can create a node_modules folder where I put shared code in small packages. This instantly makes these packages available to all the nested JS projects (no need to install them or otherwise copy them locally). So if I have:

root/node_modules/useful-thing

I can then edit:

root/blah/something/niche/index.js

to say require("useful-thing"), and it works. Or at least, I find webpack resolves useful-thing and includes it in niche's bundle.

But at the terminal in niche if I say:

npm run build

Then in niche's package.json I've defined the build script to run some tool exposed by useful-thing, this is not found.

The environment for package.json includes the local node_modules/*/bin folders, and the global ones, but not those on the chain of ancestor directories, making it a bit less convenient than the require behaviour.

What problem is the feature intended to solve?

Sharing packages within a combined tree of projects, none of them published on npm registry.

Is the absence of this feature blocking you or your team? If so, how?

No, it just means a bunch of fooling around with very long brittle paths in config files.

Is this feature similar to an existing feature in another tool?

Yes, it's analogous to the behaviour of require, searching up the ancestor directory chain.

Is this a feature you're prepared to implement, with support from the npm CLI team?

Yes!

[MegaArman]

This would be awesome! Please do it npm team!

[npm-robot]

We're closing this issue as it has gone seven days without activity and without being labeled. If we haven't even labeled in issue in seven days then we're unlikely to ever read it.

If you are still experiencing the issue that led to you opening this or this is a feature request you're still interested in then we encourage you to open a new issue. If this was a support issue, you may be better served by joining package.communty and asking your question there.

For more information about our new issue aging policies and why we've instituted them please see our blog post.