Configure Renovate #4
Welcome to Renovate! This is an onboarding PR to help you understand and configure settings before regular Pull Requests begin.
Detected Package Files
Important: Now that this branch is edited, Renovate can't rebase it from the base branch any more. If you make changes to the base branch that could impact this onboarding PR, please merge them manually.
What to Expect
With your current configuration, Renovate will create 5 Pull Requests:
chore(deps): update dependency semantic-release to v17 [security]
chore(deps): update dependency commitizen to v2.10.1
chore(deps): update dependency commitizen to v4
fix(deps): update dependency conventional-commit-types to v3
fix(deps): update dependency longest to v2
The text was updated successfully, but these errors were encountered:
@LinusU it’s a risk vs convenience trade-off. The less you pin, the higher the chance of difficult-to-pinpoint dependency breaks, even if you’re using lockfiles. It’s also dependent on how important it is to not have your master branch “broken”. For large projects that might mean man days of inconvenience per break while everyone waits.
For example I helped migrate a repository in the angular org to pinning last week and we found it had two in-range dependency updates that broke the build. They weren’t aware of it as the lockfile was holding versions back by a month or so.
Have a read through https://renovateapp.com/docs/deep-dives/dependency-pinning and let me know if you think any points should be expanded.
Even if you still prefer the risks of dependency ranges, it’s no problem though as Renovate is designed to flexible/configurable. Some people pin everything and get PRs around the clock for every dependency update while others use ranges and want a single (combined) PR once a month.
@rarkins I have now read the docs for it, and I more understand your position. I can't say that I agree with the conclusions though.
I will only address the scenario with a lock file now since both latest npm and yarn creates them by default, and I don't see why anyone wouldn't use them.
I don't think that this is true actually. Consider the following package and lock files:
Now, the latest version of
As you can see,
This is only true for your immediate dependencies, and thus pinning will only protect you against breakage in a, in many cases, small percentage of your packages. If you for example have installed express and pinned it, you will only protect yourself against a bad express release, it will not help with the 30 dependencies that express has.
Because of this, I personally think that pinning dependencies just creates a false sense of security, and that using a lock file is superior in every way.
Node.js is used in a lot of more places than beefy servers in the cloud. e.g. It's used in embedded development and many of us are developing on the road over cellular connections, less downloads is nice. Also, many packages intended for Node.js only works great in the browser when used with browserify, webpack, etc.
It also comes with the problem that passing objects from different versions of the same library often doesn't work (e.g.
This is only a problem when not using lock files, instead of recommending pinning versions, I personally think it's much better to recommend lock files. Especially since pinning only protects one layer down.
Sorry for this long dump of my thoughts
No sorry necessary at all!
I'm a little embarrassed though as I based that article on earlier
I think I will publish an updated revision to that post ASAP and address some of your points in that (both which I agree with or do not). FYI it's actually sourced from the renovate repo so you can file a bug report or PR at any time!
Don't worry about that, after all Renovate is flexible so all its users can be opinionated. It's intended to operate just as well, however you configure it.
BTW in this case I think you will want to add the preset
@LinusU FYI I have updated the doc, with a reference to this conversation included: https://renovateapp.com/docs/deep-dives/dependency-pinning
I actually intended to write something more planned and reasoned, but ran out of time this week and wanted to push an update to at least take out the inaccurate parts.
I'm thinking instead of updating it with more "opinionated" arguments, my next step might be a more dry document which describes the various approaches (semver with no lockfile, semver with lockfile, pinned with no lockfile, pinned with lockfile) and how that would work in various scenarios (e.g. minor/patch updates, major updates, breakages, etc). i.e. facts not opinions - something a bit concrete to then base a discussion of opinions on
@sashafirsov but it really doesn't? since you are only pinning your top-level dependencies, anything else could be upgraded at any time.
What would really solve your use case seems like a lock file?
I just run into this thread, trying to understand if/why we need dependency version pinning when a lockfile is present after a technical debate in a project. My general conclusion after reading through the documentation is that pinning can't harm, and it could also potentially make version ambiguities which break the build more obvious, so easier to locate and fix. Is that accurate?