-
-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Emotion stylis prefixer fork is not public #3314
Comments
I'd accept PR exporting this. Just a note - in the next major version this fork will get quite small: https://github.com/emotion-js/emotion/blob/49108c893d50fe95dca1f4b13390dd1ede80c57e/packages/cache/src/prefixer.ts |
@Andarist nice!
Yes! We saw that. We want to get rid of unnecessary prefixes (related Material UI issue) and we were wondering if there's a tentative date for Emotion v12 or if the changes made to reduce the prefixed size could be backported to v11 in an opt-in way. |
Unfortunately, not yet. The problem is that the new React 19 APIs we'd like to use are over 10x slower on the client when it comes to the styles insertion. I'm in contact with the React team and there is a rough plan to figure out next steps in the coming weeks.
I'm open to backwards-compatible ideas. |
@Andarist is there a place to follow these discussions around React 19 APIs? We (MUI) are very interested in the topic. |
The problem
Emotion uses a default set of stylis plugins (only
prefixer
as of today) increateCache
. When someone customizes thestylisPlugins
option increateCache
, Emotion stops using the default stylis plugins and uses the user provided plugins instead. In Material UI, we customize thestylisPlugins
when configuring RTL like this (see docs):Since Emotion forked the stylis prefixer and maintains its own internal version, it's not possible to get the same prefixes when you're using the default cache vs when you're customizing the
stylisPlugins
(unless you maintain a local copy of the stylis prefixer).Proposed solution
Emotion is likely going to keep maintaining the stylis prefixer internal fork, exposing the
defaultStylisPlugins
could make sense to be able to achieve the same prefixes when someone customizesstylisPlugins
. For example, the code to setup RTL in Material UI could look like this:The text was updated successfully, but these errors were encountered: