[core] Set renovate to automerge devDependencies

[JCQuintas]

Currently only set for devDependencies we can increase the automerge coverage to regular deps and the package lock refresh once we are confident in it.

• Allowed Renovate to bypass Protect base branches (bypass "Admin" role) only in Pull Requests

[mui-bot]

Deploy preview: https://deploy-preview-13463--material-ui-x.netlify.app/

Generated by 🚫 dangerJS against e3867b9

[LukasTy]

Checked pending PRs.
This would cause the following to be merged:

• Bump @testing-library/react to ^16.0.0 - autoclosed #13429 <- I wouldn't want it, as in theory, we should probably even ditch the explicit dependency as we are now transitively getting it from @mui/internal-test-utils.
• Bump sinon to ^18.0.0 #13346 <- same story as above. Given the recent changes, it seems that we should be able to remove this package.
• Bump React #12295 <- would be auto-merged after fixing lock issues, even though, we don't want it.

If I understand the behavior of this change correctly, I would be wary of introducing it. 🙈

[JCQuintas]

For the testing libs, does it even matter? We would have two different ones, we can just remove them when we want.

For react, why we can't merge it if the pipelines are passing? The website also seems correctly rendered.

It is also possible to ignore react changes though

[LukasTy]

For the testing libs, does it even matter? We would have two different ones, we can just remove them when we want.

But without seeing those PRs, we might not ever even notice these discrepancies and possible improvements/simplifications that could be done. 🤔

For react, why we can't merge it if the pipelines are passing? The website also seems correctly rendered.

It's WIP: #12295 (comment)

[JCQuintas]

If chai/RTL are going to be used directly I would expect them to be in the package.json. Else, we can just remove them. DevDeps do get out of sync a lot and that is normal, I would rather use a tool for that, than waiting for the upgrade tool to open a PR and rely on someone verifying that the dep is still used.

I saw it was blocked by the main repo PR, but why? Would it break development? Would it break for our users?

[LukasTy]

I saw it was blocked by the main repo PR, but why? Would it break development? Would it break for our users?

If the CI is green, then probably just out of optimization reasons—so as not to introduce duplicate dependency major versions if they are not necessary.

I would still like to have the option for the following flow: a dependency PR is red, we start looking into it, but we want extra confirmation before allowing it to be merged even if the CI is green (the React bump PR case).
What could be the flow then?
Converting the PR to draft?
Adding an on hold label to prevent auto-merge? 🤔

I would love input from @mui/code-infra on this question. 🙈

[JCQuintas]

I generally don't like arbitrary exceptions on CI. Green is good, red is bad. If green is bad we have to fix so it doesn't happen again.

React is a peer dependency and a dev dependency. The only people affected would be us. I don't see what would be the issue in merging all those PRs you mentioned.

I would expect renovate to completely hands off all PRs where someone has added a commit (though i didnt find docs on the automerge page), so if the pipeline goes red and we add a commit, it should work as you expect.

[michaldudak]

What could be the flow then?
Converting the PR to draft?
Adding an on hold label to prevent auto-merge? 🤔

I would love input from @mui/code-infra on this question. 🙈

You could add a negative review (request changes) to the PR. Renovate won't merge such PRs automatically.