Tracking: replace Create React App with Vite

これは単独で完結する変更ではなく、追跡用の Issue です。まず子 Issue #1579、#1580、#1581 から始め、#1567 にある既存実装の回帰マトリクスを確認してください。関連するエントリポイントは ui/、ui/static.go、internal/router/ui.go、ui/template/header.html です。3 つの依存する子変更が取り込まれ、記載されている build、asset、server、deployment の契約が維持されていれば完了です。

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: #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: #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: #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:

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).