📖 new docs for recent updates

posts/main/guides/cli.mdx

@@ -65,7 +65,7 @@ remix-pwa sw --dest app/pwa/service-worker.ts # writes the service worker to `./
   If changing the destination for service workers, ensure to update the Vite plugin accordingly.
 </Info>
 
-## `update` 🆕
+## `update`
 
 *Alias: `upgrade`*
 
@@ -75,6 +75,7 @@ It takes in the following arguments:
 
 - `--packages` (`-p`): The packages you want to update, without the `@remix-pwa/` prefix. Defaults to all packages
 - `--root` (`-r`): The root of the Remix project. Defaults to `process.cwd()` (current working directory)
+- `--dev` (`-D`) 🆕: Update the packages to their latest dev versions. Defaults to `false`
 
 ```sh
 # updates all packages
@@ -83,6 +84,10 @@ npx remix-pwa update
 # updates just @remix-pwa/dev & @remix-pwa/sw
 npx remix-pwa update -p dev sw
 
+# updates all packages to the latest `dev` versions
+# (package@dev)
+npx remix-pwa update -D
+
 # updates all packages in the app/remix-app folder
 npx remix-pwa update -r ./apps/remix-app
 

posts/main/guides/env.mdx

@@ -13,4 +13,23 @@ You can also utilise `process.env.NODE_ENV` (in that order) within your service
 
 ## Custom Variables
 
-Currently, Remix PWA doesn't offer up a way to access/set custom environment variables within the service worker. This should hopefully be rolling out in a future patch (*higher demand means it rolls out quicker 😉*).
+Remix PWA now allows for injecting custom variables via the `buildVariables` option in the Vite plugin configuration. This allows you to inject variables that are accessible within the service worker.
+
+```ts
+// vite.config.ts
+export default defineConfig({
+  plugins: [
+    remixPWA({
+      buildVariables: {
+        'process.env.PUBLIC_KEY': 'my-public-key',
+        // can also be in another format
+        'myVery_PuBlick3y': 'my-public-key-2',
+      },
+    }),
+  ],
+});
+
+// entry.worker.ts
+console.log(process.env.PUBLIC_KEY); // my-public-key
+console.log(process.env.myVery_PuBlick3y); // my-public-key-2
+```

posts/main/utils/cache-api.mdx

@@ -37,7 +37,7 @@ Why did we say main strategies? Because you can also create your own custom stra
 The methods provided are:
 
 - `async openCache(): Promise<Cache>`: This method is used to open the cache that the strategy will use (which is provided during instantiation). It returns a promise that resolves to the cache (of `this` object).
-- `ensureRequest(request: Request | string | URL): Request`: This utility method is used to ensure that the request is a `Request` object. If it's a string or URL, it converts it to a `Request` object.
+- `ensureRequest(request: RequestInfo | URL): Request`: This utility method is used to ensure that the request is a `Request` object. If it's a string or URL, it converts it to a `Request` object.
 - `async cleanupCache(): Promise<void>`: This method is used to clean up the cache based on pre-defined parameters. It returns a promise that resolves when the cleanup is done.
 - `addTimestampHeader(response: Response): Response`: This utility method is used to add a timestamp header to a response. This is used by the `cleanupCache` method to determine the age of an item in the cache.
 - `handleRequest(request: Request): Promise<Response>`: The abstract method of `BaseStrategy`. This method is used to handle the request and return a response. It must be implemented by all strategies.
@@ -77,6 +77,7 @@ where:
   - `maxAgeSeconds`: The maximum age (in seconds) of an item in the cache. If an item is older than this, it will be removed during cleanup.
   - `maxEntries`: The maximum number of items in the cache. If the cache has more items than this, the oldest items will be removed during cleanup.
   - `ignoreRoutes`: An array of routes to ignore when caching. This is useful for unique routes that should not be cached and handled specially instead.
+  - `matchOptions` 🆕: An object that defines the match options for the cache. This can be used to specify how the cache should match requests.
 
 ### `CacheFirst`
 

posts/main/utils/vite-config.mdx

@@ -40,6 +40,28 @@ By default, the service worker is registered automatically.
 
 The `workerBuildDirectory` option of type: `string` is used to set the directory where the service worker is built to. **Default**: `public` in dev and `build/client` in production. Note the lack of leading or trailing slashes.
 
+### `buildVariables` 🆕
+
+The `buildVariables` option of type: `Record<string, string>` is used to inject build variables into the service worker. Do note that these variables are visible in the browser, so don't inject private keys!
+
+```ts
+// vite.config.ts
+export default defineConfig({
+  plugins: [
+    remixPWA({
+      buildVariables: {
+        'process.env.API_URL': 'https://api.example.com',
+        'myVar': 'myValue',
+      },
+    }),
+  ],
+});
+
+// entry.worker.ts
+console.log(process.env.API_URL); // https://api.example.com
+console.log(myVar); // myValue
+```
+
 ### `scope`
 
 The scope of the service worker within your application, this is used by the internal registration injection to set the scope of the service worker. **Default**: `/`.
@@ -82,6 +104,6 @@ The `workerSourceMap` option of type: `boolean` is used to set wether to generat
 
 ### `workerEntryPoint`
 
-This is used to set the entry point of the service worker (also known as runtime in Remix PWA). <b>Default</b>: `@remix-pwa/worker-runtime`.
+This is used to set the entry point of the service worker (also known as runtime in Remix PWA). **Default**: `@remix-pwa/worker-runtime`.
 
 To create your own runtime, check out the runtime guide.