ServiceWorkerOptions
Options for serviceWorker.
Defined in: engine/src/pwa/vite.ts:41
Properties
| Property | Type | Description | Defined in |
|---|---|---|---|
fileName? | string | The worker's file name at the root of the build, which is the app's base (default sw.js). It cannot live under assets/: a worker's scope is its own folder at most, unless the server sends Service-Worker-Allowed, which GitHub Pages cannot. | engine/src/pwa/vite.ts:72 |
include? | string[] | More files to precache, relative to the base, e.g. ["manifest.webmanifest", "favicon.svg"] from the public directory. Files that fail to fetch are skipped, never fail the install. | engine/src/pwa/vite.ts:64 |
name | string | The app's cache name prefix, e.g. "examples". Every app on the origin shares one Cache Storage (GitHub Pages serves them all from one host), so it must be unique among them: the worker deletes only caches named <name>-<build id> of older builds. Letters, digits and dashes. | engine/src/pwa/vite.ts:48 |
precache? | false | "all" | "entry" | What to fetch on install, so it is there offline before it is first opened: - "all" (default): every file of the build (each page, its chunks and CSS, workers, imported assets; not source maps). For a multi-page app that is every page, so a second visit works offline even on pages not yet opened. Costs the whole build's size once per deploy (the examples are about a megabyte). - "entry": only the root index.html, its entry chunk, the chunks it imports statically and their CSS. Other pages, lazy chunks and workers are cached when first used. - false: nothing but the root index.html; everything is cached when first used. | engine/src/pwa/vite.ts:59 |
runtime? | RuntimeCacheRule[] | Fetched data to cache at run time; the first matching rule wins. See RuntimeCacheRule. | engine/src/pwa/vite.ts:66 |
RuntimeCacheRule
Fetched data to cache at run time, e.g. the viewer's samples or an example's .vox files: files from the public directory, which are not part of the bundle and so are not precached. Matching responses go to a cache of their own that survives deploys (their URLs carry no hash, so a new build does...
CacheStrategy
How a runtime rule answers a request.