[code-infra] Update internal deps ranges to be non breaking

[oliviertassinari]

Replicate mui/base-ui#3405 (review)

[mui-bot]

Netlify deploy preview

https://deploy-preview-47454--material-ui.netlify.app/

Bundle size report

Bundle	Parsed size	Gzip size
@mui/material	0B(0.00%)	0B(0.00%)
@mui/lab	0B(0.00%)	0B(0.00%)
@mui/system	0B(0.00%)	0B(0.00%)
@mui/utils	0B(0.00%)	0B(0.00%)

Details of bundle changes

Generated by 🚫 dangerJS against e0ec9c7

[Janpot]

I wouldn't bother trying to control it this fine grained. If we want to minimize lock file updates causing breakage, then let's just pin every dev dependency. Renovate will update them weekly anyway, we don't need the lockfile update to bump their patch version.

How do you feel about we do

{
  "packageRules": [
    {
      "matchDepTypes": ["devDependencies"],
      "rangeStrategy": "pin"
    }
  ]
}

?

Keep in mind we grouped all (otherwise ungrouped) devdependencies as well in renovate, so one way or the other, there will be a PR with all of them updated and it will break CI anyway, just not on the lockfile update.

mui/mui-public#947

[oliviertassinari]

I wouldn't bother trying to control it this fine grained. If we want to minimize lock file updates causing breakage, then let's just pin every dev dependency.

The idea is that only a handful of dependencies don't follow semver: prettier, typescript (but is less often an issue), and our internal packages. They are the only ones who need a ~ range or pin?

pin every dev dependency

We would lose the benefit of the lock file cleaning with this (low priority security fixes, deduplicate, mass update of low risk dependencies), if we pin, no?

[Janpot]

We would lose the benefit of the lock file cleaning with this (low priority security fixes, deduplicate, mass update of low risk dependencies), if we pin, no?

No not at all, Currently the lockfile maintenance is doing double duty:

1. update all of our direct dependencies dev and prod, within their version range
2. update all transitive dependencies + dedupe

But 1. is already handled by regular renovatebot PRs, no need to do it as well in lockfile maintenance. And we do those more frequently than lock file maintenance anyway. We can keep lockfile maintenance for prod and transitive dependencies only.

[Janpot]

Closing as all dev dependencies will be pinned during the next renovate update cycle