fix(FR-2608): disable vite-plugin-pwa auto-manifest to preserve existing manifest.json#6877
Merged
graphite-app[bot] merged 1 commit intomainfrom Apr 30, 2026
Conversation
This was referenced Apr 22, 2026
Contributor
Author
This was referenced Apr 22, 2026
Merged
ef57101 to
78236e1
Compare
This was referenced Apr 27, 2026
Contributor
There was a problem hiding this comment.
Pull request overview
Disables vite-plugin-pwa’s auto-generated web manifest so the app continues to use the repo’s authoritative manifest.json (copied into build/web/ by the existing build pipeline), preventing conflicting PWA metadata in production builds.
Changes:
- Disable PWA plugin manifest generation/injection by setting
manifest: false. - Add inline documentation explaining why manifest generation must remain disabled.
78236e1 to
b789f9e
Compare
560dea4 to
7372c48
Compare
b789f9e to
3aa344c
Compare
7372c48 to
a68b158
Compare
3aa344c to
9750f0b
Compare
a68b158 to
ff24662
Compare
9750f0b to
4b6a570
Compare
ff24662 to
ed450f5
Compare
4b6a570 to
0bd7009
Compare
0bd7009 to
7253345
Compare
ed450f5 to
07e96d8
Compare
This was referenced Apr 30, 2026
Merge activity
|
…ing manifest.json (#6877) Resolves #6811(FR-2608) ## Summary Follow-up fix for FR-2608. Discovered while verifying the end-to-end production build in FR-2611. **Bug**: `vite-plugin-pwa` generates a `manifest.webmanifest` from `react/package.json` metadata and auto-injects `<link rel="manifest" href="/manifest.webmanifest">` into `index.html`. That competes with the repo's own `manifest.json` (already copied into `build/web/` by `copyresource`) — the auto one has: - wrong `name`: `"backend-ai-webui-react"` (react package name, not product) - wrong `theme_color`: `"#42b883"` (Vue green, pulled from some default) - **no icons** Whichever manifest the browser picks first can leave PWA installs with bogus metadata. **Fix**: one-line `manifest: false` option in the VitePWA plugin config. The plugin now only emits the service worker and leaves manifest handling to the existing `copyresource` pipeline. ## Verification - [x] `pnpm run build` produces only `build/web/manifest.json` (the real one); no `manifest.webmanifest` - [x] Built `index.html` references only `href="manifest.json"` ## Stack Sits above FR-2611; logically resolves an issue introduced in FR-2608 but couldn't be amended there without invasive rebase.
graphite-app Bot
pushed a commit
that referenced
this pull request
Apr 30, 2026
…ker (#6873) Resolves #6811(FR-2608) ## Summary Production build via Vite + `vite-plugin-pwa` service worker. This is the point where `vite build` produces a complete deployable `build/` directory. **Build output** (new layout): - `build/index.html` — built from project-root `index.html` via the `transformIndexHtml` hook - `build/assets/*.js` — hashed chunks (Vite default) - `build/sw.js` — service worker generated by `vite-plugin-pwa` (generateSW strategy) - `build/workbox-*.js` — workbox runtime **PWA plugin options** mirror the craco-era `workbox-webpack-plugin` GenerateSW call (`craco.config.cjs:390-400`): - `strategies: 'generateSW'` + `filename: 'sw.js'` - `injectRegister: false` — the existing registration script in `index.html:126-131` stays in charge (preserves legacy behaviour; we do not opt into `registerType: 'autoUpdate'`). - `skipWaiting: true`, `clientsClaim: true` - `maximumFileSizeToCacheInBytes: 5 MiB` - `globIgnores: ['**/*.map', '**/asset-manifest.json']` ## Test plan - [x] `pnpm run vite:build` completes without errors - [x] `build/sw.js` generated, precaches ~460 entries (~22 MB) - [x] SW registration path in `index.html` still resolves ## Follow-up (PR #6877) The plugin also emits `manifest.webmanifest` by default, which competes with the repo's own `manifest.json`. That's disabled in the follow-up `fix(FR-2608)` PR further up the stack. ## Stack Builds on FR-2610.
07e96d8 to
eaec713
Compare
7253345 to
7b13055
Compare
Base automatically changed from
04-21-feat_fr-2611_retire_craco_webpack_build_makefile_ci_all_on_vite_vitest
to
main
April 30, 2026 12:31
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.

Resolves #6811(FR-2608)
Summary
Follow-up fix for FR-2608. Discovered while verifying the end-to-end production build in FR-2611.
Bug:
vite-plugin-pwagenerates amanifest.webmanifestfromreact/package.jsonmetadata and auto-injects<link rel="manifest" href="/manifest.webmanifest">intoindex.html. That competes with the repo's ownmanifest.json(already copied intobuild/web/bycopyresource) — the auto one has:name:"backend-ai-webui-react"(react package name, not product)theme_color:"#42b883"(Vue green, pulled from some default)Whichever manifest the browser picks first can leave PWA installs with bogus metadata.
Fix: one-line
manifest: falseoption in the VitePWA plugin config. The plugin now only emits the service worker and leaves manifest handling to the existingcopyresourcepipeline.Verification
pnpm run buildproduces onlybuild/web/manifest.json(the real one); nomanifest.webmanifestindex.htmlreferences onlyhref="manifest.json"Stack
Sits above FR-2611; logically resolves an issue introduced in FR-2608 but couldn't be amended there without invasive rebase.