Skip to content
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

~50% unused bytes in app.js with Chrome Dev Tools Coverage #1633

Closed
ghost opened this issue Apr 6, 2017 · 3 comments
Closed

~50% unused bytes in app.js with Chrome Dev Tools Coverage #1633

ghost opened this issue Apr 6, 2017 · 3 comments

Comments

@ghost
Copy link

ghost commented Apr 6, 2017

Chrome Dev Tools code coverage utility

screen shot 2017-04-06 at 02 23 23

In production, of course.

Apart from the CSS (first time using styled-jsx and will need to improve shared styles design or use something like styletron) — have I misunderstood the automatic code splitting feature?

To give some context, I use a HOC to wrap each page, and I'm passing both methods and props that don't necessarily get used by each page. Additionally: I may have been careless here and there with some imports; I use re-base which currently imports all of Firebase (not necessary in my use case).

Am I possibly mixing webpack's automatic code splitting with static analysis and tree shaking a là rollup? If so,

  1. Should Next perform tree-shaking and dead code elimination?

  2. If not, do you have any suggestions regarding how to approach and solve this problem? Chrome Dev Tools coverage results cannot be exported trivially just yet and therefore I'm not sure how to identify unused code paths and imports with the minified output.

  3. Would using something like webpack-rollup-loader be possible and make sense?

  4. Can any of this lead to improvements to the already awesome way Next works?

Thanks!

@arunoda
Copy link
Contributor

arunoda commented Apr 6, 2017

I assume this is because how webpack handles tree-shaking.
It needs ES2015 modules. I hope React doesn't provide that and that's why this is.
But I would like to experiment here. Any ideas/improvements welcome.

@ghost
Copy link
Author

ghost commented Apr 6, 2017

Possibly related to webpack#2867?

@sedubois
Copy link
Contributor

sedubois commented Apr 6, 2017

Linked from that thread, here is apparently a utility to test if tree shaking happens properly in Webpack:
https://github.com/halt-hammerzeit/es6-tree-shaking-test

@lock lock bot locked as resolved and limited conversation to collaborators May 11, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants