f1ames
commented
3 years ago Fourth proposal:
Ability to define update strategy
I thought it could be useful to have two update workflows - one respecting semver (so probably using npm update) and the other one with npm-check going with latest deps. This could be configurable via config and default to semver compatible updates.
We could then run "minor" updates once a week and "major" ones once a month. This should give us the best of both words - quick and frequent minor updates (which shouldn't break anything) and major updates from time to time to keep deps up-to-date but without spending too much time too often on them.
jacekbogdanski
Dumluregn
sculpt0r
We have already discussed it a little when working on the initial script. The difference between native
npm updateandnpm-checkis that the former one respects semver while the later one goes all the way to the latest deps version.Generally, we would like to have a possibility to update to latest versions, but OTOH we have some cases when some packages cannot be yet updated which makes update-deps scripts useless for some time periods. The ideal approach would be possibility to update deps to latest major by default unless it is not specified otherwise.
The cases we already encountered:
Error: The Angular Compiler requires TypeScript >=4.0.0 and <4.1.0 but 4.1.2 was found instead.).And here we have few ideas:
Leave as is
We can just live with this for a while and see if it gets more problematic with time or is acceptable and try to come up with reasonable workflow for breaking deps updates.
npm updateKeeping deps versions as intended is what
npm updatedoes and whatpackage.jsonis for. So we could usenpm updatebut loosen semver (to allow major updates) for all/most of the deps.The downside is, anyone starting project/package development running
npm imay end up with some latest major package (which is still not updated on remote and not tested) which breaks the project. This may be quite confusing.npm-checkwith additional configWe could do this and create additional config to mark which deps shouldn't be bumped but it really duplicates the purpose of
package.json.To sum up, from my perspective it will be good to test the current approach for some time still and see how it works. It's still more efficient than single dependabot deps update PRs. Also automatic major deps updates somehow forces us to update deps regularly without staying on fixed version which gets outdated with time.