@types grouping with sibling packages

[pvinis]

What Renovate type are you using?
Regular one on Github.

Describe the bug

Packages like react and types associated with them like @types/react don't get updated in the same PR.

By default, DefinitelyTyped is keeping the first 2 numbers of the versions in sync, so react@1.2.x will have @types/react@1.2.y.

When renovate tried to upgrade to react@2.0.x, it should also go to @types/react@2.0.y.

Did you see anything helpful in debug logs?

Not really.

To Reproduce

https://github.com/pvinis/bug-renovate-types-sync

Here I have react and @types/react, react-native and @types/react-native. All of them are not in their latest version.

I got the PR for pinning, merged it.

After that I got pvinis/bug-renovate-types-sync#3 and pvinis/bug-renovate-types-sync#4 to upgrade the @types deps, both are not pointing in versions that in theory are incompatible with the package version of react and react-native.

Soon I will get PRs for upgrading react and react-native.

As I see it, there are 2 things here that should go differently.

• @types/react should be upgraded in the same PR as react. (same for react-native)
• @types/react should not offer to upgrade to something that's later than the react version we have. (that one is not as important)

Additional context

[pvinis]

I just noticed in a private repo that react-redux and @types/react-redux were grouped.

Could it be that react and react-native are somehow not matched correctly?

[rarkins]

Synchronising @types versions is actually a duplicate of one of the oldest issues we have opened: #519

It's actually a pretty challenging problem, although maybe one day we'll work out an elegant way to solve it.

The second part is why these types aren't being grouped together with their parent package. In this case, it's because the react packages are being specifically grouped: https://github.com/renovatebot/presets/blob/72658888f765b52b8b314a7894a3655dccd85548/packages/renovate-config-monorepo/package.json#L344-L349

We ideally would have an automated way to group these types but right now it's another hard problem!

[pvinis]

Thanks for the info. I am familiar with the renovate-config-monorepo part, but I didn't know this basically "breaks" the normal way.

So there is nothing I/we can do to help for this? Do we just need to wait for the renovate team to work it out?

[rarkins]

Locally you could define your own package rule like this:

{
  "packageNames": ["@types/react", "@types/reactive-native"],
  "groupName": "react monorepo"
}

And this could put the types into the same group as the main packages. But it won't do anything about the "sync" problem with versions.

[DanielMSchmidt]

If someone runs into the same problem and want a starting point for a scripted solution: I have this gist for updating the renovate.json with package rules: https://gist.github.com/DanielMSchmidt/a1a5e3f753a52e13f53efeac42579461

[falkenhawk]

Locally you could define your own package rule like this:

{
  "packageNames": ["@types/react", "@types/reactive-native"],
  "groupName": "react monorepo"
}

And this could put the types into the same group as the main packages. But it won't do anything about the "sync" problem with versions.

@rarkins wouldn't it be just enough for now if renovate treats @types the same way as in #1368 but that it also works for packages listed in the default monorepo package groups? 🤔 It looks like the monorepo grouping takes precedence and disables the standard @types treatment.

[rarkins]

No, it wouldn't work.

#1368 makes it so that @types/foo goes into a branch like renovate/foo-1.x instead of renovate/types-foo-1.x. This works if you don't have grouping.

Meanwhile monorepo grouping is based on source URL and @types/ packages come from a different source. And the branch name is like renovate/react-monorepo.