You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
So far it's been assumed/tested that existing package.json dependencies use pinned versions, such as 1.6.0 and not such as ~1.6. So for now, this is an undocumented prerequisite of the tool. Ideally we could handle initialising a repo with non-pinned versions and pinning them.
Given that we prefer not to keep the tool stateless, we can't easily tell if this is the "first" time we've run, i.e. to do a special once-only cleanup. We could use a hack like looking for any past pull requests created by our account, but I prefer to avoid that.
Some possible options:
Consider any repo with unpinned dependencies to be "uninitialised" and therefore initialise it if we haven't already
Problem: we can't stop developers adding new unpinned dependencies at any time in future
Treat any unpinned dependency similar to how we treat an out-of-date pinned dependency
Find the highest pinned major and minor updates, and raise a PR for each we find
I think the second option is better, but perhaps there's a problem if someone runs the tool the first time on a repo with completely unpinned dependencies - you could end up with dozens or even hundreds of pull requests.
Perhaps then we provide a special option for the tool where people can manually initialise a repository. e.g. run it with a --initialize parameter and in that case it adopts different behaviour:
It creates only one branch/PR, instead of one PR per-dependency
It only upgrades dependencies according to their semver, e.g. if it's a tilde range then it only looks for patch upgrades and not minor or major
In theory this shouldn't make any different to the project, because it would simply be pinning the same dependency versions that npm would be resolving anyway.
Activity
rarkins commentedon Dec 18, 2016
Given that we prefer not to keep the tool stateless, we can't easily tell if this is the "first" time we've run, i.e. to do a special once-only cleanup. We could use a hack like looking for any past pull requests created by our account, but I prefer to avoid that.
Some possible options:
I think the second option is better, but perhaps there's a problem if someone runs the tool the first time on a repo with completely unpinned dependencies - you could end up with dozens or even hundreds of pull requests.
Perhaps then we provide a special option for the tool where people can manually initialise a repository. e.g. run it with a
--initialize
parameter and in that case it adopts different behaviour:In theory this shouldn't make any different to the project, because it would simply be pinning the same dependency versions that npm would be resolving anyway.
rarkins commentedon Dec 18, 2016
I wonder if a tool to pin all dependencies already exists, but I can't find it. It's not the same as
npm shrinkwrap
.Support ranges