mui
Bump stylis to ^4.3.4
This PR contains the following updates:
| Package | Change | Age | Adoption | Passing | Confidence |
|---|---|---|---|---|---|
| stylis | ^4.3.2 -> ^4.3.4 |
Release Notes
Configuration
📅 Schedule: Branch creation - "on sunday before 6:00am" in timezone UTC, Automerge - At any time (no schedule defined).
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about these updates again.
- [ ] If you want to rebase/retry this PR, check this box
This PR was generated by Mend Renovate. View the repository job log.
![renovate[bot] avatar](https://avatars.githubusercontent.com/in/2740?v=4 "Published by a pub.dev verified publisher"){kind=small}
Deploy preview: https://deploy-preview-14323--material-ui-x.netlify.app/
Generated by :no_entry_sign: dangerJS against 0432c1efa030f9317b362ee983bc639544558253
This pull request has conflicts, please resolve those before we can evaluate the pull request.
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
This pull request has conflicts, please resolve those before we can evaluate the pull request.
@JCQuintas on such core dependencies, especially ones that are coming from Core I tend to wait until they bump it first. 🙈 https://github.com/mui/material-ui/pull/37791
🤔 I think I mistook this one for another. I was trying to figure out which ones come from core by seeing if they are duplicated in the package lock, which this one is, but it skipped me for some reason 😅
On another note, should we handle this differently? Like, I know we probably use this directly in our scripts, but we could define them as a required peerDep and set it to an exact version in the core/package.json, which probably would mean we always update to the correct one, and we wouldn't need to check 🤔
On another note, should we handle this differently? Like, I know we probably use this directly in our scripts, but we could define them as a required peerDep and set it to an exact version in the core/package.json, which probably would mean we always update to the correct one, and we wouldn't need to check 🤔
Once everything in common for docs to function is moved to @mui/docs we would get a more clear separation of what is a peer dependency and what is coming transitively from @mui/docs.
But this case is slightly different, because we use stylis explicitly in a few of our demos. 🙈
I think there is no problem here, but I would have still waited for other dependencies to catch up and Core to merge it first, given that this dependency is kind of integral part of the docs.