@nuxt/docs-nightly 4.2.1-29369624.1cc53932 → 4.2.1-29370805.6a102676

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
@@ -1212,33 +1212,25 @@ However, to take advantage of improved type checking, you can opt in to the new
1212
1212
  Augmenting types from outside the `app/`, `server/`, or `shared/` directories will not work with the new project references setup.
1213
1213
  ::
1214
1214
 
1215
- 5. **Configure TypeScript options** if needed:
1215
+ 5. **Configure Node.js TypeScript options** if needed:
1216
1216
  <!-- @case-police-ignore tsConfig -->
1217
1217
 
1218
1218
  ```ts
1219
1219
  export default defineNuxtConfig({
1220
1220
  typescript: {
1221
- // customize tsconfig.app.json
1221
+ // Customize app/server TypeScript config
1222
1222
  tsConfig: {
1223
- // ...
1224
- },
1225
- // customize tsconfig.shared.json
1226
- sharedTsConfig: {
1227
- // ...
1223
+ compilerOptions: {
1224
+ strict: true,
1225
+ },
1228
1226
  },
1229
- // customize tsconfig.node.json
1227
+ // Customize build-time TypeScript config
1230
1228
  nodeTsConfig: {
1231
- // ...
1232
- },
1233
- },
1234
- nitro: {
1235
- typescript: {
1236
- // customize tsconfig.server.json
1237
- tsConfig: {
1238
- // ...
1229
+ compilerOptions: {
1230
+ strict: true,
1239
1231
  },
1240
1232
  },
1241
- }
1233
+ },
1242
1234
  })
1243
1235
  ```
1244
1236
 
@@ -5,7 +5,7 @@ head.title: "node_modules/"
5
5
  navigation.icon: i-vscode-icons-folder-type-node
6
6
  ---
7
7
 
8
- The package manager ([`npm`](https://docs.npmjs.com/cli/commands/npm/) or [`yarn`](https://yarnpkg.com) or [`pnpm`](https://pnpm.io/cli/install) or [`bun`](https://bun.com/package-manager)) creates this directory to store the dependencies of your project.
8
+ The package manager ([`npm`](https://docs.npmjs.com/cli/commands/npm) or [`yarn`](https://yarnpkg.com) or [`pnpm`](https://pnpm.io/cli/install) or [`bun`](https://bun.com/package-manager)) creates this directory to store the dependencies of your project.
9
9
 
10
10
  ::important
11
11
  This directory should be added to your [`.gitignore`](/docs/4.x/guide/directory-structure/gitignore) file to avoid pushing the dependencies to your repository.
@@ -1,13 +1,13 @@
1
1
  ---
2
2
  title: "tsconfig.json"
3
- description: "Learn how Nuxt manages TypeScript configuration across different parts of your project."
3
+ description: "Nuxt generates multiple TypeScript configuration files with sensible defaults and your aliases."
4
4
  head.title: "tsconfig.json"
5
5
  navigation.icon: i-vscode-icons-file-type-tsconfig
6
6
  ---
7
7
 
8
- Nuxt [automatically generates](/docs/4.x/guide/concepts/typescript#auto-generated-types) multiple TypeScript configuration files (`.nuxt/tsconfig.app.json`, `.nuxt/tsconfig.server.json`, `.nuxt/tsconfig.node.json` and `.nuxt/tsconfig.shared.json`) that include recommended basic TypeScript configuration for your project, references to [auto-imports](/docs/4.x/guide/concepts/auto-imports), [API route types](/docs/4.x/guide/concepts/server-engine#typed-api-routes), path aliases, and more.
8
+ Nuxt [automatically generates](/docs/4.x/guide/concepts/typescript) multiple TypeScript configuration files (`.nuxt/tsconfig.app.json`, `.nuxt/tsconfig.server.json`, `.nuxt/tsconfig.node.json` and `.nuxt/tsconfig.shared.json`) with the resolved aliases you are using in your Nuxt project, as well as with other sensible defaults.
9
9
 
10
- Your Nuxt project should include the following `tsconfig.json` file at the root of the project:
10
+ You can benefit from this by creating a `tsconfig.json` in the root of your project with the following content:
11
11
 
12
12
  ```json [tsconfig.json]
13
13
  {
@@ -29,41 +29,10 @@ Your Nuxt project should include the following `tsconfig.json` file at the root
29
29
  }
30
30
  ```
31
31
 
32
- ::warning
33
- We do not recommend modifying the contents of this file directly, as doing so could overwrite important settings that Nuxt or other modules rely on. Instead, extend it via `nuxt.config.ts`.
32
+ ::note
33
+ As you need to, you can customize the contents of this file. However, it is recommended that you don't overwrite `target`, `module` and `moduleResolution`.
34
34
  ::
35
35
 
36
- ::read-more{to="/docs/4.x/guide/concepts/typescript#project-references"}
37
- Read more about the different type contexts of a Nuxt project here.
36
+ ::note
37
+ If you need to customize your `paths`, this will override the auto-generated path aliases. Instead, we recommend that you add any path aliases you need to the [`alias`](/docs/4.x/api/nuxt-config#alias) property within your `nuxt.config`, where they will get picked up and added to the auto-generated `tsconfig`.
38
38
  ::
39
-
40
- ## Extending TypeScript Configuration
41
-
42
- You can customize the TypeScript configuration of your Nuxt project for each context (`app`, `shared`, `node`, and `server`) in the `nuxt.config.ts` file.
43
- <!-- @case-police-ignore tsConfig -->
44
- ```ts twoslash [nuxt.config.ts]
45
- export default defineNuxtConfig({
46
- typescript: {
47
- // customize tsconfig.app.json
48
- tsConfig: {
49
- // ...
50
- },
51
- // customize tsconfig.shared.json
52
- sharedTsConfig: {
53
- // ...
54
- },
55
- // customize tsconfig.node.json
56
- nodeTsConfig: {
57
- // ...
58
- },
59
- },
60
- nitro: {
61
- typescript: {
62
- // customize tsconfig.server.json
63
- tsConfig: {
64
- // ...
65
- },
66
- },
67
- }
68
- })
69
- ```
@@ -47,37 +47,56 @@ export default defineNuxtConfig({
47
47
 
48
48
  ## Auto-generated Types
49
49
 
50
- Nuxt projects rely on auto-generated types to work properly. These types are stored in the [`.nuxt`](/docs/4.x/guide/directory-structure/nuxt) directory and are generated when you run the dev server or build your application. You can also generate these files manually by running `nuxt prepare`.
50
+ When you run `nuxt dev` or `nuxt build`, Nuxt generates the following files for IDE type support (and type checking):
51
51
 
52
- The generated `tsconfig.json` files inside the [`.nuxt`](/docs/4.x/guide/directory-structure/nuxt) directory include **recommended basic TypeScript configuration** for your project, references to [auto-imports](/docs/4.x/guide/concepts/auto-imports), [API route types](/docs/4.x/guide/concepts/server-engine#typed-api-routes), path aliases like `#imports`, `~/file`, or `#build/file`, and more.
52
+ ### `.nuxt/nuxt.d.ts`
53
53
 
54
- ::warning
55
- Nuxt relies on this configuration, and [Nuxt Modules](/docs/4.x/guide/going-further/modules) can extend it as well. For this reason, it is not recommended to modify your `tsconfig.json` file directly, as doing so could overwrite important settings. Instead, extend it via `nuxt.config.ts`. [Learn more about extending the configuration here](/docs/4.x/guide/directory-structure/tsconfig).
54
+ This file contains the types of any modules you are using, as well as the key types that Nuxt requires. Your IDE should recognize these types automatically.
55
+
56
+ Some of the references in the file are to files that are only generated within your `buildDir` (`.nuxt`) and therefore for full typings, you will need to run `nuxt dev` or `nuxt build`.
57
+
58
+ ### `.nuxt/tsconfig.app.json`
59
+
60
+ This file contains the recommended basic TypeScript configuration for your project, including resolved aliases injected by Nuxt or modules you are using, so you can get full type support and path auto-complete for aliases like `~/file` or `#build/file`.
61
+
62
+ ::note
63
+ Consider using the `imports` section of [nuxt.config](/docs/4.x/api/nuxt-config#imports) to include directories beyond the default ones. This can be useful for auto-importing types which you're using across your app.
56
64
  ::
57
65
 
66
+ [Read more about how to extend this configuration](/docs/4.x/guide/directory-structure/tsconfig).
67
+
58
68
  ::tip{icon="i-lucide-video" to="https://youtu.be/umLI7SlPygY" target="_blank"}
59
69
  Watch a video from Daniel Roe explaining built-in Nuxt aliases.
60
70
  ::
61
71
 
72
+ ::note
73
+ Nitro also [auto-generates types](/docs/4.x/guide/concepts/server-engine#typed-api-routes) for API routes. Plus, Nuxt also generates types for globally available components and [auto-imports from your composables](/docs/4.x/guide/directory-structure/app/composables), plus other core functionality.
74
+ ::
75
+
76
+ ::note
77
+ For backward compatibility, Nuxt still generates `./.nuxt/tsconfig.json`. However, we recommend using [TypeScript project references](/docs/4.x/guide/directory-structure/tsconfig) with the new configuration files (`.nuxt/tsconfig.app.json`, `.nuxt/tsconfig.server.json`, etc.) for better type safety and performance.
78
+
79
+ If you do extend from `./.nuxt/tsconfig.json`, keep in mind that all options will be overwritten by those defined in your `tsconfig.json`. Overwriting options such as `"compilerOptions.paths"` with your own configuration will lead TypeScript to not factor in the module resolutions, which can cause module resolutions such as `#imports` to not be recognized.
80
+
81
+ In case you need to extend options further, you can use the [`alias` property](/docs/4.x/api/nuxt-config#alias) within your `nuxt.config`. Nuxt will pick them up and extend the generated TypeScript configurations accordingly.
82
+ ::
83
+
62
84
  ## Project References
63
85
 
64
86
  Nuxt uses [TypeScript project references](https://www.typescriptlang.org/docs/handbook/project-references.html) to improve type-checking performance and provide better IDE support. This feature allows TypeScript to break up your codebase into smaller, more manageable pieces.
65
87
 
66
88
  ### How Nuxt Uses Project References
67
89
 
68
- When you run `nuxt dev`, `nuxt build` or `nuxt prepare`, Nuxt will generate multiple `tsconfig.json` files for different parts of your application.
90
+ When you run `nuxt dev` or `nuxt build`, Nuxt will generate multiple `tsconfig.json` files for different parts of your application.
69
91
 
70
- - **`.nuxt/tsconfig.app.json`** - Configuration for your application code within the `app/` directory
71
- - **`.nuxt/tsconfig.node.json`** - Configuration for your `nuxt.config.ts` and files outside the other contexts
92
+ - **`.nuxt/tsconfig.app.json`** - Configuration for your application code
93
+ - **`.nuxt/tsconfig.node.json`** - Configuration for your `nuxt.config` and modules
72
94
  - **`.nuxt/tsconfig.server.json`** - Configuration for server-side code (when applicable)
73
95
  - **`.nuxt/tsconfig.shared.json`** - For code shared between app and server contexts (like types and non-environment specific utilities)
96
+ - **`.nuxt/tsconfig.json`** - Legacy configuration for backward compatibility
74
97
 
75
98
  Each of these files is configured to reference the appropriate dependencies and provide optimal type-checking for their specific context.
76
99
 
77
- ::note
78
- For backward compatibility, Nuxt still generates `.nuxt/tsconfig.json`. However, we recommend using [TypeScript project references](/docs/4.x/guide/directory-structure/tsconfig) with the new configuration files (`.nuxt/tsconfig.app.json`, `.nuxt/tsconfig.server.json`, etc.) for better type safety and performance. This legacy file will be removed in a future version of Nuxt.
79
- ::
80
-
81
100
  ### Benefits of Project References
82
101
 
83
102
  - **Faster builds**: TypeScript can skip rebuilding unchanged projects
@@ -85,9 +104,13 @@ For backward compatibility, Nuxt still generates `.nuxt/tsconfig.json`. However,
85
104
  - **Isolated compilation**: Errors in one part of your application don't prevent compilation of other parts
86
105
  - **Clearer dependency management**: Each project explicitly declares its dependencies
87
106
 
107
+ ::note
108
+ The project reference setup is handled automatically by Nuxt. You typically don't need to modify these configurations manually, but understanding how they work can help you troubleshoot type-checking issues.
109
+ ::
110
+
88
111
  ### Augmenting Types with Project References
89
112
 
90
- Since the project is divided into **multiple type contexts**, it's important to **augment types within the correct context** to ensure they're properly recognized. TypeScript will not recognize augmentations placed outside these directories unless they are explicitly included in the appropriate context.
113
+ Since the project is divided into **multiple type contexts**, it's important to **augment types within the correct context** to ensure they are properly recognized.
91
114
 
92
115
  For example, if you want to augment types for the `app` context, the augmentation file should be placed in the `app/` directory.
93
116
 
@@ -95,15 +118,15 @@ Similarly:
95
118
  - For the `server` context, place the augmentation file in the `server/` directory.
96
119
  - For types that are **shared between the app and server**, place the file in the `shared/` directory.
97
120
 
98
- ::read-more{to="/docs/4.x/guide/going-further/modules#extending-tsconfigjson"}
99
- Read more about augmenting specific type contexts from **files outside those contexts** in the Module Author Guide.
121
+ ::warning
122
+ Augmenting types outside of these directories will not be recognized by TypeScript.
100
123
  ::
101
124
 
102
125
  ## Strict Checks
103
126
 
104
127
  TypeScript comes with certain checks to give you more safety and analysis of your program.
105
128
 
106
- [Strict checks](https://www.typescriptlang.org/docs/handbook/migrating-from-javascript.html#getting-stricter-checks) are enabled by default in Nuxt when the [`typescript.typeCheck`](/docs/4.x/guide/concepts/typescript#type-checking) option is enabled to give you greater type safety.
129
+ [Strict checks](https://www.typescriptlang.org/docs/handbook/migrating-from-javascript.html#getting-stricter-checks) are enabled by default in Nuxt to give you greater type safety.
107
130
 
108
131
  If you are currently converting your codebase to TypeScript, you may want to temporarily disable strict checks by setting `strict` to `false` in your `nuxt.config`:
109
132
 
@@ -653,19 +653,6 @@ export default defineNuxtModule({
653
653
  })
654
654
  ```
655
655
 
656
- #### Updating Templates
657
-
658
- If you need to update your templates/virtual files, you can leverage the `updateTemplates` utility like this:
659
-
660
- ```ts
661
- nuxt.hook('builder:watch', (event, path) => {
662
- if (path.includes('my-module-feature.config')) {
663
- // This will reload the template that you registered
664
- updateTemplates({ filter: t => t.filename === 'my-module-feature.mjs' })
665
- }
666
- })
667
- ```
668
-
669
656
  #### Adding Type Declarations
670
657
 
671
658
  You might also want to add a type declaration to the user's project (for example, to augment a Nuxt interface
@@ -704,73 +691,19 @@ nuxt.hook('prepare:types', ({ references }) => {
704
691
  })
705
692
  ```
706
693
 
707
- #### Extending `tsconfig.json`
708
-
709
- There are multiple ways to extend the TypeScript configuration of the user's project from your module.
710
-
711
- The simplest way is to modify the Nuxt configuration directly like this:
712
-
713
- <!-- @case-police-ignore tsConfig -->
714
- ```ts
715
- // extend tsconfig.app.json
716
- nuxt.options.typescript.tsConfig.include ??= []
717
- nuxt.options.typescript.tsConfig.include.push(resolve('./augments.d.ts'))
718
-
719
- // extend tsconfig.shared.json
720
- nuxt.options.typescript.sharedTsConfig.include ??= []
721
- nuxt.options.typescript.sharedTsConfig.include.push(resolve('./augments.d.ts'))
722
-
723
- // extend tsconfig.node.json
724
- nuxt.options.typescript.nodeTsConfig.include ??= []
725
- nuxt.options.typescript.nodeTsConfig.include.push(resolve('./augments.d.ts'))
726
-
727
- // extend tsconfig.server.json
728
- nuxt.options.nitro.typescript ??= {}
729
- nuxt.options.nitro.typescript.tsConfig ??= {}
730
- nuxt.options.nitro.typescript.tsConfig.include ??= []
731
- nuxt.options.nitro.typescript.tsConfig.include.push(resolve('./augments.d.ts'))
732
- ```
694
+ ##### Updating Templates
733
695
 
734
- Alternatively, you can use the `prepare:types` and `nitro:prepare:types` hooks to extend the TypeScript references for specific type contexts, or modify the TypeScript configuration similar to the example above.
696
+ If you need to update your templates/virtual files, you can leverage the `updateTemplates` utility like this :
735
697
 
736
698
  ```ts
737
- nuxt.hook('prepare:types', ({ references, sharedReferences, nodeReferences }) => {
738
- // extend app context
739
- references.push({ path: resolve('./augments.d.ts') })
740
- // extend shared context
741
- sharedReferences.push({ path: resolve('./augments.d.ts') })
742
- // extend node context
743
- nodeReferences.push({ path: resolve('./augments.d.ts') })
744
- })
745
-
746
- nuxt.hook('nitro:prepare:types', ({ references }) => {
747
- // extend server context
748
- references.push({ path: resolve('./augments.d.ts') })
699
+ nuxt.hook('builder:watch', (event, path) => {
700
+ if (path.includes('my-module-feature.config')) {
701
+ // This will reload the template that you registered
702
+ updateTemplates({ filter: t => t.filename === 'my-module-feature.mjs' })
703
+ }
749
704
  })
750
705
  ```
751
706
 
752
- ::note
753
- TypeScript references add files to the type context [without being affected by the `exclude` option in `tsconfig.json`](https://www.typescriptlang.org/tsconfig/#exclude).
754
- ::
755
-
756
- #### Augmenting Types From Modules
757
-
758
- Nuxt automatically includes your module's directories in the appropriate type contexts. To augment types from your module, all you need to do is place the type declaration file in the appropriate directory based on the augmented type context. Alternatively, you can [extend the TypeScript configuration](/docs/4.x/guide/going-further/modules#extending-tsconfigjson) to augment from an arbitrary location.
759
-
760
- - `my-module/runtime/` - app type context (except for the `runtime/server` directory)
761
- - `my-module/runtime/server/` - server type context
762
- - `my-module/` - node type context (except for the `runtime/` and `runtime/server` directories)
763
-
764
- ```bash [Directory Structure]
765
- -| my-module/ # node type context
766
- ---| runtime/ # app type context
767
- ------| augments.app.d.ts
768
- ------| server/ # server type context
769
- ---------| augments.server.d.ts
770
- ---| module.ts
771
- ---| augments.node.d.ts
772
- ```
773
-
774
707
  ### Testing
775
708
 
776
709
  Testing helps ensuring your module works as expected given various setup. Find in this section how to perform various kinds of tests against your module.
@@ -841,7 +774,7 @@ An example of such a workflow is available on [the module starter](https://githu
841
774
 
842
775
  Having a playground Nuxt application to test your module when developing it is really useful. [The module starter integrates one for that purpose](/docs/4.x/guide/going-further/modules#how-to-develop).
843
776
 
844
- You can test your module with other Nuxt applications (applications that are not part of your module repository) locally. To do so, you can use [`npm pack`](https://docs.npmjs.com/cli/commands/npm-pack/) command, or your package manager equivalent, to create a tarball from your module. Then in your test project, you can add your module to `package.json` packages as: `"my-module": "file:/path/to/tarball.tgz"`.
777
+ You can test your module with other Nuxt applications (applications that are not part of your module repository) locally. To do so, you can use [`npm pack`](https://docs.npmjs.com/cli/commands/npm-pack) command, or your package manager equivalent, to create a tarball from your module. Then in your test project, you can add your module to `package.json` packages as: `"my-module": "file:/path/to/tarball.tgz"`.
845
778
 
846
779
  After that, you should be able to reference `my-module` like in any regular project.
847
780
 
@@ -8,28 +8,28 @@ links:
8
8
  size: xs
9
9
  ---
10
10
 
11
+ The `useHeadSafe` composable is a wrapper around the [`useHead`](/docs/4.x/api/composables/use-head) composable that restricts the input to only allow safe values.
12
+
11
13
  ## Usage
12
14
 
13
- The `useHeadSafe` composable is a wrapper around the [`useHead`](/docs/4.x/api/composables/use-head) composable that restricts the input to only allow safe values. This is the recommended way to manage head data when working with user input, as it prevents XSS attacks by sanitizing potentially dangerous attributes.
15
+ You can pass all the same values as [`useHead`](/docs/4.x/api/composables/use-head)
14
16
 
15
- ```vue [app/app.vue]
16
- <script setup lang="ts">
17
+ ```ts
17
18
  useHeadSafe({
18
19
  script: [
19
20
  { id: 'xss-script', innerHTML: 'alert("xss")' },
20
21
  ],
21
22
  meta: [
22
- { 'http-equiv': 'refresh', content: '0;javascript:alert(1)' },
23
+ { 'http-equiv': 'refresh', 'content': '0;javascript:alert(1)' },
23
24
  ],
24
25
  })
25
26
  // Will safely generate
26
27
  // <script id="xss-script"></script>
27
28
  // <meta content="0;javascript:alert(1)">
28
- </script>
29
29
  ```
30
30
 
31
- ::warning
32
- When using `useHeadSafe`, potentially dangerous attributes like `innerHTML` in scripts or `http-equiv` in meta tags are automatically stripped out to prevent XSS attacks. Use this composable whenever you're working with user-generated content.
31
+ ::read-more{to="https://unhead.unjs.io/docs/typescript/head/api/composables/use-head-safe" target="_blank"}
32
+ Read more on the `Unhead` documentation.
33
33
  ::
34
34
 
35
35
  ## Type
@@ -38,9 +38,7 @@ When using `useHeadSafe`, potentially dangerous attributes like `innerHTML` in s
38
38
  export function useHeadSafe (input: MaybeComputedRef<HeadSafe>): void
39
39
  ```
40
40
 
41
- ### Allowed Attributes
42
-
43
- The following attributes are whitelisted for each head element type:
41
+ The list of allowed values is:
44
42
 
45
43
  ```ts
46
44
  const WhitelistAttributes = {
@@ -55,34 +53,3 @@ const WhitelistAttributes = {
55
53
  ```
56
54
 
57
55
  See [@unhead/vue](https://github.com/unjs/unhead/blob/main/packages/vue/src/types/safeSchema.ts) for more detailed types.
58
-
59
- ## Parameters
60
-
61
- `input`: A `MaybeComputedRef<HeadSafe>` object containing head data. You can pass all the same values as [`useHead`](/docs/4.x/api/composables/use-head), but only safe attributes will be rendered.
62
-
63
- ## Return Values
64
-
65
- This composable does not return any value.
66
-
67
- ## Example
68
-
69
- ```vue [app/pages/user-profile.vue]
70
- <script setup lang="ts">
71
- // User-generated content that might contain malicious code
72
- const userBio = ref('<script>alert("xss")</script>')
73
-
74
- useHeadSafe({
75
- title: `User Profile`,
76
- meta: [
77
- {
78
- name: 'description',
79
- content: userBio.value, // Safely sanitized
80
- },
81
- ],
82
- })
83
- </script>
84
- ```
85
-
86
- ::read-more{to="https://unhead.unjs.io/docs/typescript/head/api/composables/use-head-safe" target="_blank"}
87
- Read more on the `Unhead` documentation.
88
- ::
@@ -8,38 +8,19 @@ links:
8
8
  size: xs
9
9
  ---
10
10
 
11
- ## Usage
11
+ The [`useHead`](/docs/4.x/api/composables/use-head) composable function allows you to manage your head tags in a programmatic and reactive way, powered by [Unhead](https://unhead.unjs.io). If the data comes from a user or other untrusted source, we recommend you check out [`useHeadSafe`](/docs/4.x/api/composables/use-head-safe).
12
12
 
13
- The `useHead` composable allows you to manage your head tags in a programmatic and reactive way, powered by [Unhead](https://unhead.unjs.io). It lets you customize the meta tags, links, scripts, and other elements in the `<head>` section of your HTML document.
14
-
15
- ```vue [app/app.vue]
16
- <script setup lang="ts">
17
- useHead({
18
- title: 'My App',
19
- meta: [
20
- { name: 'description', content: 'My amazing site.' }
21
- ],
22
- bodyAttrs: {
23
- class: 'test'
24
- },
25
- script: [{ innerHTML: 'console.log(\'Hello world\')' }]
26
- })
27
- </script>
28
- ```
29
-
30
- ::warning
31
- If the data comes from a user or other untrusted source, we recommend you check out [`useHeadSafe`](/docs/4.x/api/composables/use-head-safe).
32
- ::
33
-
34
- ::note
35
- The properties of `useHead` can be dynamic, accepting `ref`, `computed` and `reactive` properties. The `meta` parameter can also accept a function returning an object to make the entire object reactive.
36
- ::
13
+ :read-more{to="/docs/4.x/getting-started/seo-meta"}
37
14
 
38
15
  ## Type
39
16
 
40
17
  ```ts [Signature]
41
18
  export function useHead (meta: MaybeComputedRef<MetaObject>): void
19
+ ```
42
20
 
21
+ Below are the non-reactive types for [`useHead`](/docs/4.x/api/composables/use-head) .
22
+
23
+ ```ts
43
24
  interface MetaObject {
44
25
  title?: string
45
26
  titleTemplate?: string | ((title?: string) => string)
@@ -54,116 +35,35 @@ interface MetaObject {
54
35
  }
55
36
  ```
56
37
 
57
- See [@unhead/schema](https://github.com/unjs/unhead/blob/main/packages/vue/src/types/schema.ts) for more detailed types.
58
-
59
- ## Parameters
60
-
61
- `meta`: An object accepting head metadata properties to customize the page's `<head>` section. All properties support reactive values (`ref`, `computed`, `reactive`) or can be a function returning the metadata object.
62
-
63
- | Property | Type | Description |
64
- | --- | --- | --- |
65
- | `title` | `string` | Sets the page title. |
66
- | `titleTemplate` | `string \| ((title?: string) => string)` | Configures a dynamic template to customize the page title. Can be a string with `%s` placeholder or a function. |
67
- | `base` | `Base` | Sets the `<base>` tag for the document. |
68
- | `link` | `Link[]` | Array of link objects. Each element is mapped to a `<link>` tag, where object properties correspond to HTML attributes. |
69
- | `meta` | `Meta[]` | Array of meta objects. Each element is mapped to a `<meta>` tag, where object properties correspond to HTML attributes. |
70
- | `style` | `Style[]` | Array of style objects. Each element is mapped to a `<style>` tag, where object properties correspond to HTML attributes. |
71
- | `script` | `Script[]` | Array of script objects. Each element is mapped to a `<script>` tag, where object properties correspond to HTML attributes. |
72
- | `noscript` | `Noscript[]` | Array of noscript objects. Each element is mapped to a `<noscript>` tag, where object properties correspond to HTML attributes. |
73
- | `htmlAttrs` | `HtmlAttributes` | Sets attributes of the `<html>` tag. Each object property is mapped to the corresponding attribute. |
74
- | `bodyAttrs` | `BodyAttributes` | Sets attributes of the `<body>` tag. Each object property is mapped to the corresponding attribute. |
75
-
76
- ## Return Values
77
-
78
- This composable does not return any value. It registers the head metadata with Unhead, which manages the actual DOM updates.
79
-
80
- ## Examples
81
-
82
- ### Basic Meta Tags
83
-
84
- ```vue [app/pages/about.vue]
85
- <script setup lang="ts">
86
- useHead({
87
- title: 'About Us',
88
- meta: [
89
- { name: 'description', content: 'Learn more about our company' },
90
- { property: 'og:title', content: 'About Us' },
91
- { property: 'og:description', content: 'Learn more about our company' }
92
- ]
93
- })
94
- </script>
95
- ```
96
-
97
- ### Reactive Meta Tags
98
-
99
- ```vue [app/pages/profile.vue]
100
- <script setup lang="ts">
101
- const profile = ref({ name: 'John Doe' })
102
-
103
- useHead({
104
- title: computed(() => profile.value.name),
105
- meta: [
106
- {
107
- name: 'description',
108
- content: computed(() => `Profile page for ${profile.value.name}`)
109
- }
110
- ]
111
- })
112
- </script>
113
- ```
114
-
115
- ### Using a Function for Full Reactivity
116
-
117
- ```vue [app/pages/dynamic.vue]
118
- <script setup lang="ts">
119
- const count = ref(0)
120
-
121
- useHead(() => ({
122
- title: `Count: ${count.value}`,
123
- meta: [
124
- { name: 'description', content: `Current count is ${count.value}` }
125
- ]
126
- }))
127
- </script>
128
- ```
129
-
130
- ### Adding External Scripts and Styles
131
-
132
- ```vue [app/pages/external.vue]
133
- <script setup lang="ts">
134
- useHead({
135
- link: [
136
- {
137
- rel: 'stylesheet',
138
- href: 'https://cdn.example.com/styles.css'
139
- }
140
- ],
141
- script: [
142
- {
143
- src: 'https://cdn.example.com/script.js',
144
- async: true
145
- }
146
- ]
147
- })
148
- </script>
149
- ```
150
-
151
- ### Body and HTML Attributes
152
-
153
- ```vue [app/pages/themed.vue]
154
- <script setup lang="ts">
155
- const isDark = ref(true)
38
+ See [@unhead/vue](https://github.com/unjs/unhead/blob/main/packages/vue/src/types/schema.ts) for more detailed types.
156
39
 
157
- useHead({
158
- htmlAttrs: {
159
- lang: 'en',
160
- class: computed(() => isDark.value ? 'dark' : 'light')
161
- },
162
- bodyAttrs: {
163
- class: 'themed-page'
164
- }
165
- })
166
- </script>
167
- ```
40
+ ::note
41
+ The properties of `useHead` can be dynamic, accepting `ref`, `computed` and `reactive` properties. `meta` parameter can also accept a function returning an object to make the entire object reactive.
42
+ ::
168
43
 
169
- :read-more{to="/docs/4.x/getting-started/seo-meta"}
44
+ ## Params
45
+
46
+ ### `meta`
47
+
48
+ **Type**: `MetaObject`
49
+
50
+ An object accepting the following head metadata:
51
+
52
+ - `meta`: Each element in the array is mapped to a newly-created `<meta>` tag, where object properties are mapped to the corresponding attributes.
53
+ - **Type**: `Array<Record<string, any>>`
54
+ - `link`: Each element in the array is mapped to a newly-created `<link>` tag, where object properties are mapped to the corresponding attributes.
55
+ - **Type**: `Array<Record<string, any>>`
56
+ - `style`: Each element in the array is mapped to a newly-created `<style>` tag, where object properties are mapped to the corresponding attributes.
57
+ - **Type**: `Array<Record<string, any>>`
58
+ - `script`: Each element in the array is mapped to a newly-created `<script>` tag, where object properties are mapped to the corresponding attributes.
59
+ - **Type**: `Array<Record<string, any>>`
60
+ - `noscript`: Each element in the array is mapped to a newly-created `<noscript>` tag, where object properties are mapped to the corresponding attributes.
61
+ - **Type**: `Array<Record<string, any>>`
62
+ - `titleTemplate`: Configures dynamic template to customize the page title on an individual page.
63
+ - **Type**: `string` | `((title: string) => string)`
64
+ - `title`: Sets static page title on an individual page.
65
+ - **Type**: `string`
66
+ - `bodyAttrs`: Sets attributes of the `<body>` tag. Each object property is mapped to the corresponding attribute.
67
+ - **Type**: `Record<string, any>`
68
+ - `htmlAttrs`: Sets attributes of the `<html>` tag. Each object property is mapped to the corresponding attribute.
69
+ - **Type**: `Record<string, any>`
@@ -8,8 +8,6 @@ links:
8
8
  size: xs
9
9
  ---
10
10
 
11
- `useHydration` is a built-in composable that provides a way to set data on the server side every time a new HTTP request is made and receive that data on the client side. This way `useHydration` allows you to take full control of the hydration cycle.
12
-
13
11
  ::note
14
12
  This is an advanced composable, primarily designed for use within plugins, mostly used by Nuxt modules.
15
13
  ::
@@ -18,23 +16,13 @@ This is an advanced composable, primarily designed for use within plugins, mostl
18
16
  `useHydration` is designed to **ensure state synchronization and restoration during SSR**. If you need to create a globally reactive state that is SSR-friendly in Nuxt, [`useState`](/docs/4.x/api/composables/use-state) is the recommended choice.
19
17
  ::
20
18
 
21
- ## Usage
19
+ `useHydration` is a built-in composable that provides a way to set data on the server side every time a new HTTP request is made and receive that data on the client side. This way `useHydration` allows you to take full control of the hydration cycle.
22
20
 
23
21
  The data returned from the `get` function on the server is stored in `nuxtApp.payload` under the unique key provided as the first parameter to `useHydration`. During hydration, this data is then retrieved on the client, preventing redundant computations or API calls.
24
22
 
25
- ::code-group
26
-
27
- ```ts [With useHydration]
28
- export default defineNuxtPlugin((nuxtApp) => {
29
- const myStore = new MyStore()
23
+ ## Usage
30
24
 
31
- useHydration(
32
- 'myStoreState',
33
- () => myStore.getState(),
34
- data => myStore.setState(data),
35
- )
36
- })
37
- ```
25
+ ::code-group
38
26
 
39
27
  ```ts [Without useHydration]
40
28
  export default defineNuxtPlugin((nuxtApp) => {
@@ -53,6 +41,18 @@ export default defineNuxtPlugin((nuxtApp) => {
53
41
  }
54
42
  })
55
43
  ```
44
+
45
+ ```ts [With useHydration]
46
+ export default defineNuxtPlugin((nuxtApp) => {
47
+ const myStore = new MyStore()
48
+
49
+ useHydration(
50
+ 'myStoreState',
51
+ () => myStore.getState(),
52
+ data => myStore.setState(data),
53
+ )
54
+ })
55
+ ```
56
56
  ::
57
57
 
58
58
  ## Type
@@ -63,12 +63,6 @@ export function useHydration<T> (key: string, get: () => T, set: (value: T) => v
63
63
 
64
64
  ## Parameters
65
65
 
66
- | Parameter | Type | Description |
67
- | --- | --- | --- |
68
- | `key` | `string` | A unique key that identifies the data in your Nuxt application. |
69
- | `get` | `() => T` | A function executed **only on the server** (called when SSR rendering is done) to set the initial value. |
70
- | `set` | `(value: T) => void` | A function executed **only on the client** (called when initial Vue instance is created) to receive the data. |
71
-
72
- ## Return Values
73
-
74
- This composable does not return any value.
66
+ - `key`: A unique key that identifies the data in your Nuxt application.
67
+ - `get`: A function executed **only on the server** (called when SSR rendering is done) to set the initial value.
68
+ - `set`: A function executed **only on the client** (called when initial vue instance is created) to receive the data.
@@ -8,62 +8,15 @@ links:
8
8
  size: xs
9
9
  ---
10
10
 
11
- `useLazyAsyncData` provides a wrapper around [`useAsyncData`](/docs/4.x/api/composables/use-async-data) that triggers navigation before the handler is resolved by setting the `lazy` option to `true`.
11
+ ## Description
12
12
 
13
- ::note
14
- By default, [`useAsyncData`](/docs/4.x/api/composables/use-async-data) blocks navigation until its async handler is resolved. `useLazyAsyncData` allows navigation to occur immediately while data fetching continues in the background.
15
- ::
16
-
17
- ## Usage
18
-
19
- ```vue [app/pages/index.vue]
20
- <script setup lang="ts">
21
- const { status, data: posts } = await useLazyAsyncData('posts', () => $fetch('/api/posts'))
22
- </script>
23
-
24
- <template>
25
- <div>
26
- <div v-if="status === 'pending'">Loading...</div>
27
- <div v-else-if="status === 'error'">Error loading posts</div>
28
- <div v-else>{{ posts }}</div>
29
- </div>
30
- </template>
31
- ```
32
-
33
- When using `useLazyAsyncData`, navigation will occur before fetching is complete. This means you must handle `pending` and `error` states directly within your component's template.
34
-
35
- ::warning
36
- `useLazyAsyncData` is a reserved function name transformed by the compiler, so you should not name your own function `useLazyAsyncData`.
37
- ::
38
-
39
- ## Type
40
-
41
- ```ts [Signature]
42
- export function useLazyAsyncData<DataT, ErrorT> (
43
- handler: (ctx?: NuxtApp) => Promise<DataT>,
44
- options?: AsyncDataOptions<DataT>
45
- ): AsyncData<DataT, ErrorT>
46
-
47
- export function useLazyAsyncData<DataT, ErrorT> (
48
- key: string,
49
- handler: (ctx?: NuxtApp) => Promise<DataT>,
50
- options?: AsyncDataOptions<DataT>
51
- ): AsyncData<DataT, ErrorT>
52
- ```
13
+ By default, [`useAsyncData`](/docs/4.x/api/composables/use-async-data) blocks navigation until its async handler is resolved. `useLazyAsyncData` provides a wrapper around [`useAsyncData`](/docs/4.x/api/composables/use-async-data) that triggers navigation before the handler is resolved by setting the `lazy` option to `true`.
53
14
 
15
+ ::note
54
16
  `useLazyAsyncData` has the same signature as [`useAsyncData`](/docs/4.x/api/composables/use-async-data).
17
+ ::
55
18
 
56
- ## Parameters
57
-
58
- `useLazyAsyncData` accepts the same parameters as [`useAsyncData`](/docs/4.x/api/composables/use-async-data), with the `lazy` option automatically set to `true`.
59
-
60
- :read-more{to="/docs/4.x/api/composables/use-async-data#parameters"}
61
-
62
- ## Return Values
63
-
64
- `useLazyAsyncData` returns the same values as [`useAsyncData`](/docs/4.x/api/composables/use-async-data).
65
-
66
- :read-more{to="/docs/4.x/api/composables/use-async-data#return-values"}
19
+ :read-more{to="/docs/4.x/api/composables/use-async-data"}
67
20
 
68
21
  ## Example
69
22
 
@@ -87,4 +40,8 @@ watch(count, (newCount) => {
87
40
  </template>
88
41
  ```
89
42
 
43
+ ::warning
44
+ `useLazyAsyncData` is a reserved function name transformed by the compiler, so you should not name your own function `useLazyAsyncData`.
45
+ ::
46
+
90
47
  :read-more{to="/docs/4.x/getting-started/data-fetching"}
@@ -8,81 +8,21 @@ links:
8
8
  size: xs
9
9
  ---
10
10
 
11
- `useLazyFetch` provides a wrapper around [`useFetch`](/docs/4.x/api/composables/use-fetch) that triggers navigation before the handler is resolved by setting the `lazy` option to `true`.
11
+ ## Description
12
12
 
13
- ## Usage
14
-
15
- By default, [`useFetch`](/docs/4.x/api/composables/use-fetch) blocks navigation until its async handler is resolved. `useLazyFetch` allows navigation to proceed immediately, with data being fetched in the background.
16
-
17
- ```vue [app/pages/index.vue]
18
- <script setup lang="ts">
19
- const { status, data: posts } = await useLazyFetch('/api/posts')
20
- </script>
21
-
22
- <template>
23
- <div v-if="status === 'pending'">
24
- Loading ...
25
- </div>
26
- <div v-else>
27
- <div v-for="post in posts">
28
- <!-- do something -->
29
- </div>
30
- </div>
31
- </template>
32
- ```
13
+ By default, [`useFetch`](/docs/4.x/api/composables/use-fetch) blocks navigation until its async handler is resolved. `useLazyFetch` provides a wrapper around [`useFetch`](/docs/4.x/api/composables/use-fetch) that triggers navigation before the handler is resolved by setting the `lazy` option to `true`.
33
14
 
34
15
  ::note
35
16
  `useLazyFetch` has the same signature as [`useFetch`](/docs/4.x/api/composables/use-fetch).
36
17
  ::
37
18
 
38
- ::warning
39
- Awaiting `useLazyFetch` only ensures the call is initialized. On client-side navigation, data may not be immediately available, and you must handle the `pending` state in your component's template.
40
- ::
41
-
42
- ::warning
43
- `useLazyFetch` is a reserved function name transformed by the compiler, so you should not name your own function `useLazyFetch`.
44
- ::
45
-
46
- ## Type
47
-
48
- ```ts [Signature]
49
- export function useLazyFetch<DataT, ErrorT> (
50
- url: string | Request | Ref<string | Request> | (() => string | Request),
51
- options?: UseFetchOptions<DataT>
52
- ): Promise<AsyncData<DataT, ErrorT>>
53
- ```
54
-
55
19
  ::note
56
- `useLazyFetch` is equivalent to `useFetch` with `lazy: true` option set. See [`useFetch`](/docs/4.x/api/composables/use-fetch) for full type definitions.
20
+ Awaiting `useLazyFetch` in this mode only ensures the call is initialized. On client-side navigation, data may not be immediately available, and you should make sure to handle the pending state in your app.
57
21
  ::
58
22
 
59
- ## Parameters
60
-
61
- `useLazyFetch` accepts the same parameters as [`useFetch`](/docs/4.x/api/composables/use-fetch):
62
-
63
- - `URL` (`string | Request | Ref<string | Request> | () => string | Request`): The URL or request to fetch.
64
- - `options` (object): Same as [`useFetch` options](/docs/4.x/api/composables/use-fetch#parameters), with `lazy` automatically set to `true`.
65
-
66
- :read-more{to="/docs/4.x/api/composables/use-fetch#parameters"}
23
+ :read-more{to="/docs/4.x/api/composables/use-fetch"}
67
24
 
68
- ## Return Values
69
-
70
- Returns the same `AsyncData` object as [`useFetch`](/docs/4.x/api/composables/use-fetch):
71
-
72
- | Name | Type | Description |
73
- | --- | --- |--- |
74
- | `data` | `Ref<DataT \| undefined>` | The result of the asynchronous fetch. |
75
- | `refresh` | `(opts?: AsyncDataExecuteOptions) => Promise<void>` | Function to manually refresh the data. |
76
- | `execute` | `(opts?: AsyncDataExecuteOptions) => Promise<void>` | Alias for `refresh`. |
77
- | `error` | `Ref<ErrorT \| undefined>` | Error object if the data fetching failed. |
78
- | `status` | `Ref<'idle' \| 'pending' \| 'success' \| 'error'>` | Status of the data request. |
79
- | `clear` | `() => void` | Resets `data` to `undefined`, `error` to `undefined`, sets `status` to `idle`, and cancels any pending requests. |
80
-
81
- :read-more{to="/docs/4.x/api/composables/use-fetch#return-values"}
82
-
83
- ## Examples
84
-
85
- ### Handling Pending State
25
+ ## Example
86
26
 
87
27
  ```vue [app/pages/index.vue]
88
28
  <script setup lang="ts">
@@ -108,4 +48,8 @@ watch(posts, (newPosts) => {
108
48
  </template>
109
49
  ```
110
50
 
51
+ ::note
52
+ `useLazyFetch` is a reserved function name transformed by the compiler, so you should not name your own function `useLazyFetch`.
53
+ ::
54
+
111
55
  :read-more{to="/docs/4.x/getting-started/data-fetching"}
@@ -8,7 +8,7 @@ links:
8
8
  size: xs
9
9
  ---
10
10
 
11
- Programmatic usage can be helpful when you want to use Nuxt programmatically, for example, when building a [CLI tool](https://github.com/nuxt/cli) or [test utils](https://github.com/nuxt/test-utils).
11
+ Programmatic usage can be helpful when you want to use Nuxt programmatically, for example, when building a [CLI tool](https://github.com/nuxt/cli) or [test utils](https://github.com/nuxt/nuxt/tree/main/packages/test-utils).
12
12
 
13
13
  ## `loadNuxt`
14
14
 
@@ -31,7 +31,7 @@ function loadNuxt (loadOptions?: LoadNuxtOptions): Promise<Nuxt>
31
31
 
32
32
  ## `buildNuxt`
33
33
 
34
- Build Nuxt programmatically. It will invoke the builder (currently [@nuxt/vite-builder](https://github.com/nuxt/nuxt/blob/main/packages/vite) or [@nuxt/webpack-builder](https://github.com/nuxt/nuxt/blob/main/packages/webpack)) to bundle the application.
34
+ Build Nuxt programmatically. It will invoke the builder (currently [@nuxt/vite-builder](https://github.com/nuxt/nuxt/tree/main/packages/vite) or [@nuxt/webpack-builder](https://github.com/nuxt/nuxt/tree/main/packages/webpack)) to bundle the application.
35
35
 
36
36
  ### Type
37
37
 
@@ -2133,7 +2133,7 @@ See [css-loader](https://github.com/webpack/css-loader) for available options.
2133
2133
  }
2134
2134
  ```
2135
2135
 
2136
- **See**: [esbuild loader](https://github.com/privatenumber/esbuild-loader)
2136
+ **See**: [esbuild loader](https://github.com/esbuild-kit/esbuild-loader)
2137
2137
 
2138
2138
  #### `file`
2139
2139
 
@@ -39,7 +39,7 @@ If your issue concerns Vue or Vite, please try to reproduce it first with the Vu
39
39
 
40
40
  ::card-group
41
41
  :card{title="Vue SSR on StackBlitz" icon="i-simple-icons-stackblitz" to="https://stackblitz.com/github/nuxt-contrib/vue3-ssr-starter/tree/main?terminal=dev" target="_blank"}
42
- :card{title="Vue SSR on CodeSandbox" icon="i-simple-icons-codesandbox" to="https://codesandbox.io/p/sandbox/github/nuxt-contrib/vue3-ssr-starter/main" target="_blank"}
42
+ :card{title="Vue SSR on CodeSandbox" icon="i-simple-icons-codesandbox" to="https://codesandbox.io/s/github/nuxt-contrib/vue3-ssr-starter/main" target="_blank"}
43
43
  :card{title="Vue SSR Template on GitHub" icon="i-simple-icons-github" to="https://github.com/nuxt-contrib/vue3-ssr-starter/generate" target="_blank"}
44
44
  ::
45
45
 
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@nuxt/docs-nightly",
3
- "version": "4.2.1-29369624.1cc53932",
3
+ "version": "4.2.1-29370805.6a102676",
4
4
  "repository": {
5
5
  "type": "git",
6
6
  "url": "git+https://github.com/nuxt/nuxt.git",