@emotion/react@11.0.0 is 10% bigger than @emotion/core@10.1.1
See original GitHub issueHi friends,
I raise this with the upmost thanks and gratefulness for this project. I’ve noticed that @emotion/react@11.0.0
is +10%
bigger than @emotion/core@10.1.1
@emotion/core@10.1.1
:6.6Kb
https://bundlephobia.com/result?p=@emotion/core@10.1.1@emotion/react@11.0.0
:7.3Kb
+10%
Some thoughts:
- In the release notes it mentioned that theming was brought into the main package. Does it need to be in the main package?
- hoist-non-react-statics is adding
1.2kb
to the size and it is a new addition. Is it needed?
I appreciate the sometimes projects need to get bigger in order to move forward well. But I wanted to raise this just in case there was something that could be done.
Also, i’m not sure what these badges are referring to in the readme
:
Issue Analytics
- State:
- Created 3 years ago
- Comments:5 (2 by maintainers)
Top Results From Across the Web
Emotion 11
Emotion 11 is a slight evolution over the Emotion 10. It focuses mainly on the developer experience, TS types improvements, switches internals to...
Read more >react-collapse using Emotion CSS prop example
Environmentcreate-react-app. Files. public. src. Accordion.js. index.js. styles.scss. package.json. Dependencies. @emotion/core. 10.0.15.
Read more >Changelog - Datetime picker - Atlaskit by Atlassian
a91fbaf0552 - Updates @emotion/core to @emotion/react ; v10 to v11. ... 7566be18f20 - [ux] Time picker no longer loses focus to the document...
Read more >@emotion/native | Yarn - Package Manager
Style and render React Native components using emotion ... or if you use yarn ... Emotion 10 is a big change that we're...
Read more >the `@emotion/core` package has been renamed to ... - You.com
Apparently in Emotion 11, @emotion/core was renamed to @emotion/react, ... I've just migrated from v10 to v11 and I've fully reinstalled all emotion...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
@alexreardon thank you for keeping an eye for things like this - it has actually helped me to improve the tree-shakeability of
@emotion/react
. The PR is not merged in yet but you can check it out here: https://github.com/emotion-js/emotion/pull/2101I’ve prepared a demo that is showcasing how this change will improve the story around this. Notice how in this commit
hoist-non-react-statics
has completely vanished from webpack and Rollup bundles: https://github.com/Andarist/emotion-11-tree-shaking-test/commit/be06ae978615f949ddd0d18e00afbd250e2897f8 . This is the commit that applies the patch from the PR I’ve mentioned here.That being said - I don’t believe that bundlephobia is an ideal tool for measuring things like this. It’s probably one of the best though and it would be very hard to create a better one. The problem is that it all depends on the usage and what can be dropped from a particular package. As I’ve showcased here it’s totally possible to cut down the bytes that will be put into our consumers’ bundle if they don’t end up using
withTheme
export. Splitting a package (and thus decreasing the overall DX) just to satisfy metrics like bundlephobia’s ones feels like a counter-productive thing to do. It’s a good thing to care about bundlesizes etc and we certainly take this into account - in fact, we use several build techniques to cut down the final size (providing special browser build, NODE_ENV checks, using PURE annotations and more). I don’t think though it’s worth pursuing a vanity metric here if it doesn’t reflect the actual usage.I understand though that people just won’t realize this subtlety, we have no means to communicate our intentions to bundlephobia and people will stop analyzing after seeing a single, simple, final score of the overall bundlesize. This is very unfortunate but I don’t know how the situation can be improved here.
If we simply subtract the
react-is
+hoist-non-react-statics
% involvement (based on bundlephobia’s composition values) then we’ll end up with 6.52kb (7.3kb * 0.894) which is an improvement over v10’s 6.6kb and this already includes theme-related helpers in v11. I don’t think this math is super accurate because % involvement is based on non-minified sizes but it shows that there is a high possibility of those bundlesizes being very close to each other.Those bagdes were pointing to the old package names - thanks for noticing. I’ve prepared a fixing PR for this here: https://github.com/emotion-js/emotion/pull/2099
For some reason
@emotion/react@11.1.0
has not fixed the issue with those unwanted deps being bundled in (even though I have been testing it) but after a quick investigation I’ve managed to fix this and@emotion/react@11.1.1
works as expected in this regard. You can checkout the updated demo here: https://github.com/Andarist/emotion-11-tree-shaking-test/commit/507baa4df207a287f82de5197844bb15e66739c4