BuildSWOptions

Interface @vite-pwa/workbox-build/build

Properties

Property	Type	Default	Description
additionalManifestEntries?	string | ManifestEntry[]		A list of entries to be precached, in addition to any entries that are generated as part of the build configuration.
additionalManifestEntriesGenerator?	() => AsyncGenerator<string | ManifestEntry, undefined, void>		Async generator that yields additional entries to be preached. runs after additionalManifestEntries and glob patterns, but before manifestTransforms If the same URL appears more than once (e.g. from both static array and generator), a warning will be logged and the duplicate will be skipped.
alias?	CustomAlias<B>
baseUrl?	string	'/'	The base url for the service worker web manifest entries build check.
bundlerLogLevel?	BundlerLogLevel	{ rolldown: 'warn', vite: 'warn' }	Granular control for underlying bundler logLevel. If you set logLevel to 'silent then the underline bundler logLevel will also be silent.
chunkNames?	"dash" | "dot"	'dash'	Specifies the separator style used for code splitting chunk names, assets, and entries. By default, Vite and Rolldown use the dash (-) separator: - chunkFileNames: [name]-[hash].js - assetFileNames: [name]-[hash].[ext] - entryFileNames: [name]-[hash].js (Note: The main Service Worker entry won't include the -[hash]) Switching to dot (.) makes it easier to programmatically extract the [hash] from the filename (e.g., in backend environments). Enabling this changes the naming patterns to: - chunkFileNames: [name].[hash].js - assetFileNames: [name].[hash].[ext] - entryFileNames: [name].[hash].js (Note: The main Service Worker entry won't include the .[hash])
customChunks?	CustomChunkCallback<B>		Custom chunks support. This allows splitting specific modules into separate files via a callback. When used in 'classic' mode, static imports will be automatically added to importScripts. Example: customChunks: (moduleId) => { if (moduleId.includes('node_modules/dexie')) { return 'dexie-lib'; } }
define?	Record<string, any>
dontCacheBustURLsMatching?	RegExp		Assets that match this will be assumed to be uniquely versioned via their URL, and exempted from the normal HTTP cache-busting that's done when populating the precache. While not required, it's recommended that if your existing build process already inserts a [hash] value into each filename, you provide a RegExp that will detect that, as it will reduce the bandwidth consumed when precaching.
enableSWKitLogs?	boolean		Enables workbox-swkit logs in the SW build (debug only): - replaces process.env.NODE_ENV with development inside workbox-swkit modules - exposes import.meta.env.ENABLE_SWKIT_LOGS at define It also enables workbox-swkit assertions and increases the bundle size.
envDir?	string | false
envPrefix?	string | string[]	VITE_
failOnDuplicateManifestEntries?	boolean	false	When true, throw an error listing all duplicate precache entry URLs.
globDirectory	string		The local directory you wish to match globPatterns against. The path is relative to the current directory.
globFollow?	boolean	true	Determines whether or not symlinks are followed when generating the precache manifest. For more information, see the definition of followSymbolicLinks in the glob documentation.
globIgnores?	string[]		A set of patterns matching files to always exclude when generating the precache manifest. For more information, see the definition of ignore in the glob documentation.
globPatterns?	string[]		Files matching any of these patterns will be included in the precache manifest. For more information, see the tinyglobby.
globStrict?	boolean	true	If true, an error reading a directory when generating a precache manifest will cause the build to fail. If false, the problematic directory will be skipped. For more information, see the definition of strict in the glob documentation.
injectionPoint?	string | false | null	"self.__WB_MANIFEST"	The string to find inside of the swSrc file. Once found, it will be replaced by the generated precache manifest. Set it to null or false to disable injection point. NOTE: calling injectManifest directly with injectionPoint set to null or false will fail.
inlineWorkboxRuntime?	boolean	false	Whether the runtime code for the Workbox library should be included in the top-level service worker, or split into a separate file that needs to be deployed alongside the service worker. Keeping the runtime separate means that users will not have to re-download the Workbox code each time your top-level service worker changes.
logLevel?	"info" | "silent"	'info'
manifest?	boolean	false	Enables the generation of the build manifest specifically for the Service Worker structure. The manifest naming follows the same architectural strategy as the Service Worker assets: - sw-manifest.json: When using a single Service Worker strategy or when workboxRuntimeCompatible is enabled. - sw-manifest-classic.json: When using a dual Service Worker build for the classic variant, or when workboxRuntimeCompatible is disabled. - sw-manifest-module.json: When using a dual Service Worker build for the module variant, or when workboxRuntimeCompatible is disabled. The generated files will be emitted to the .vite-pwa subfolder within the build output directory, matching Vite's standard manifest structure (containing only file, name, src, isEntry, and imports).
manifestTransforms?	ManifestTransform[]		One or more functions which will be applied sequentially against the generated manifest. If modifyURLPrefix or dontCacheBustURLsMatching are also specified, their corresponding transformations will be applied first.
maximumFileSizeToCacheInBytes?	number	2097152	This value can be used to determine the maximum size of files that will be precached. This prevents you from inadvertently precaching very large files that might have accidentally matched one of your patterns.
minify?	boolean		Should minify the output? - when specified it is preserved - true when sourcemap is not set to false or mode is set to production - otherwise false
mode?	string | null	"production"	If set to 'production', then an optimized service worker bundle that excludes debugging info will be produced. If not explicitly configured here, the process.env.NODE_ENV value will be used, and failing that, it will fall back to 'production'.
modifyURLPrefix?	object		An object mapping string prefixes to replacement string values. This can be used to, e.g., remove or add a path prefix from a manifest entry if your web hosting setup doesn't match your local filesystem setup. As an alternative with more flexibility, you can use the manifestTransforms option and provide a function that modifies the entries in the manifest using whatever logic you provide. Example usage: // Replace a '/dist/' prefix with '/', and also prepend // '/static' to every URL. modifyURLPrefix: { '/dist/': '/', '': '/static', }
swDest	string		The path and filename of the service worker file that will be created by the build process, relative to the current working directory. It must end in '.js'.
swSrc	string		The path and filename of the service worker file that will be read during the build process, relative to the current working directory.
swType?	T	classic	The type of the service worker.
target?	SWTarget	undefined	Service worker target build.
templatedURLs?	object		If a URL is rendered based on some server-side logic, its contents may depend on multiple files or on some other unique string value. The keys in this object are server-rendered URLs. If the values are an array of strings, they will be interpreted as glob patterns, and the contents of any files matching the patterns will be used to uniquely version the URL. If used with a single string, it will be interpreted as unique versioning information that you've generated for a given URL.
throwMaximumFileSizeToCacheInBytes?	boolean	true	Should maximumFileSizeToCacheInBytes exceeded throw an error?.
workboxRuntimeCompatible?	boolean	true	When using classic or module and splitting workbox runtime (inlineWorkboxRuntime set to false), this flag controls the name of the workbox-**.js chunk: - when true, workbox will generate the same old asset name workbox-<hash>.js using hex - when false, workbox will generate workbox-classic-<hash>.js or workbox-module-<hash>.js with modern Vite/Rolldown hash. When using classic-and-module (dual build), the build will use modern Vite/Rolldown hash regardless of the value of this flag.