mui
[core] Set renovate to automerge devDependencies
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
Renovateto bypass Protect base branches (bypass "Admin" role) only in Pull Requests
Deploy preview: https://deploy-preview-13463--material-ui-x.netlify.app/
Generated by :no_entry_sign: dangerJS against de6231102341df8d7ba86320257f2acfee1da2de
Checked pending PRs. This would cause the following to be merged:
- https://github.com/mui/mui-x/pull/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. - https://github.com/mui/mui-x/pull/13346 <- same story as above. Given the recent changes, it seems that we should be able to remove this package.
- https://github.com/mui/mui-x/pull/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. 🙈
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
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: https://github.com/mui/mui-x/pull/12295#issuecomment-2150701924
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?
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. 🙈
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.
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.
Sorry, I forgot about this PR. 🙈 I think we can try experimenting with automerging dev deps excluding major bumps. 👍
😆
I would love to have the option to automerge only when the diff has equal amounts of additions and removals. 🤔 😆
Don't think it is currently possible. Though having different versions should mostly be ok in dev deps.