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

1. Having to build compatibility layer with Gitlab's project structure and dependencies
2. Some things might not work in Vite
3. 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

1. Upgrade Vue to 2.7

Stage 2: Development experimentation

1. Add ViteRuby gem
2. Use Vite helper tags where necessary instead of Webpack ones
3. Backport Webpack Rails glue code to support ViteRuby
4. Add ViteRails-specific code to templates and ruby code
5. Create entrypoints for Vite
6. Hide all of Vite's functionality under a feature flag
7. Disable Vite completely in tests and CI
8. Configure CSP to properly handle Vite's HMR
9. Use ?worker resource query to indicate worker imports
10. Make sure the CI passes without any issues
11. Write tests for Vite helpers
12. Collect bugs and UX feedback
13. Decide on Vite's future in GitLab

Stage 3: Default to Vite in GDK

1. Resolve currently identified integration issues
2. Integrate with GDK: gitlab-org/gitlab-development-kit!3448 (merged)
3. Make it work with feature testing: gitlab-org/gitlab!135714 (merged)
4. Use Vite for other assets in HAML templates
5. Make vite build compile without any errors
6. Add Vite build to CI
7. Write documentation on how to use Vite in GitLab
8. Set Vite to be used instead of Webpack by default during development
9. Collect more feedback

Stage 4: Production-ready build

1. Match to Webpack production output as close as possible
   1. Migrate Webpack chunking strategy to Vite
2. Enable Vite for tests and CI
3. Manually test production build in all the parts of GitLab (outsourced to the whole frontend department)

Stage 5: Full switch to Vite

1. Use Vite instead of Webpack for production assets
2. Remove feature flag
3. 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

1. Upgrade to Webpack 5 and rely on its lazy compilation mechanism