📖 fixed links across the docs to match new convention

posts/dev/getting-started/changelog.mdx

@@ -29,7 +29,7 @@ This has been moved to the `@remix-pwa/manifest` package.
 ### Support for Remix SPA mode and Single Fetch
 
 Remix PWA now supports both Remix SPA mode and Single Fetch. This drastically alters the behaviour of Remix PWA and how it handles the service worker.
-Check out the [SPA](/docs/next/spa) and [Single Fetch](/docs/next/single-fetch) docs for more information.
+Check out the [SPA](/docs/dev/spa) and [Single Fetch](/docs/dev/single-fetch) docs for more information.
 
 Some of the less obvious changes include faster build times and smaller service worker sizes
 
@@ -109,7 +109,7 @@ This has been replaced by the `installPWAGlobals` hook.
 
 ### Removal of `ManifestLink` component
 
-This has been moved to the [`@remix-pwa/manifest`](/docs/next/changelog#remix-pwa-manifest) package.
+This has been moved to the [`@remix-pwa/manifest`](/docs/dev/changelog#remix-pwa-manifest) package.
 
 ### Reoval of message sending utilities
 

posts/dev/getting-started/quick-start.mdx

@@ -45,7 +45,7 @@ export default defineConfig({
 })
 ```
 
-The options for the `remixPWA` plugin can be found [here](/docs/next/vite-config).
+The options for the `remixPWA` plugin can be found [here](/docs/dev/vite-config).
 
 To create a service worker, you can use the `remix-pwa` CLI:
 

posts/dev/getting-started/v5.mdx

@@ -8,7 +8,7 @@ order: 3
 Remix PWA v5 is a major milestone built upon v4. It is built to work with Remix latest features, as well as prepare for React Router v7.
 
 Upgrading to v5 doesn't require a lot of work. The main thing you would need to do is to upgrade your `@remix-pwa/*` packages to the latest `v5.x.x` version. There are also a few breaking changes that you would need to be aware of.
-Check out the [changelog](/docs/next/changelog) for more details.
+Check out the [changelog](/docs/dev/changelog) for more details.
 
 ## Upgrading from v4 to v5
 
@@ -63,4 +63,4 @@ Check out the rest of the docs for even more details.
 
 ## Upgrading from older versions to v5
 
-Check out the [this doc](/docs/main/v4) for more details on migrating from v3 and below.
+Check out the [this doc](/docs/latest/v4) for more details on migrating from v3 and below.

posts/dev/utils/redirect.mdx

@@ -5,4 +5,4 @@ alternateTitle: redirect
 toc: false
 ---
 
-> Like [`json`](/docs/main/json) and the [`defer`](/docs/main/defer) utility, this function is also a re-export of React Router [redirect](https://reactrouter.com/en/main/fetch/redirect) function.
+> Like [`json`](/docs/latest/json) and the [`defer`](/docs/latest/defer) utility, this function is also a re-export of React Router [redirect](https://reactrouter.com/en/main/fetch/redirect) function.

posts/dev/utils/vite-config.mdx

@@ -31,7 +31,7 @@ export default defineConfig({
 
 The `injectSWRegister` option of type: `boolean` is used to set wether to automatically register the service worker or not via plugin injection.
 
-By default, the service worker is registered automatically. Alternatively, you can set this to `false` and manually register the service worker in your application via the [`PWAScripts`](/docs/next/pwa-scripts) component.
+By default, the service worker is registered automatically. Alternatively, you can set this to `false` and manually register the service worker in your application via the [`PWAScripts`](/docs/dev/pwa-scripts) component.
 
 ### `workerBuildDirectory`
 

posts/latest/apis/default-fetch-handler.mdx

@@ -12,7 +12,7 @@ In Remix PWA, the fetch event is handled implicitly (behind-the-scenes) by runti
 <Info>
   The `defaultFetchHandler` is basically a fallback handler that is used when no appropriate handler is found in a route.
 
-  Route handlers in this case, or as we like to call them: route worker apis, are simply [`workerAction`](/docs/main/worker-action) and [`workerLoader`](/docs/main/worker-loader) exports in your routes that handle non-`GET` and `GET` requests respectively.
+  Route handlers in this case, or as we like to call them: route worker apis, are simply [`workerAction`](/docs/latest/worker-action) and [`workerLoader`](/docs/latest/worker-loader) exports in your routes that handle non-`GET` and `GET` requests respectively.
 </Info>
 
 ## Usage
@@ -49,7 +49,7 @@ server that maps the same path as the request.
 </Warn>
 
 <Details title="What happens if I don't provide a default fetch handler?">
-  Well, in that case, it depends on the [runtime](/docs/main/runtimes). If you are using `@remix-pwa/worker-runtime`, the underlying behaviour is to just utilise a simple
+  Well, in that case, it depends on the [runtime](/docs/latest/runtimes). If you are using `@remix-pwa/worker-runtime`, the underlying behaviour is to just utilise a simple
   `fetch` call to the server. As you can see, this behaviour is heavily dependent on the runtime, so you can customise it to suit your needs.
 </Details>
 
@@ -75,7 +75,7 @@ The `context` object is a global context object being passed around your service
   sharing of data and state between them.
 </Info>
 
-Creation of the `context` object is handled via the [`getLoadContext`](/docs/main/get-load-context) function in your entry worker file.
+Creation of the `context` object is handled via the [`getLoadContext`](/docs/latest/get-load-context) function in your entry worker file.
 
 ### `params`
 

posts/latest/apis/worker-action.mdx

@@ -83,7 +83,7 @@ In this example, we adapted the code from Remix [action page](https://remix.run/
 
 `workerAction` receives an object with the following properties:
 
-- `context` - The worker global context object that's created via [`getLoadContext`](/docs/main/get-load-context) in your entry worker.
+- `context` - The worker global context object that's created via [`getLoadContext`](/docs/latest/get-load-context) in your entry worker.
 - `params` - The route `params` properties. Matches dynamic routes, check out Remix docs for more info.
 - `request` - The request object.
 

posts/latest/guides/enhanced-cache.mdx

@@ -8,7 +8,7 @@ alternateTitle: EnhancedCache
 
 ## Features
 
-`EnhancedCache` is a class that wraps itself around a [strategy](/docs/main/cache-api#strategies). Let's go ahead and create an enhanced cache instance.
+`EnhancedCache` is a class that wraps itself around a [strategy](/docs/latest/cache-api#strategies). Let's go ahead and create an enhanced cache instance.
 
 ```ts {{filename:'entry.worker.ts'}}
 import { EnhancedCache } from '@remix-pwa/sw';
@@ -57,7 +57,7 @@ It takes in two parameters:
 2. `options`: An object that contains the following properties:
    - `version`: A string that represents the version of the cache. This allows for versioning of the cache.
    - `strategy`: A string that represents the strategy to be used. The available strategies are `CacheFirst`, `CacheOnly`, `NetworkFirst`, and `StaleWhileRevalidate` (the available strategies from `sw` package).
-   - `strategyOptions`: An object that contains the options for the strategy. The options are different for each strategy. Check out the strategy [page](/docs/main/cache-api#strategies) for more info.
+   - `strategyOptions`: An object that contains the options for the strategy. The options are different for each strategy. Check out the strategy [page](/docs/latest/cache-api#strategies) for more info.
 
 > Currently, `EnhancedCache` only supports the strategies provided by the `sw` package. Extending it to custom `BaseStrategy` sub-classes is underway.
 

posts/latest/guides/messaging.mdx

@@ -148,7 +148,7 @@ It also has a `handleMessage` method (like all message handlers) that can be use
 
 The `SkipWaitHandler` is a subclass of `MessageHandler` that listens for the `SKIP_WAITING` event. It is used to skip the waiting phase of the service worker and activate the new service worker immediately.
 
-A very simple handler, it doesn't take in any options and simply handles skipping workers. Should be paired with [`sendSkipWaitingMessage`](/docs/main/misc#send-skip-waiting-message) for maximum effect.
+A very simple handler, it doesn't take in any options and simply handles skipping workers. Should be paired with [`sendSkipWaitingMessage`](/docs/latest/misc#send-skip-waiting-message) for maximum effect.
 
 ## Recommended Tips
 

posts/latest/guides/offline.mdx

@@ -141,7 +141,7 @@ We create the base three caches: the pages (HTML), assets (CSS & JS) and finally
 We also created a version constant. This is to ensure cache cleanup, and to enforce it as we see fit (for example, when we have a major update that requires just cleaning our caches).
 
 <Info>
-  Read more about the `EnhancedCache` class [here](/docs/main/enhanced-cache)
+  Read more about the `EnhancedCache` class [here](/docs/latest/enhanced-cache)
 </Info>
 
 ### Fetching
@@ -183,7 +183,7 @@ We set some groundwork here. First of all, we check if the requests coming throu
 
 You might have noticed that even though `defaultFetchHandler` takes in a `request` object as a property of its lone parameter, we still went ahead to use `event.request` from the context. This is because the `request` object available via `context` is the raw request, without any modification, whereas the one available directly is a cleaned up version - the same as the one passed to loaders and actions. If we wanted to have access to the request as it was made, we would use the one from the `context`.
 
-Another thing is that we utilise the `__workerManifest` object to access our assets. The reason for that is simply that Remix PWA plugin under the hood gathers all assets after scouring the entire Remix App, and then via `@remix-pwa/worker-runtime`, inject it into the service worker scope. You can see a breakdown on the worker manifest [here](/docs/main/runtimes#implementing-the-runtime).
+Another thing is that we utilise the `__workerManifest` object to access our assets. The reason for that is simply that Remix PWA plugin under the hood gathers all assets after scouring the entire Remix App, and then via `@remix-pwa/worker-runtime`, inject it into the service worker scope. You can see a breakdown on the worker manifest [here](/docs/latest/runtimes#implementing-the-runtime).
 
 <Info>
   Fun fact, if you disable network right now and reload, you get an unstyled page, not an error. That's because some assets are missing (stylesheets, some logos located at resource routes, etc.) but the basics (documents, loader data, etc.) are still served.
@@ -222,7 +222,7 @@ self.addEventListener('message', (event: ExtendableMessageEvent) => {
 
 </Snippet>
 
-The first thing we did was to simply add the `useSWEffect` hook to our root. We don't need to tamper with it as the defaults are setup perfectly for our needs. The second thing we did was to create a `NavigationHandler` instance and then listen for messages. You can check out exactly what it does and more [here](/docs/main/messaging#navigation-handler). In short, it fetches the document on each client navigation and caches that document if it isn't found.
+The first thing we did was to simply add the `useSWEffect` hook to our root. We don't need to tamper with it as the defaults are setup perfectly for our needs. The second thing we did was to create a `NavigationHandler` instance and then listen for messages. You can check out exactly what it does and more [here](/docs/latest/messaging#navigation-handler). In short, it fetches the document on each client navigation and caches that document if it isn't found.
 
 ## Going Off The Grid
 
@@ -272,7 +272,7 @@ We can finally go ahead and save our service worker. We are done! If we go ahead
 
 ### UI Feedback
 
-If you were looking at the logs in preview mode (`npm run start`), you would notice that there were no logs. If you were on a mobile device, it would even be impossible to check! This is because [`Logger`](/docs/main/logger) only outputs in development mode. And we also can't be telling our users to keep an eye out for any new/interesting log coming in. We need to actually let them know when something goes wrong, an update comes in, connection goes off or on, etc. That's what we would be attempting in this section.
+If you were looking at the logs in preview mode (`npm run start`), you would notice that there were no logs. If you were on a mobile device, it would even be impossible to check! This is because [`Logger`](/docs/latest/logger) only outputs in development mode. And we also can't be telling our users to keep an eye out for any new/interesting log coming in. We need to actually let them know when something goes wrong, an update comes in, connection goes off or on, etc. That's what we would be attempting in this section.
 
 The amount of UI feedback possible is plenty. Gives your users better interaction with your app as well as reduce the chance of sudden "mishaps", we would be limiting ours to just two:
 
@@ -377,7 +377,7 @@ A very simple prompt that serves our purpose within the root so it is available
 - `isUpdateAvailable`: A boolean that tells us if there is a new service worker waiting to take over.
 - `newWorker`: The new service worker that is waiting to take over or `null`, if `isUpdateAvailable` is `false`.
 
-If `isUpdateAvailable` is true, we display a prompt that tells the user an update is available. When the user clicks the 'Reload' button, we send a message to the service worker to skip waiting and then reload the page. Note, the [`sendSkipWaitingMessage`](/docs/main/misc#send-skip-waiting-message) function took in the new service worker as its lone argument instead of the current registration, that's because it is the new worker that is doing the skipping.
+If `isUpdateAvailable` is true, we display a prompt that tells the user an update is available. When the user clicks the 'Reload' button, we send a message to the service worker to skip waiting and then reload the page. Note, the [`sendSkipWaitingMessage`](/docs/latest/misc#send-skip-waiting-message) function took in the new service worker as its lone argument instead of the current registration, that's because it is the new worker that is doing the skipping.
 
 <Info>
   In case you are wondering why we are going through the hassle of sending a message instead of skipping directly, it's because there's no way to directly skip waiting from the client thread. The service worker has to do it itself. So we send a message to the service worker to skip waiting and then reload the page.

posts/latest/guides/push-api.mdx

@@ -48,7 +48,7 @@ Before we dive into the awesomeness of push, let's clarify a few things about ho
 
 - `.` (`@remix-pwa/push`): This is the default import route and is used for server-side imports. It includes all the server-side APIs and utilities for building push on the server.
 - `@remix-pwa/push/client`: This is for importing client-side APIs and utilities. It includes all the client-side APIs and utilities for building in your PWA client.
-- `@remix-pwa/push/use-push`: This is the import route for the [`usePush`](/docs/main/use-push) hook, a React hook for everything push in your PWA client.
+- `@remix-pwa/push/use-push`: This is the import route for the [`usePush`](/docs/latest/use-push) hook, a React hook for everything push in your PWA client.
 
 Now that we've made sense of the import routes, let's keep exploring the exciting world of push notifications in web apps!
 
@@ -81,7 +81,7 @@ export function NotificationButton() {
 
 When you call this hook, you'll receive a `PushObject` that's bursting with features. It's like getting a brand-new smartphone, but instead of cat videos and memes, you get a whole suite of push notification superpowers. With this object in hand, you can subscribe to push notifications, unsubscribe from them, and even check if you're already subscribed – all with just a few lines of code.
 
-Check out the [`usePush` doc page](/docs/main/use-push) for more information on how to use this hook and unlock the full potential of push notifications in your web app 🪝.
+Check out the [`usePush` doc page](/docs/latest/use-push) for more information on how to use this hook and unlock the full potential of push notifications in your web app 🪝.
 
 ### `PushManager` to the Rescue
 

posts/latest/hooks/use-push.mdx

@@ -109,4 +109,4 @@ unsubscribeFromPush(() => {
 })
 ```
 
-The `usePush` (client) hook is just one side of the coin. The flipside, server, is a more sophisticated topic covered, alongside others, in the [Push API doc](/docs/main/push-api)
+The `usePush` (client) hook is just one side of the coin. The flipside, server, is a more sophisticated topic covered, alongside others, in the [Push API doc](/docs/latest/push-api)

posts/latest/started/v4.mdx

@@ -5,7 +5,7 @@ alternateTitle: Ugrading to v4
 order: 2
 ---
 
-As the [Quick Start](/docs/main/quick-start) docs might have informed you, Remix PWA v4 utilises just Vite. Previously,
+As the [Quick Start](/docs/latest/quick-start) docs might have informed you, Remix PWA v4 utilises just Vite. Previously,
 Remix PWA utilised `esbuild` and was built to work in tandem with the Remix esbuild framework. As such, we needed to keep
 supporting Remix Esbuild going forward.
 

posts/latest/utils/redirect.mdx

@@ -5,4 +5,4 @@ alternateTitle: redirect
 toc: false
 ---
 
-> Like [`json`](/docs/main/json) and the [`defer`](/docs/main/defer) utility, this function is also a re-export of React Router [redirect](https://reactrouter.com/en/main/fetch/redirect) function.
+> Like [`json`](/docs/latest/json) and the [`defer`](/docs/latest/defer) utility, this function is also a re-export of React Router [redirect](https://reactrouter.com/en/main/fetch/redirect) function.

tests/e2e/link-checker.test.ts

@@ -3,5 +3,5 @@ import { expect, test } from '@playwright/test'
 test('doc navigation test', async ({ page }) => {
   await page.goto('/docs/main')
   await page.click("text=Beginner's Guide")
-  await expect(page).toHaveURL('/docs/main/quick-start')
+  await expect(page).toHaveURL('/docs/latest/quick-start')
 })