@nuxt/docs 4.1.1 → 4.1.3

package/1.getting-started/17.testing.md

@@ -5,7 +5,7 @@ navigation.icon: i-lucide-circle-check
 ---
 
 ::tip
-If you are a module author, you can find more specific information in the [Module Author's guide](/docs/guide/going-further/modules#testing).
+If you are a module author, you can find more specific information in the [Module Author's guide](/docs/4.x/guide/going-further/modules#testing).
 ::
 
 Nuxt offers first-class support for end-to-end and unit testing of your Nuxt application via `@nuxt/test-utils`, a library of test utilities and configuration that currently powers the [tests we use on Nuxt itself](https://github.com/nuxt/nuxt/tree/main/test) and tests throughout the module ecosystem.
@@ -46,8 +46,8 @@ We currently ship an environment for unit testing code that needs a [Nuxt](https
    ```ts twoslash
    export default defineNuxtConfig({
      modules: [
-       '@nuxt/test-utils/module'
-     ]
+       '@nuxt/test-utils/module',
+     ],
    })
    ```
 
@@ -115,7 +115,7 @@ export default defineVitestConfig({
     //     }
     //   }
     // }
-  }
+  },
 })
 ```
 
@@ -199,10 +199,10 @@ export default defineVitestConfig({
         mock: {
           intersectionObserver: true,
           indexedDb: true,
-        }
-      }
-    }
-  }
+        },
+      },
+    },
+  },
 })
 ```
 
@@ -222,8 +222,9 @@ For example:
 
 ```ts twoslash
 // @noErrors
-import { it, expect } from 'vitest'
+import { expect, it } from 'vitest'
 import type { Component } from 'vue'
+
 declare module '#components' {
   export const SomeComponent: Component
 }
@@ -233,17 +234,16 @@ import { mountSuspended } from '@nuxt/test-utils/runtime'
 import { SomeComponent } from '#components'
 
 it('can mount some component', async () => {
-    const component = await mountSuspended(SomeComponent)
-    expect(component.text()).toMatchInlineSnapshot(
-        '"This is an auto-imported component"'
-    )
+  const component = await mountSuspended(SomeComponent)
+  expect(component.text()).toMatchInlineSnapshot(
+    '"This is an auto-imported component"',
+  )
 })
-
 ```
 
 ```ts twoslash
 // @noErrors
-import { it, expect } from 'vitest'
+import { expect, it } from 'vitest'
 // ---cut---
 // tests/components/SomeComponents.nuxt.spec.ts
 import { mountSuspended } from '@nuxt/test-utils/runtime'
@@ -251,8 +251,8 @@ import App from '~/app.vue'
 
 // tests/App.nuxt.spec.ts
 it('can also mount an app', async () => {
-    const component = await mountSuspended(App, { route: '/test' })
-    expect(component.html()).toMatchInlineSnapshot(`
+  const component = await mountSuspended(App, { route: '/test' })
+  expect(component.html()).toMatchInlineSnapshot(`
       "<div>This is an auto-imported component</div>
       <div> I am a global component </div>
       <div>/</div>
@@ -275,8 +275,9 @@ Examples:
 
 ```ts twoslash
 // @noErrors
-import { it, expect } from 'vitest'
+import { expect, it } from 'vitest'
 import type { Component } from 'vue'
+
 declare module '#components' {
   export const SomeComponent: Component
 }
@@ -294,7 +295,7 @@ it('can render some component', async () => {
 
 ```ts twoslash
 // @noErrors
-import { it, expect } from 'vitest'
+import { expect, it } from 'vitest'
 // ---cut---
 // tests/App.nuxt.spec.ts
 import { renderSuspended } from '@nuxt/test-utils/runtime'
@@ -341,8 +342,8 @@ import { mockNuxtImport } from '@nuxt/test-utils/runtime'
 const { useStorageMock } = vi.hoisted(() => {
   return {
     useStorageMock: vi.fn(() => {
-      return { value: 'mocked storage'}
-    })
+      return { value: 'mocked storage' }
+    }),
   }
 })
 
@@ -369,20 +370,20 @@ import { mockComponent } from '@nuxt/test-utils/runtime'
 
 mockComponent('MyComponent', {
   props: {
-    value: String
+    value: String,
   },
-  setup(props) {
+  setup (props) {
     // ...
-  }
+  },
 })
 
 // relative path or alias also works
-mockComponent('~/components/my-component.vue', async () => {
+mockComponent('~/components/my-component.vue', () => {
   // or a factory function
   return defineComponent({
-    setup(props) {
+    setup (props) {
       // ...
-    }
+    },
   })
 })
 
@@ -401,10 +402,10 @@ mockComponent('MyComponent', async () => {
   const { ref, h } = await import('vue')
 
   return defineComponent({
-    setup(props) {
+    setup (props) {
       const counter = ref(0)
       return () => h('div', null, counter.value)
-    }
+    },
   })
 })
 ```
@@ -422,7 +423,7 @@ For example, to mock `/test/` endpoint, you can do:
 import { registerEndpoint } from '@nuxt/test-utils/runtime'
 
 registerEndpoint('/test/', () => ({
-  test: 'test-field'
+  test: 'test-field',
 }))
 ```
 
@@ -433,11 +434,11 @@ import { registerEndpoint } from '@nuxt/test-utils/runtime'
 
 registerEndpoint('/test/', {
   method: 'POST',
-  handler: () => ({ test: 'test-field' })
+  handler: () => ({ test: 'test-field' }),
 })
 ```
 
-> **Note**: If your requests in a component go to an external API, you can use `baseURL` and then make it empty using [Nuxt Environment Override Config](/docs/getting-started/configuration#environment-overrides) (`$test`) so all your requests will go to Nitro server.
+> **Note**: If your requests in a component go to an external API, you can use `baseURL` and then make it empty using [Nuxt Environment Override Config](/docs/4.x/getting-started/configuration#environment-overrides) (`$test`) so all your requests will go to Nitro server.
 
 #### Conflict with End-To-End Testing
 
@@ -455,13 +456,12 @@ mockNuxtImport('useStorage', () => {
     return { value: 'mocked storage' }
   }
 })
-
 ```
 
 `app.e2e.spec.ts`
 
 ```ts twoslash
-import { setup, $fetch } from '@nuxt/test-utils/e2e'
+import { $fetch, setup } from '@nuxt/test-utils/e2e'
 
 await setup({
   setupTimeout: 10000,
@@ -502,7 +502,7 @@ If you prefer to use `@vue/test-utils` on its own for unit testing in Nuxt, and
      test: {
        environment: 'happy-dom',
      },
-   });
+   })
    ```
 
 3. Add a new command for test in your `package.json`
@@ -527,7 +527,7 @@ If you prefer to use `@vue/test-utils` on its own for unit testing in Nuxt, and
 5. Create a simple unit test for this newly created component `~/components/HelloWorld.spec.ts`
 
    ```ts twoslash
-   import { describe, it, expect } from 'vitest'
+   import { describe, expect, it } from 'vitest'
    import { mount } from '@vue/test-utils'
 
    import HelloWorld from './HelloWorld.vue'
@@ -569,7 +569,7 @@ In each `describe` block where you are taking advantage of the `@nuxt/test-utils
 
 ```ts twoslash [test/my-test.spec.ts]
 import { describe, test } from 'vitest'
-import { setup, $fetch } from '@nuxt/test-utils/e2e'
+import { $fetch, setup } from '@nuxt/test-utils/e2e'
 
 describe('My test', async () => {
   await setup({
@@ -624,7 +624,7 @@ Please use the options below for the `setup` method.
   - Type: `number | undefined`
   - Default: `undefined`
 
-- `host`: If provided, a URL to use as the test target instead of building and running a new server. Useful for running "real" end-to-end tests against a deployed version of your application, or against an already running local server (which may provide a significant reduction in test execution timings). See the [target host end-to-end example below](#target-host-end-to-end-example).
+- `host`: If provided, a URL to use as the test target instead of building and running a new server. Useful for running "real" end-to-end tests against a deployed version of your application, or against an already running local server (which may provide a significant reduction in test execution timings). See the [target host end-to-end example below](/docs/4.x/getting-started/testing#target-host-end-to-end-example).
   - Type: `string`
   - Default: `undefined`
 
@@ -648,8 +648,8 @@ For local development or automated deploy pipelines, testing against a separate
 To utilize a separate target host for end-to-end tests, simply provide the `host` property of the `setup` function with the desired URL.
 
 ```ts
-import { setup, createPage } from '@nuxt/test-utils/e2e'
-import { describe, it, expect } from 'vitest'
+import { createPage, setup } from '@nuxt/test-utils/e2e'
+import { describe, expect, it } from 'vitest'
 
 describe('login page', async () => {
   await setup({
@@ -742,8 +742,8 @@ import type { ConfigOptions } from '@nuxt/test-utils/playwright'
 export default defineConfig<ConfigOptions>({
   use: {
     nuxt: {
-      rootDir: fileURLToPath(new URL('.', import.meta.url))
-    }
+      rootDir: fileURLToPath(new URL('.', import.meta.url)),
+    },
   },
   // ...
 })
@@ -770,8 +770,8 @@ import { expect, test } from '@nuxt/test-utils/playwright'
 
 test.use({
   nuxt: {
-    rootDir: fileURLToPath(new URL('..', import.meta.url))
-  }
+    rootDir: fileURLToPath(new URL('..', import.meta.url)),
+  },
 })
 
 test('test', async ({ page, goto }) => {

package/1.getting-started/18.upgrade.md

@@ -32,7 +32,7 @@ bun x nuxt upgrade
 
 ### Nightly Release Channel
 
-To use the latest Nuxt build and test features before their release, read about the [nightly release channel](/docs/guide/going-further/nightly-release-channel) guide.
+To use the latest Nuxt build and test features before their release, read about the [nightly release channel](/docs/4.x/guide/going-further/nightly-release-channel) guide.
 
 ## Migrating to Nuxt 4
 
@@ -186,8 +186,8 @@ export default defineNuxtConfig({
   srcDir: '.',
   // This specifies the directory prefix for `router.options.ts` and `spa-loading-template.html`
   dir: {
-    app: 'app'
-  }
+    app: 'app',
+  },
 })
 ```
 
@@ -224,14 +224,14 @@ These changes have been made to improve memory usage and increase consistency wi
    It may be beneficial to extract any calls to `useAsyncData` that share an explicit key (and have custom options) into their own composable:
 
    ```ts [app/composables/useUserData.ts]
-   export function useUserData(userId: string) {
+   export function useUserData (userId: string) {
      return useAsyncData(
        `user-${userId}`,
        () => fetchUser(userId),
-       { 
+       {
          deep: true,
-         transform: (user) => ({ ...user, lastAccessed: new Date() })
-       }
+         transform: user => ({ ...user, lastAccessed: new Date() }),
+       },
      )
    }
    ```
@@ -260,8 +260,8 @@ Alternatively, for now, you can disable this behaviour with:
 export default defineNuxtConfig({
   experimental: {
     granularCachedData: false,
-    purgeCachedData: false
-  }
+    purgeCachedData: false,
+  },
 })
 ```
 
@@ -271,7 +271,7 @@ export default defineNuxtConfig({
 
 #### What Changed
 
-The order in which modules are loaded when using [Nuxt layers](/docs/guide/going-further/layers) has been corrected. Previously, modules from the project root were loaded before modules from extended layers, which was the reverse of the expected behavior.
+The order in which modules are loaded when using [Nuxt layers](/docs/4.x/guide/going-further/layers) has been corrected. Previously, modules from the project root were loaded before modules from extended layers, which was the reverse of the expected behavior.
 
 Now modules are loaded in the correct order:
 
@@ -303,23 +303,23 @@ Example of the new correct order:
 ```ts
 // Layer: my-layer/nuxt.config.ts
 export default defineNuxtConfig({
-  modules: ['layer-module-1', 'layer-module-2']
+  modules: ['layer-module-1', 'layer-module-2'],
 })
 
 // Project: nuxt.config.ts
 export default defineNuxtConfig({
   extends: ['./my-layer'],
-  modules: ['project-module-1', 'project-module-2']
+  modules: ['project-module-1', 'project-module-2'],
 })
 
 // Loading order (corrected):
 // 1. layer-module-1
-// 2. layer-module-2  
+// 2. layer-module-2
 // 3. project-module-1 (can override layer modules)
 // 4. project-module-2 (can override layer modules)
 ```
 
-If you encounter issues with module order dependencies due to needing to register a hook, consider using the [`modules:done` hook](/docs/guide/going-further/modules#custom-hooks) for modules that need to call a hook. This is run after all other modules have been loaded, which means it is safe to use.
+If you encounter issues with module order dependencies due to needing to register a hook, consider using the [`modules:done` hook](/docs/4.x/guide/going-further/modules#custom-hooks) for modules that need to call a hook. This is run after all other modules have been loaded, which means it is safe to use.
 
 👉 See [PR #31507](https://github.com/nuxt/nuxt/pull/31507) and [issue #25719](https://github.com/nuxt/nuxt/issues/25719) for more details.
 
@@ -380,8 +380,8 @@ Alternatively, for now, you can disable this behaviour with:
 ```ts twoslash [nuxt.config.ts]
 export default defineNuxtConfig({
   experimental: {
-    normalizeComponentNames: false
-  }
+    normalizeComponentNames: false,
+  },
 })
 ```
 
@@ -420,14 +420,14 @@ useHead({
 * If you're using [Template Params](https://unhead.unjs.io/docs/head/guides/plugins/template-params) or [Alias Tag Sorting](https://unhead.unjs.io/docs/head/guides/plugins/alias-sorting), you will need to explicitly opt in to these features now.
 
 ```ts
-import { TemplateParamsPlugin, AliasSortingPlugin } from '@unhead/vue/plugins'
+import { AliasSortingPlugin, TemplateParamsPlugin } from '@unhead/vue/plugins'
 
 export default defineNuxtPlugin({
-  setup() {
+  setup () {
     const unhead = injectHead()
     unhead.use(TemplateParamsPlugin)
     unhead.use(AliasSortingPlugin)
-  }
+  },
 })
 ```
 
@@ -444,7 +444,7 @@ If you still have issues you may revert to the v1 behavior by enabling the `head
 export default defineNuxtConfig({
   unhead: {
     legacy: true,
-  }
+  },
 })
 ```
 
@@ -483,7 +483,7 @@ Alternatively, you can revert to the previous behaviour with:
 export default defineNuxtConfig({
   experimental: {
     spaLoadingTemplateLocation: 'within',
-  }
+  },
 })
 ```
 
@@ -527,8 +527,8 @@ This feature is fully configurable and you can revert to the previous behavior b
 ```ts twoslash [nuxt.config.ts]
 export default defineNuxtConfig({
   features: {
-    inlineStyles: true
-  }
+    inlineStyles: true,
+  },
 })
 ```
 
@@ -566,8 +566,8 @@ Alternatively, you can revert to the previous behaviour with:
 ```ts twoslash [nuxt.config.ts]
 export default defineNuxtConfig({
   experimental: {
-    scanPageMeta: true
-  }
+    scanPageMeta: true,
+  },
 })
 ```
 
@@ -607,8 +607,8 @@ Alternatively, you can disable this feature with:
 ```ts twoslash [nuxt.config.ts]
 export default defineNuxtConfig({
   experimental: {
-    sharedPrerenderData: false
-  }
+    sharedPrerenderData: false,
+  },
 })
 ```
 
@@ -632,24 +632,6 @@ If you were checking if `data.value` or `error.value` were `null`, you can updat
 You can automate this step by running `npx codemod@latest nuxt/4/default-data-error-value`
 ::
 
-If you encounter any issues you can revert back to the previous behavior with:
-
-```ts twoslash [nuxt.config.ts]
-// @errors: 2353
-export default defineNuxtConfig({
-  experimental: {
-    defaults: {
-      useAsyncData: {
-        value: 'null',
-        errorValue: 'null'
-      }
-    }
-  }
-})
-```
-
-Please report an issue if you are doing this, as we do not plan to keep this as configurable.
-
 ### Removal of deprecated `boolean` values for `dedupe` option when calling `refresh` in `useAsyncData` and `useFetch`
 
 🚦 **Impact Level**: Minimal
@@ -660,7 +642,7 @@ Previously it was possible to pass `dedupe: boolean` to `refresh`. These were al
 
 ```ts twoslash [app/app.vue]
 // @errors: 2322
-const { refresh } = await useAsyncData(async () => ({ message: 'Hello, Nuxt!' }))
+const { refresh } = await useAsyncData(() => Promise.resolve({ message: 'Hello, Nuxt!' }))
 
 async function refreshData () {
   await refresh({ dedupe: true })
@@ -748,8 +730,8 @@ Alternatively, you can temporarily revert to the previous behavior with:
 ```ts twoslash [nuxt.config.ts]
 export default defineNuxtConfig({
   experimental: {
-    pendingWhenIdle: true
-  }
+    pendingWhenIdle: true,
+  },
 })
 ```
 
@@ -788,8 +770,8 @@ To opt out of this behavior:
 // Or globally in your Nuxt config
 export default defineNuxtConfig({
   experimental: {
-    alwaysRunFetchOnKeyChange: true
-  }
+    alwaysRunFetchOnKeyChange: true,
+  },
 })
 ```
 
@@ -822,10 +804,10 @@ In most cases, no migration steps are required, but if you rely on the reactivit
      experimental: {
        defaults: {
          useAsyncData: {
-           deep: true
-         }
-       }
-     }
+           deep: true,
+         },
+       },
+     },
    })
    ```
 
@@ -904,10 +886,10 @@ Probably no migration is necessary but if you wish to revert to previous behavio
 ```ts
 export default defineNuxtConfig({
   hooks: {
-    'app:resolve'(app) {
+    'app:resolve' (app) {
       app.middleware = app.middleware.filter(mw => !/\/index\.[^/]+$/.test(mw.path))
-    }
-  }
+    },
+  },
 })
 ```
 
@@ -957,7 +939,7 @@ Finally, if you are using the template utilities (`serialize`, `importName`, `im
 ```ts
 import { genDynamicImport, genImport, genSafeVariableName } from 'knitwork'
 
-const serialize = (data: any) => JSON.stringify(data, null, 2).replace(/"{(.+)}"(?=,?$)/gm, r => JSON.parse(r).replace(/^{(.*)}$/, '$1'))
+const serialize = (data: any) => JSON.stringify(data, null, 2).replace(/"\{(.+)\}"(?=,?$)/gm, r => JSON.parse(r).replace(/^\{(.*)\}$/, '$1'))
 
 const importSources = (sources: string | string[], { lazy = false } = {}) => {
   return toArray(sources).map((src) => {
@@ -1002,10 +984,10 @@ There are two approaches:
      typescript: {
        tsConfig: {
          compilerOptions: {
-           noUncheckedIndexedAccess: false
-         }
-       }
-     }
+           noUncheckedIndexedAccess: false,
+         },
+       },
+     },
    })
    ```
 
@@ -1090,16 +1072,16 @@ However, to take advantage of improved type checking, you can opt in to the new
        // Customize app/server TypeScript config
        tsConfig: {
          compilerOptions: {
-           strict: true
-         }
+           strict: true,
+         },
        },
-       // Customize build-time TypeScript config  
+       // Customize build-time TypeScript config
        nodeTsConfig: {
          compilerOptions: {
-           strict: true
-         }
-       }
-     }
+           strict: true,
+         },
+       },
+     },
    })
    ```
 
@@ -1195,7 +1177,7 @@ Static sites             | ✅             | ✅                | ✅
 
 The migration guide provides a step-by-step comparison of Nuxt 2 features to Nuxt 3+ features and guidance to adapt your current application.
 
-::read-more{to="/docs/migration/overview"}
+::read-more{to="/docs/4.x/migration/overview"}
 Check out the **guide to migrating from Nuxt 2 to Nuxt 3**.
 ::
 
@@ -1203,6 +1185,6 @@ Check out the **guide to migrating from Nuxt 2 to Nuxt 3**.
 
 If you prefer to progressively migrate your Nuxt 2 application to Nuxt 3, you can use Nuxt Bridge. Nuxt Bridge is a compatibility layer that allows you to use Nuxt 3+ features in Nuxt 2 with an opt-in mechanism.
 
-::read-more{to="/docs/bridge/overview"}
+::read-more{to="/docs/4.x/bridge/overview"}
 **Migrate from Nuxt 2 to Nuxt Bridge**
 ::

package/2.guide/0.index.md

@@ -7,19 +7,19 @@ surround: false
 ---
 
 ::card-group{class="sm:grid-cols-1"}
-  ::card{icon="i-lucide-medal" title="Key Concepts" to="/docs/guide/concepts"}
-  Discover the main concepts behind Nuxt, from auto-import, hybrid rendering to its TypeScript support.
-  ::
-  ::card{icon="i-lucide-folders" title="Directory Structure" to="/docs/guide/directory-structure"}
+  ::card{icon="i-lucide-folders" title="Directory Structure" to="/docs/4.x/guide/directory-structure"}
   Learn about Nuxt directory structure and what benefits each directory or file offers.
   ::
-  ::card{icon="i-lucide-star" title="Going Further" to="/docs/guide/going-further"}
+  ::card{icon="i-lucide-medal" title="Key Concepts" to="/docs/4.x/guide/concepts"}
+  Discover the main concepts behind Nuxt, from auto-import, hybrid rendering to its TypeScript support.
+  ::
+  ::card{icon="i-lucide-star" title="Going Further" to="/docs/4.x/guide/going-further"}
   Master Nuxt with advanced concepts like experimental features, hooks, modules, and more.
   ::
-  ::card{icon="i-lucide-book-open" title="Recipes" to="/docs/guide/recipes"}
+  ::card{icon="i-lucide-book-open" title="Recipes" to="/docs/4.x/guide/recipes"}
   Find solutions to common problems and learn how to implement them in your Nuxt project.
   ::
-  ::card{icon="i-lucide-square-check" title="Best Practices" to="/docs/guide/best-practices"}
+  ::card{icon="i-lucide-square-check" title="Best Practices" to="/docs/4.x/guide/best-practices"}
   Learn about best practices when developing with Nuxt
   ::
 ::

package/2.guide/{2.directory-structure → 1.directory-structure}/.navigation.yml

@@ -1,3 +1,3 @@
 title: Directory Structure
 titleTemplate: '%s · Nuxt Directory Structure'
-icon: i-lucide-folders
+icon: i-vscode-icons-default-folder

package/2.guide/{2.directory-structure → 1.directory-structure}/0.nuxt.md

@@ -2,11 +2,11 @@
 title: ".nuxt"
 description: "Nuxt uses the .nuxt/ directory in development to generate your Vue application."
 head.title: ".nuxt/"
-navigation.icon: i-lucide-folder
+navigation.icon: i-vscode-icons-folder-type-temp
 ---
 
 ::important
-This directory should be added to your [`.gitignore`](/docs/guide/directory-structure/gitignore) file to avoid pushing the dev build output to your repository.
+This directory should be added to your [`.gitignore`](/docs/4.x/guide/directory-structure/gitignore) file to avoid pushing the dev build output to your repository.
 ::
 
 This directory is interesting if you want to learn more about the files Nuxt generates based on your directory structure.
@@ -16,5 +16,5 @@ Nuxt also provides a Virtual File System (VFS) for modules to add templates to t
 You can explore the generated files by opening the [Nuxt DevTools](https://devtools.nuxt.com) in development mode and navigating to the **Virtual Files** tab.
 
 ::warning
-You should not touch any files inside since the whole directory will be re-created when running [`nuxt dev`](/docs/api/commands/dev).
+You should not touch any files inside since the whole directory will be re-created when running [`nuxt dev`](/docs/4.x/api/commands/dev).
 ::

package/2.guide/1.directory-structure/0.output.md

@@ -0,0 +1,18 @@
+---
+title: ".output"
+description: "Nuxt creates the .output/ directory when building your application for production."
+head.title: ".output/"
+navigation.icon: i-vscode-icons-folder-type-package
+---
+
+::important
+This directory should be added to your [`.gitignore`](/docs/4.x/guide/directory-structure/gitignore) file to avoid pushing the build output to your repository.
+::
+
+Use this directory to deploy your Nuxt application to production.
+
+:read-more{to="/docs/4.x/getting-started/deployment"}
+
+::warning
+You should not touch any files inside since the whole directory will be re-created when running [`nuxt build`](/docs/4.x/api/commands/build).
+::

package/2.guide/{2.directory-structure → 1.directory-structure}/1.app/.navigation.yml

@@ -2,4 +2,4 @@ title: app
 titleTemplate: '%s · Nuxt Directory Structure'
 head.title: "app/"
 defaultOpen: true
-icon: i-lucide-folders
+icon: i-vscode-icons-folder-type-app

package/2.guide/{2.directory-structure → 1.directory-structure}/1.app/1.assets.md

@@ -2,15 +2,15 @@
 title: "assets"
 description: "The assets/ directory is used to add all the website's assets that the build tool will process."
 head.title: "assets/"
-navigation.icon: i-lucide-folder
+navigation.icon: i-vscode-icons-folder-type-asset
 ---
 
 The directory usually contains the following types of files:
 
 - Stylesheets (CSS, SASS, etc.)
 - Fonts
-- Images that won't be served from the [`public/`](/docs/guide/directory-structure/public) directory.
+- Images that won't be served from the [`public/`](/docs/4.x/guide/directory-structure/public) directory.
 
-If you want to serve assets from the server, we recommend taking a look at the [`public/`](/docs/guide/directory-structure/public) directory.
+If you want to serve assets from the server, we recommend taking a look at the [`public/`](/docs/4.x/guide/directory-structure/public) directory.
 
-:read-more{to="/docs/getting-started/assets"}
+:read-more{to="/docs/4.x/getting-started/assets"}