Config-help: Best practice for libs

[kbrandwijk]

I have a question about how to best configure my dependencies for libs. Up until now, we have pinned both devDependencies and dependencies. This is causing quite a PR and version avalanche, because many packages in our chain dependencies to each other.

Now I have seen your base config for libs, which only pins devDepencies, and not dependencies, but I am a bit unsure of the consequences of that. Could you shed some light on this?

[rarkins]

Have you seen https://renovateapp.com/docs/deep-dives/dependency-pinning ?

[rarkins]

For libraries that are consumed by other packages, I recommend ranges for dependencies and exact versions for devDependencies. And never publish new versions for devDependency updates. Hence there shouldn’t be anything to really cause an avalanche.

[kbrandwijk]

Yeah, I've read that. I've also read there that not pinning dependencies leads to faulty master branches (the part about a new version being released that breaks your build but you're not noticing it.
So to me, using ranges for dependencies doesn't sound that great.

Practical example. There was a bugfix in graphql-import, causing a PR on graphql-cli-prepare: https://github.com/supergraphql/graphql-cli-prepare/pull/37. Now if I merge this, this will cause a new release of graphql-cli-prepare, in turn causing a fix(deps) PR on graphql-cli, releasing a new version of it that includes that fix.

Now, if I didn't pin dependencies, then the fix on grapqhl-import wouldn't have caused a PR on graphql-cli-prepare, so there wouldn't be a new version of graphql-cli. So people installing the cli today would get a different behavior than the people who already installed it yesterday. With no way of knowing that there's a new version. Yet, reinstalling the same version would give them a different output...

Which one is better...

[rarkins]

If you wish to keep pinning but reduce updates then scheduling (eg weekly) and grouping (if any deps are tightly related) will both reduce the total number of PRs you receive. You can exclude internal or important packages from the scheduling to update them right away.

[kbrandwijk]

@rarkins Thank you for your feedback. I think grouping is the best solution in this case, even with pinned dependencies. This is the concrete issue: https://github.com/graphql-cli/graphql-cli/issues/123. Do you agree that grouping will result in only one fix PR, with both library updates in it?
And with automerge, is there a way to put in a delay, so both package updates will in fact end up in that one PR? Something a bit faster than daily?

[rarkins]

That’s a tough one. You want it done as soon as possible.. but it’s undesirable to have two PRs?

You can group them but perhaps the import dep gets updated and merged before the other one appears so the grouping doesn’t really change anything.

If you can have a CI rule to somehow fail the PR then that would prevent automerge but I’m not sure that’s easier.

So if it were possible one day to say “group these two packages and only merge when both are present” then would that work?

[kbrandwijk]

perhaps the import dep gets updated and merged before the other one appears

That's exactly the issue. If it might be possible to even delay by an hour, that should usually be enough.

"Only merge when both are present". That wouldn't work, because this behavior only occurs when an upstream dependency is updated. If I just add a feature to one of the two, the other one wouldn't update, so in your solution the PR would never be merged.

[rarkins]

Ok so a configurable delay until automerge is done? No automerge until at least x minutes, for example? And would it be x minutes after npmjs publication or after Renovate branch creation?

[rarkins]

We could also delay branch creation or PR creation instead, for that matter.

[kbrandwijk]

I think it could work just like the existing 'daily' schedule, but then specifying 'x hours'.
Renovate also needs some time 'upstream' to create and merge the PR's there, I've seen that take quite a while too.

[rarkins]

@kbrandwijk FYI, I added some real-time hooks to the Renovate App today so that you should see PRs for dependencies within minutes of the upstream package being published. It doesn't solve the problem you described above but will probably look a little different to you as a user, e.g. you'll see the direct dependency PR right away.

[kbrandwijk]

Yes, it has become a lot faster, I noticed!