Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
Add instructions to use source-map-explorer #1641
The wildcard in this command fails on Windows 10 with error "no such file or directory". I wasn't able to find an alternative other than changing it to
May want to include a disclaimer in there.
referenced this pull request
Mar 17, 2017
We would love a brief writeup to explain how to analyze the produced output. Tell the users what to be on the lookout for, explain that huge (squares) modules are what's taking up space, that they may want to see if they offer a es6 build that may reduce size, etc.
May I suggest @gr33nfury something like:
Analyzing and reducing the bundle size
To add source-map-explorer in your CRA project:
npm install source-map-explorer --save-dev
Then you can generate a report by typing:
npm run build ./node_modules/.bin/source-map-explorer build/static/js/main.*
It should open a html report in your browser similar to the following:
In this interactive report, each module is represented by a rectangle. The bigger the rectangle, the bigger the module in bytes. All the sizes listed here are uncompressed.
If you feel that some of your modules is too large, you can:
If you feel that a third party module is too large compared to the functionalities it provides, you may:
You also may notice the bundle can contain 2 different versions of the same module (like React for instance), it usually comes from the peer dependencies being incompatible.
I've been using it more lately and I don't know how I ever lived without
Maybe there's an API we can leverage as a secondary package to recommend / suggest to the user what to change / defer loading.
I'm a little tied up with work right now so I can't lay out a more detailed plan, but in a few days I'll have some free time.
@baptistemanson - I reckon you should go ahead and add
I wouldn't think this requires e2e or any other tests. But one of the maintainers might correct me. They might want an e2e just to make sure the command works across platform etc.
I think making automated recommendations to the user is pretty hard. Just letting people see whats causing issues is a huge help.
For me personally, its allowed me to fine heaps of large bundles being imported by packages I use and make PRs to remove them. Often it's something silly like all of lodash being imported just for one function. Or just realise when I should roll my own because the dependency is much too large.
@sr-h see this twitter thread for context
I do not believe this is a path we are going to take, but there will be discussions soon once