Context
src/vite/service-worker.js implements service-worker generation as a Vite plugin, with a .d.ts and a test file next to it. No repo in the org imports it. Verified by searching for both the package path and the exported plugin name; zero hits outside this repo.
Consumer apps that want a service worker ship a hand-written public/sw.js instead, each re-declaring the same cacheFirst / networkFirst strategies. That pattern is currently repeated across six apps.
Why it is not getting picked up
The shared Vite config lives in a different package, @max-health-inc/config/vite, and its createViteConfig does not compose this plugin. So an app adopting the shared build config gets no service worker, and the local sw.js stays where it is. There is no one-line adoption path, which is usually the whole reason a shared module goes unused.
Ask
Decide which package owns build plugins, then make adoption a single line.
- If it stays here: export it from the package entry point and document the wiring alongside
createViteConfig.
- If it moves: hand it to
@max-health-inc/config, which is where the rest of the build configuration lives.
Filed the other half as Max-Health-Inc/config#4. Worth resolving together rather than in either repo alone, since the split between the two packages is the actual cause.
Context
src/vite/service-worker.jsimplements service-worker generation as a Vite plugin, with a.d.tsand a test file next to it. No repo in the org imports it. Verified by searching for both the package path and the exported plugin name; zero hits outside this repo.Consumer apps that want a service worker ship a hand-written
public/sw.jsinstead, each re-declaring the samecacheFirst/networkFirststrategies. That pattern is currently repeated across six apps.Why it is not getting picked up
The shared Vite config lives in a different package,
@max-health-inc/config/vite, and itscreateViteConfigdoes not compose this plugin. So an app adopting the shared build config gets no service worker, and the localsw.jsstays where it is. There is no one-line adoption path, which is usually the whole reason a shared module goes unused.Ask
Decide which package owns build plugins, then make adoption a single line.
createViteConfig.@max-health-inc/config, which is where the rest of the build configuration lives.Filed the other half as Max-Health-Inc/config#4. Worth resolving together rather than in either repo alone, since the split between the two packages is the actual cause.