New: Replace Webpack with Vite
Current status: merged, evaluating
Please share your feedback in a feedback issue.
New Pattern Proposal: Use Vite instead of Webpack for the whole Gitlab project
Vite is a modern frontend tooling which can act as a direct Webpack replacement. Webpack is used by Gitlab at the moment to build and develop all of its frontend.
Advantages of new pattern
You can read about all of the Vite's advantages here. In short: it would allow us to have a much faster HMR and cold app start.
Preliminary production compile times comparison
bundle exec vite build -f |
yarn run webpack-prod |
|
---|---|---|
Run 1 | 191.01 real 254.40 user 22.52 sys | 209.31 real 285.36 user 14.50 sys |
Run 2 | 185.88 real 248.55 user 22.37 sys | 218.70 real 291.41 user 15.40 sys |
Run 3 | 185.74 real 245.94 user 23.35 sys | 209.15 real 279.04 user 13.75 sys |
The runs were done against an exact codebase on an M1 Pro 32GB. Some of the code had to be commented out to make it compile in both bundlers. Vite had an additional env defined: NODE_OPTIONS="--max_old_space_size=10240"
, which gave 10GB to the process to operate. Vite was compiling against a es2015
target with maxParallelFileReads
set to 10 (half of the default).
Disadvantages of new pattern
- Having to build compatibility layer with Gitlab's project structure and dependencies
- Some things might not work in Vite
- A lot of the parts of the Gitlab would have to be tested
What is the impact on our existing codebase?
The impact will be substantial in terms of the scope of the change. Current Gitlab CI is heavily reliant on Webpack's capabilities and all of it would have to be adapted to Vite eventually.
Implementation plan (JavaScript assets)
Stage 1: Preparation work
-
Upgrade Vue to 2.7
Stage 2: Development experimentation
-
Add ViteRuby gem -
Use Vite helper tags where necessary instead of Webpack ones -
Backport Webpack Rails glue code to support ViteRuby -
Add ViteRails-specific code to templates and ruby code -
Create entrypoints for Vite -
Hide all of Vite's functionality under a feature flag -
Disable Vite completely in tests and CI -
Configure CSP to properly handle Vite's HMR -
Use ?worker
resource query to indicate worker imports -
Make sure the CI passes without any issues -
Write tests for Vite helpers -
Collect bugs and UX feedback -
Decide on Vite's future in GitLab
Stage 3: Default to Vite in GDK
-
Resolve currently identified integration issues -
Integrate with GDK: gitlab-org/gitlab-development-kit!3448 (merged) -
Make it work with feature testing: gitlab-org/gitlab!135714 (merged) -
Use Vite for other assets in HAML templates -
Make vite build
compile without any errors -
Add Vite build to CI -
Write documentation on how to use Vite in GitLab -
Set Vite to be used instead of Webpack by default during development -
Collect more feedback
Stage 4: Production-ready build
-
Match to Webpack production output as close as possible -
Migrate Webpack chunking strategy to Vite
-
-
Enable Vite for tests and CI -
Manually test production build in all the parts of GitLab (outsourced to the whole frontend department)
Stage 5: Full switch to Vite
-
Use Vite instead of Webpack for production assets -
Remove feature flag -
Remove Webpack
Implementation plan (CSS Assets)
Not planned as a part of this effort but can be done once we do a full switch to Vite for JavaScript assets.
Reference implementation
Reference implementation does the first stage and most of the second stage as an example of the final result. It's fully functional for the Javascript compilation during development at the moment.
Alternatives
- Upgrade to Webpack 5 and rely on its lazy compilation mechanism