Skip to content

Tracking: replace Create React App with Vite #1578

Description

@xantorres

This is the tracking issue for replacing react-scripts and react-app-rewired with Vite in ui/, opened at maintainer request as the follow-up to #1567. It records scope and constraints only. The work itself lands as three child pull requests, each of which keeps dev buildable on its own.

Why. react-scripts is unmaintained and officially sunset. It sits behind most of the ui/ audit findings and blocks dependency upgrades, and staying on it is the riskier default. #1567 has the full write-up, the regression matrix results, and the measurements.

The series. Each child has its own issue and its own PR against dev. Order matters: 2 depends on 1, 3 depends on 2.

  • Step 1, Go HTML and asset contract: Vite migration (1/3): Go HTML and asset contract #1579. GetStyle() reads the script and stylesheet tags out of the built index.html from the parsed document (golang.org/x/net/html) instead of a regex pinned to one bundler's tag shape; cssPath becomes a list; ui/template/header.html ranges over the stylesheets; a Go test asserts the parse against the embedded build. Lands while Create React App still builds. Classic defer scripts stay until step 2.
  • Step 2, Vite cutover, atomic: Vite migration (2/3): replace Create React App with Vite #1580. Vite config, package.json and lockfile, index.html moved to the ui root, Create React App and rewired removed, import.meta.env, router import.meta.glob, require() to ESM, header.html entry script as type="module", plus the two first-paint fixes (plugin i18n init order, bootstrap-icons font path).
  • Step 3, check-ui and small follow-ups: Vite migration (3/3): check-ui guards and small follow-ups #1581. The make check-ui guard scripts, the locale probe, and the small CSS and route fixes. Not required to boot.

Constraints every step preserves.

Server-side contracts. The build directory stays ui/build, which ui/static.go embeds. Emitted assets stay under static/, which internal/router/ui.go serves as a route, grouped as static/js, static/css, static/media. ui/scripts/env.js remains the single source of truth for configuration shared with the server, the REACT_APP_ prefix included, and its public_url value drives the bundler's base so a non-root ui.public_url keeps every asset reference prefixed. Production sourcemaps stay on. GetStyle() must not depend on tag attribute order, attribute set, or quoting, so the next bundler change cannot silently empty the server-rendered pages again.

Module scripts. After step 2 the entry script served by header.html is an ES module (type="module" crossorigin), matching what the bundler emits in index.html; a module served through a classic script tag fails on its first import. A module script fetches in CORS mode, so any CDN origin serving these files must send the matching CORS headers or the app will not boot even though every request returns 200. Default same-origin deployments are unaffected. The note for CDN users lives only in the CDN plugin READMEs, per the placement decided on #1567: apache/answer-plugins#326. When the version that ships the Vite frontend is cut, its release notes carry a short call-out linking to that README.

i18n init order. i18next attaches its resource-store methods inside init(), while the builtin plugins register their translations during module evaluation. Which runs first is decided by the bundler's chunking, so registration must be correct in either order (immediate when an initialised instance exists, otherwise deferred to the initialized handler). Under the previous toolchain the working order was incidental.

Not in scope for the series. No CI job for the frontend is added; the project runs none today and a build on every push is a cost maintainers should choose to take on. One constraint carries forward for whoever wires it: a bare go test ./... reports ok while asserting nothing about the built asset paths, because the Go test skips when no frontend build is embedded, so a CI job needs to build the frontend first. Migrating the 30 Sass @import uses to @use is a separate change; the pinned sass version stays below the release that starts deprecating them.

Prior art. #1567 is the same change as one PR, reviewed against dev, with the regression matrix (subdirectory deploy, OAuth callbacks, absolute CDN public_url) run and reported in its thread. It stays open only until this issue and the first child PR exist, then closes with a pointer here; its branch stays as reference and the child commits cite their source SHAs. Its measurements, same machine and same Node and package manager versions, clean tree and clean install on both sides, five runs per timing metric:

Metric Before After
Cold production build 19.87s 4.77s
Warm build 8.75s 4.87s
Dev server time to ready 7104ms 359ms
HMR latency 421ms 139ms
Bundle JS, raw / gzip 3477.60KB / 1198.75KB 3010.49KB / 1035.57KB
Bundle total, raw / gzip 4290.39KB / 1652.24KB 3763.97KB / 1474.34KB
Direct dependencies 75 65
Packages installed 1578 689
Audit findings, critical/high/moderate/low 4/78/63/13 1/50/38/6

The caveats attached to those numbers are in #1567 (cold and warm builds equal within noise because the new build has no persistent cache to warm and now type-checks on every build; chunk boundaries differ so bundle rows compare totals; HMR measured once at an earlier head on both toolchains).

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions