How we got twitter.com to build with webpack.
Feeling the burn of migrating to webpack! At least they ditched npm for Yarn.
Read about i18n and Globalize!
twitter.com is a big website and a pretty old website–much of the code, especially in the bundling and deployment pipeline, is several years old. For loading and bundling JS files, we used two libraries: loadrunner for loading JS modules, and loadbuilder for bundling those modules into efficient bundles for frontend delivery.
Challenges
Our biggest challenge was doing two things at once. We couldn’t migrate to webpack in a single commit: the amount of changes required was too large and would have been too high risk. Instead, we had to ensure all of our application code worked in both the webpack build and the loadrunner build, to avoid blocking continual feature development on the site.
A close second problem was the size of the codebase–our production build consists of about 1300 JS modules, that generate about 20 JS files for deployment. We couldn’t pause development on the site while working on this migration, so any changes would have to work for all of our modules, and continue to pass our unit, integration, and end-to-end test suites.
A few specific problems, with solutions/hacks/workarounds, are described below.
