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
Check dependency versions before running any commands #5107
a.k.a., "put an end to self-trolling."
This is a very common experience when working on teams of size larger than one:
Proposal: before any operations involving npm, including e.g.
The minimum viable version of this for Ember is fixing #5083 plus making this work for shrinkwrap.
That still requires interaction with the npm command line interface. What if there was runtime support (optional) for the package.json and npm-shrinkwrap.json files? That is, perhaps I could
@derekprior I think that's a good idea in general---factoring out the check into a separate package would be a good way to divide the work inside npm, and make it reusable. But in the end you should be starting your app with
This will become an even better safety net once
referenced this issue
Apr 21, 2014
There are a bunch of subtleties here.
You want to verify that
All agree about what the versions of dependencies are. This can introduce complexities with ranges & git dependencies.
If you use ranges & git dependencies (without shas) at best we can do is verify a git / npm range in package.json matches node_modules.
For verifying npm-shrinkwrap & node_modules we should be able to check resolved agrees recursively.
For branches & tags in package.json we can either
The problem is fundamentally the notion that
the hard part to do as an external module is hooking into
Also with the default
referenced this issue
Jul 13, 2015
Reading the installed tree from disk isn’t a cheap operation; particularly with the large trees generated by
Re: @Raynos’s points about shrinkwrap behavior when checking out branches,
The team agrees that in general it would be useful to help users not push repos or publish packages with package trees in inconsistent states. As a few of you have alluded, this is something that could be built out as a separate utility, and added to projects via package lifecycle scripts or repo hooks (which also goes a long way towards remedying the performance concerns above – if you’re consciously opting into this functionality, you’re much less likely to be displeased with the resulting slowdown). I think that’s the best way to lay down a cowpath that the CLI could later pave by incorporating this functionality into
We further agree that when using the CLI to manage dependencies, it should never be possible to put
Thanks to all for the discussion, as well as for your time and patience!