Consider using DllPlugin
See original GitHub issuehttp://engineering.invisionapp.com/post/optimizing-webpack/ https://robertknight.github.io/posts/webpack-dll-plugins/
I don’t quite understand how to integrate it, and community help would be most welcome. It would be ideal if we could make both dev and prod builds faster.
The idea is that we’d only use it for react
and react-dom
.
Issue Analytics
- State:
- Created 7 years ago
- Comments:20 (14 by maintainers)
Top Results From Across the Web
Improve your webpack build with the DLL plugin
This tutorial shows you how to improve build times when working with webpack as a dependency for build tools using the DLL plugin....
Read more >webpack common chunks plugin vs webpack dll plugin
So much, that you could consider using DllPlugin for your dev environment (advantage: short compile time), while using CommonsChunkPlugin ...
Read more >webpack-build-dll-plugin - npm package - Snyk
Simplifies run build DllReferencePlugin & DllPlugin for your webpack project For more information about how to use this package see README.
Read more >Optimizing Webpack build performance | by Juan Pablo Rivillas
If images are not clear, the build without DllPlugin took 10,5 seconds and the build with DllPlugin took 6,4 seconds. If you consider...
Read more >strip-dll-manifest-webpack-plugin - npm
A Webpack plugin to strip useless modules in manifest.json generated by DllPlugin. Latest version: 0.1.0, last published: 2 years ago.
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 Free
Top 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
@gaearon I implemented this in my own (large) project and in create-react-app.
On my own project it took our rebuild times from ~4000ms to ~1000ms.
However in the CRA which basically just has React in the DLL the difference is alot smaller.
Stats
Added complexity
Creating DLL package list The list of node modules to for the DLL can either be automatically generated from the package.json (ala react-boilerplate) or manually added to an array. Automatically going through the package.json makes it easier but I found some packages (react-toolbox) can break the dll build (due to importing of sass files). Manually the user knows what is going in the DLL but has to remember to add files to the array when they add new node_modules (but they know what packages make up the dll). Any missed files just go into the regular bundle.
Weird webpack stuff DLL’s aren’t used by many project. When you eject and see it, it might be confusing (although my implementation is much simpler than react-boilerplate). It also needs to be run on any update to the node_modules (I believe it can be ran as
postinstall
)Reliability React-boilerplate is the only large project I know of using DLLs. It should be getting a lot of user testing now, but as of this moment its largely untested in real world apps.
Worth adding?
I don’t have much of an answer if it’s worth adding. The ‘feeling’ between the two rather minimal as is. However if CRA is used for something containin 10+ node_modules, the difference might be much larger.
Large CRA example
Example with larger CRA (imports: redux, react-redux, lodash, react-bootstrap, immutable, redux-saga, reselect, babel-polyfill, react-router. No other changes)
I am so excited about this!
After seeing @ro-savage’s Stats, I had to try it for myself. I was so impressed by it. I realized that I really-really want it to be there the next time I build something with CRA.
So, I decided to make a PR.
I wanted to Add the DllPlugin to CRA without introducing new files, I liked the cleanness of the source code and didn’t wanted to mess it with all the DllPlugin’s Boilerplate.
The main challenges was that:
Those constraints led to many iterations over this PR, until one night I realized that the most declarative and minimalist form to add DLL Support to CRA is by creating a new webpack plugin that encapsulates all that logic.
You just add it to webpack.config.dev.js as usual, tell it which modules you want to move to the DLL and that’s it.
Now, when you run webpack for the first time, It creates a separate compiler that builds the DLLs, stores them in a cache directory, and load them into the memory so webpack’s dev server can consume them later.
Then, it connects with the HTMLPlugin to injects the DLL bundles before the main one.
The next time you run webpack, it will read the DLLs from the cache, to skip unnecessary build, unless node_modules changed or if the plugin’s settings are different from the last build.
The more I worked on the Plugin, the more I realized that there’s nothing specific to CRA about it, and that this plugin can serve many other webpacks configurations, so I extracted the code into a separate repository and called it AutoDllPlugin.
This PR is now included only 2 changes: It adds a plugin to webpack.config.dev.js and another dependency to react-script’s package.json
The way to use it is by adding the dll entries in the packge.json, like so:
Only ./polyfills are included by default. I left ‘react’ and ‘react-dom’ intentionally, in case someone we’ll want to use CRA to work on one of them.
That’s it. It was a really incredible journey for me to make this plugin. I hope you’ll like it.