@nuxt/docs 0.0.0 → 3.17.0

package/3.api/6.advanced/1.hooks.md

@@ -0,0 +1,105 @@
+---
+title: 'Lifecycle Hooks'
+description: Nuxt provides a powerful hooking system to expand almost every aspect using hooks.
+---
+
+:read-more{to="/docs/guide/going-further/hooks"}
+
+## App Hooks (runtime)
+
+Check the [app source code](https://github.com/nuxt/nuxt/blob/main/packages/nuxt/src/app/nuxt.ts#L37) for all available hooks.
+
+Hook                   | Arguments           | Environment     | Description
+-----------------------|---------------------|-----------------|-------------
+`app:created`          | `vueApp`            | Server & Client | Called when initial `vueApp` instance is created.
+`app:error`            | `err`               | Server & Client | Called when a fatal error occurs.
+`app:error:cleared`    | `{ redirect? }`     | Server & Client | Called when a fatal error occurs.
+`vue:setup`            | -                   | Server & Client | Called when the setup of Nuxt root is initialized. This callback must be synchronous.
+`vue:error`            | `err, target, info` | Server & Client | Called when a vue error propagates to the root component. [Learn More](https://vuejs.org/api/composition-api-lifecycle.html#onerrorcaptured).
+`app:rendered`         | `renderContext`     | Server          | Called when SSR rendering is done.
+`app:redirected`       | -                   | Server          | Called before SSR redirection.
+`app:beforeMount`      | `vueApp`            | Client          | Called before mounting the app, called only on client side.
+`app:mounted`          | `vueApp`            | Client          | Called when Vue app is initialized and mounted in browser.
+`app:suspense:resolve` | `appComponent`      | Client          | On [Suspense](https://vuejs.org/guide/built-ins/suspense.html#suspense) resolved event.
+`app:manifest:update`  | `{ id, timestamp }` | Client          | Called when there is a newer version of your app detected.
+`app:data:refresh`     | `keys?`             | Client          | Called when `refreshNuxtData` is called.
+`link:prefetch`        | `to`                | Client          | Called when a `<NuxtLink>` is observed to be prefetched.
+`page:start`           | `pageComponent?`    | Client          | Called on [Suspense](https://vuejs.org/guide/built-ins/suspense.html#suspense) inside of `NuxtPage` pending event.
+`page:finish`          | `pageComponent?`    | Client          | Called on [Suspense](https://vuejs.org/guide/built-ins/suspense.html#suspense) inside of `NuxtPage` resolved event.
+`page:loading:start`   | -                   | Client          | Called when the `setup()` of the new page is running.
+`page:loading:end`     | -                   | Client          | Called after `page:finish`
+`page:transition:finish`| `pageComponent?`    | Client          | After page transition [onAfterLeave](https://vuejs.org/guide/built-ins/transition.html#javascript-hooks) event.
+`dev:ssr-logs`         | `logs`              | Client          | Called with an array of server-side logs that have been passed to the client (if `features.devLogs` is enabled).
+`page:view-transition:start` | `transition`        | Client          | Called after `document.startViewTransition` is called when [experimental viewTransition support is enabled](/docs/getting-started/transitions#view-transitions-api-experimental).
+
+## Nuxt Hooks (build time)
+
+Check the [schema source code](https://github.com/nuxt/nuxt/blob/main/packages/schema/src/types/hooks.ts#L83) for all available hooks.
+
+Hook                     | Arguments                  | Description
+-------------------------|----------------------------|-------------
+`kit:compatibility`      | `compatibility, issues`    | Allows extending compatibility checks.
+`ready`                  | `nuxt`                     | Called after Nuxt initialization, when the Nuxt instance is ready to work.
+`close`                  | `nuxt`                     | Called when Nuxt instance is gracefully closing.
+`restart`                | `{ hard?: boolean }`       | To be called to restart the current Nuxt instance.
+`modules:before`         | -                          | Called during Nuxt initialization, before installing user modules.
+`modules:done`           | -                          | Called during Nuxt initialization, after installing user modules.
+`app:resolve`            | `app`                      | Called after resolving the `app` instance.
+`app:templates`          | `app`                      | Called during `NuxtApp` generation, to allow customizing, modifying or adding new files to the build directory (either virtually or to written to `.nuxt`).
+`app:templatesGenerated` | `app`                      | Called after templates are compiled into the [virtual file system](/docs/guide/directory-structure/nuxt#virtual-file-system) (vfs).
+`build:before`           | -                          | Called before Nuxt bundle builder.
+`build:done`             | -                          | Called after Nuxt bundle builder is complete.
+`build:manifest`         | `manifest`                 | Called during the manifest build by Vite and webpack. This allows customizing the manifest that Nitro will use to render `<script>` and `<link>` tags in the final HTML.
+`builder:generateApp`    | `options`                  | Called before generating the app.
+`builder:watch`          | `event, path`              | Called at build time in development when the watcher spots a change to a file or directory in the project.
+`pages:extend`           | `pages`                    | Called after page routes are scanned from the file system.
+`pages:resolved`         | `pages`                    | Called after page routes have been augmented with scanned metadata.
+`pages:routerOptions`   | `{ files: Array<{ path: string, optional?: boolean }> }` | Called when resolving `router.options` files. Later items in the array override earlier ones.
+`server:devHandler`      | `handler`                  | Called when the dev middleware is being registered on the Nitro dev server.
+`imports:sources`        | `presets`                  | Called at setup allowing modules to extend sources.
+`imports:extend`         | `imports`                  | Called at setup allowing modules to extend imports.
+`imports:context`        | `context`                  | Called when the [unimport](https://github.com/unjs/unimport) context is created.
+`imports:dirs`           | `dirs`                     | Allows extending import directories.
+`components:dirs`        | `dirs`                     | Called within `app:resolve` allowing to extend the directories that are scanned for auto-importable components.
+`components:extend`      | `components`               | Allows extending new components.
+`nitro:config`           | `nitroConfig`              | Called before initializing Nitro, allowing customization of Nitro's configuration.
+`nitro:init`             | `nitro`                    | Called after Nitro is initialized, which allows registering Nitro hooks and interacting directly with Nitro.
+`nitro:build:before`     | `nitro`                    | Called before building the Nitro instance.
+`nitro:build:public-assets`     | `nitro`                    | Called after copying public assets. Allows modifying public assets before Nitro server is built.
+`prerender:routes`       | `ctx`                      | Allows extending the routes to be pre-rendered.
+`build:error`            | `error`                    | Called when an error occurs at build time.
+`prepare:types`          | `options`                  | Called before Nuxi writes `.nuxt/tsconfig.json` and `.nuxt/nuxt.d.ts`, allowing addition of custom references and declarations in `nuxt.d.ts`, or directly modifying the options in `tsconfig.json`
+`listen`                 | `listenerServer, listener` | Called when the dev server is loading.
+`schema:extend`          | `schemas`                  | Allows extending default schemas.
+`schema:resolved`        | `schema`                   | Allows extending resolved schema.
+`schema:beforeWrite`     | `schema`                   | Called before writing the given schema.
+`schema:written`         | -                          | Called after the schema is written.
+`vite:extend`            | `viteBuildContext`         | Allows to extend Vite default context.
+`vite:extendConfig`      | `viteInlineConfig, env`    | Allows to extend Vite default config.
+`vite:configResolved`    | `viteInlineConfig, env`    | Allows to read the resolved Vite config.
+`vite:serverCreated`     | `viteServer, env`          | Called when the Vite server is created.
+`vite:compiled`          | -                          | Called after Vite server is compiled.
+`webpack:config`         | `webpackConfigs`           | Called before configuring the webpack compiler.
+`webpack:configResolved` | `webpackConfigs`           | Allows to read the resolved webpack config.
+`webpack:compile`        | `options`                  | Called right before compilation.
+`webpack:compiled`       | `options`                  | Called after resources are loaded.
+`webpack:change`         | `shortPath`                | Called on `change` on WebpackBar.
+`webpack:error`          | -                          | Called on `done` if has errors on WebpackBar.
+`webpack:done`           | -                          | Called on `allDone` on WebpackBar.
+`webpack:progress`       | `statesArray`              | Called on `progress` on WebpackBar.
+
+## Nitro App Hooks (runtime, server-side)
+
+See [Nitro](https://nitro.unjs.io/guide/plugins#available-hooks) for all available hooks.
+
+Hook                   | Arguments             | Description                          | Types
+-----------------------|-----------------------|--------------------------------------|------------------
+`dev:ssr-logs`         | `{ path, logs }`      | Server                               | Called at the end of a request cycle with an array of server-side logs.
+`render:response`      | `response, { event }` | Called before sending the response.  | [response](https://github.com/nuxt/nuxt/blob/71ef8bd3ff207fd51c2ca18d5a8c7140476780c7/packages/nuxt/src/core/runtime/nitro/renderer.ts#L24), [event](https://github.com/unjs/h3/blob/f6ceb5581043dc4d8b6eab91e9be4531e0c30f8e/src/types.ts#L38)
+`render:html`          | `html, { event }`     | Called before constructing the HTML. | [html](https://github.com/nuxt/nuxt/blob/71ef8bd3ff207fd51c2ca18d5a8c7140476780c7/packages/nuxt/src/core/runtime/nitro/renderer.ts#L15), [event](https://github.com/unjs/h3/blob/f6ceb5581043dc4d8b6eab91e9be4531e0c30f8e/src/types.ts#L38)
+`render:island`        | `islandResponse, { event, islandContext }` | Called before constructing the island HTML. | [islandResponse](https://github.com/nuxt/nuxt/blob/e50cabfed1984c341af0d0c056a325a8aec26980/packages/nuxt/src/core/runtime/nitro/renderer.ts#L28), [event](https://github.com/unjs/h3/blob/f6ceb5581043dc4d8b6eab91e9be4531e0c30f8e/src/types.ts#L38), [islandContext](https://github.com/nuxt/nuxt/blob/e50cabfed1984c341af0d0c056a325a8aec26980/packages/nuxt/src/core/runtime/nitro/renderer.ts#L38)
+`close`               | -                | Called when Nitro is closed. | -
+`error`               | `error, { event? }`          | Called when an error occurs. | [error](https://github.com/nitrojs/nitro/blob/d20ffcbd16fc4003b774445e1a01e698c2bb078a/src/types/runtime/nitro.ts#L48), [event](https://github.com/unjs/h3/blob/f6ceb5581043dc4d8b6eab91e9be4531e0c30f8e/src/types.ts#L38)
+`request`             | `event`        | Called when a request is received. | [event](https://github.com/unjs/h3/blob/f6ceb5581043dc4d8b6eab91e9be4531e0c30f8e/src/types.ts#L38)
+`beforeResponse`      | `event, { body }`        | Called before sending the response. | [event](https://github.com/unjs/h3/blob/f6ceb5581043dc4d8b6eab91e9be4531e0c30f8e/src/types.ts#L38), unknown
+`afterResponse`       | `event, { body }`        | Called after sending the response. | [event](https://github.com/unjs/h3/blob/f6ceb5581043dc4d8b6eab91e9be4531e0c30f8e/src/types.ts#L38), unknown

package/3.api/6.advanced/2.import-meta.md

@@ -0,0 +1,60 @@
+---
+title: 'Import meta'
+description: Understand where your code is running using `import.meta`.
+---
+
+## The `import.meta` object
+
+With ES modules you can obtain some metadata from the code that imports or compiles your ES-module.
+This is done through `import.meta`, which is an object that provides your code with this information.
+Throughout the Nuxt documentation you may see snippets that use this already to figure out whether the
+code is currently running on the client or server side.
+
+::read-more{to="https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/import.meta"}
+Read more about `import.meta`.
+::
+
+## Runtime (App) Properties
+
+These values are statically injected and can be used for tree-shaking your runtime code.
+
+Property | Type | Description
+--- | --- | ---
+`import.meta.client` | boolean | True when evaluated on the client side.
+`import.meta.browser` | boolean | True when evaluated on the client side.
+`import.meta.server` | boolean | True when evaluated on the server side.
+`import.meta.nitro` | boolean | True when evaluated on the server side.
+`import.meta.dev` | boolean | True when running the Nuxt dev server.
+`import.meta.test` | boolean | True when running in a test context.
+`import.meta.prerender` | boolean | True when rendering HTML on the server in the prerender stage of your build.
+
+## Builder Properties
+
+These values are available both in modules and in your `nuxt.config`.
+
+Property | Type | Description
+--- | --- | ---
+`import.meta.env` | object | Equals `process.env`
+`import.meta.url` | string | Resolvable path for the current file.
+
+## Examples
+
+### Using `import.meta.url` to resolve files within modules
+
+```ts [modules/my-module/index.ts]
+import { createResolver } from 'nuxt/kit'
+
+// Resolve relative from the current file
+const resolver = createResolver(import.meta.url)
+
+export default defineNuxtModule({
+  meta: { name: 'myModule' },
+  setup() {
+    addComponent({
+      name: 'MyModuleComponent',
+      // Resolves to '/modules/my-module/components/MyModuleComponent.vue'
+      filePath: resolver.resolve('./components/MyModuleComponent.vue')
+    })
+  }
+})
+```

package/3.api/6.nuxt-config.md

@@ -0,0 +1,12 @@
+---
+title: Nuxt Configuration
+titleTemplate: '%s'
+description: Discover all the options you can use in your nuxt.config.ts file.
+navigation.icon: i-lucide-cog
+---
+
+::note{icon="i-simple-icons-github" to="https://github.com/nuxt/nuxt/tree/main/packages/schema/src/config" target="_blank"}
+This file is auto-generated from Nuxt source code.
+::
+
+<!-- GENERATED_CONFIG_DOCS -->

package/3.api/index.md

@@ -0,0 +1,31 @@
+---
+title: 'Nuxt API Reference'
+titleTemplate: '%s'
+description: 'Explore all Nuxt Internals: Components, Composables, Utils, Commands and more.'
+navigation: false
+surround: false
+---
+
+::card-group
+  ::card{icon="i-lucide-box" title="Components" to="/docs/api/components/client-only"}
+  Explore Nuxt built-in components for pages, layouts, head, and more.
+  ::
+  ::card{icon="i-lucide-arrow-left-right" title="Composables" to="/docs/api/composables/use-app-config"}
+  Discover Nuxt composable functions for data-fetching, head management and more.
+  ::
+  ::card{icon="i-lucide-square-function" title="Utils" to="/docs/api/utils/dollarfetch"}
+  Learn about Nuxt utility functions for navigation, error handling and more.
+  ::
+  ::card{icon="i-lucide-square-terminal" title="Commands" to="/docs/api/commands/add"}
+  List of Nuxt CLI commands to init, analyze, build, and preview your application.
+  ::
+  ::card{icon="i-lucide-package" title="Nuxt Kit" to="/docs/api/kit/modules"}
+  Understand Nuxt Kit utilities to create modules and control Nuxt.
+  ::
+  ::card{icon="i-lucide-brain" title="Advanced" to="/docs/api/advanced/hooks"}
+  Go deep in Nuxt internals with Nuxt lifecycle hooks.
+  ::
+  ::card{icon="i-lucide-cog" title="Nuxt Configuration" to="/docs/api/nuxt-config"}
+  Explore all Nuxt configuration options to customize your application.
+  ::
+::

package/5.community/.navigation.yml

@@ -0,0 +1,3 @@
+title: 'Community'
+titleTemplate: '%s · Nuxt Community'
+icon: i-lucide-messages-square

package/5.community/2.getting-help.md

@@ -0,0 +1,48 @@
+---
+title: Getting Help
+description: We're a friendly community of developers and we'd love to help.
+navigation:
+  icon: i-lucide-life-buoy
+---
+
+At some point, you may find that there's an issue you need some help with.
+
+But don't worry! We're a friendly community of developers and we'd love to help.
+
+::card-group
+  ::card{icon="i-simple-icons-discord" title="Discord" to="https://go.nuxt.com/discord" target="_blank"}
+  Get real-time help, exchange with the core team and the community, and stay updated on the latest Nuxt news.
+  ::
+  ::card{icon="i-simple-icons-nuxt" title="Nuxters" to="https://nuxters.nuxt.com" target="_blank"}
+  Connect with other Nuxt enthusiasts.
+  ::
+::
+
+## "I can't figure out how to (...)."
+
+You've read through these docs and you think it should be possible, but it's not clear how. The best thing is to [open a GitHub Discussion](https://github.com/nuxt/nuxt/discussions).
+
+Please don't feel embarrassed about asking a question that you think is easy - we've all been there! ❤️
+
+Everyone you'll encounter is helping out because they care, not because they are paid to do so. The kindest thing to do is make it easy for them to help you. Here are some ideas:
+
+- _Explain what your objective is, not just the problem you're facing._ "I need to ensure my form inputs are accessible, so I'm trying to get the ids to match between server and client."
+- _Make sure you've first read the docs and used your favorite search engine_. Let people know by saying something like "I've Googled for 'nuxt script setup' but I couldn't find code examples anywhere."
+- _Explain what you've tried._ Tell people the kind of solutions you've experimented with, and why. Often this can make people's advice more relevant to your situation.
+- _Share your code._ People probably won't be able to help if they just see an error message or a screenshot - but that all changes if you share your code in a copy/pasteable format - preferably in the form of a minimal reproduction like a CodeSandbox.
+
+And finally, just ask the question! There's no need to [ask permission to ask a question](https://dontasktoask.com) or [wait for someone to reply to your 'hello'](https://www.nohello.com). If you do, you might not get a response because people are waiting for the whole question before engaging.
+
+## "Could there be a bug?"
+
+Something isn't working the way that the docs say that it should. You're not sure if it's a bug. You've searched through the [open issues](https://github.com/nuxt/nuxt/issues) and [discussions](https://github.com/nuxt/nuxt/discussions) but you can't find anything. (if there is a closed issue, please create a new one)
+
+We recommend taking a look at [how to report bugs](/docs/community/reporting-bugs). Nuxt is still in active development, and every issue helps make it better.
+
+## "I need professional help"
+
+If the community couldn't provide the help you need in the time-frame you have, NuxtLabs offers professional support with the [Nuxt Experts](https://nuxt.com/enterprise/support).
+
+The objective of the Nuxt Expert is to provide support to the Vue ecosystem, while also creating freelance opportunities for those contributing to open-source solutions, thus helping to maintain the sustainability of the ecosystem.
+
+The Nuxt experts are Vue, Nuxt and Vite chosen contributors providing professional support and consulting services.

package/5.community/3.reporting-bugs.md

@@ -0,0 +1,50 @@
+---
+title: 'Reporting Bugs'
+description: 'One of the most valuable roles in open source is taking the time to report bugs helpfully.'
+navigation.icon: i-lucide-bug
+---
+
+Try as we might, we will never completely eliminate bugs.
+
+Even if you can't fix the underlying code, reporting a bug well can enable someone else with a bit more familiarity with the codebase to spot a pattern or make a quick fix.
+
+Here are a few key steps.
+
+## Is It Really a Bug?
+
+Consider if you're looking to get help with something, or whether you think there's a bug with Nuxt itself. If it's the former, we'd love to help you - but the best way to do that is through [asking for help](/docs/community/getting-help) rather than reporting a bug.
+
+## Search the Issues
+
+Search through the [open issues](https://github.com/nuxt/nuxt/issues) and [discussions](https://github.com/nuxt/nuxt/discussions) first. If you find anything that seems like the same bug, it's much better to comment on an existing thread than create a duplicate.
+
+## Create a Minimal Reproduction
+
+It's important to be able to reproduce the bug reliably - in a minimal way and apart from the rest of your project. This narrows down what could be causing the issue and makes it possible for someone not only to find the cause, but also to test a potential solution.
+
+Start with the Nuxt sandbox and add the **minimum** amount of code necessary to reproduce the bug you're experiencing.
+
+::note
+If your issue concerns Vue or Vite, please try to reproduce it first with the Vue SSR starter.
+::
+
+**Nuxt**:
+
+::card-group
+  :card{title="Nuxt on StackBlitz" icon="i-simple-icons-stackblitz" to="https://nuxt.new/s/v3" target="_blank"}
+  :card{title="Nuxt on CodeSandbox" icon="i-simple-icons-codesandbox" to="https://nuxt.new/c/v3" target="_blank"}
+::
+
+**Vue**:
+
+::card-group
+  :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"}
+  :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"}
+  :card{title="Vue SSR Template on GitHub" icon="i-simple-icons-github" to="https://github.com/nuxt-contrib/vue3-ssr-starter/generate" target="_blank"}
+::
+
+Once you've reproduced the issue, remove as much code from your reproduction as you can (while still recreating the bug). The time spent making the reproduction as minimal as possible will make a huge difference to whoever sets out to fix the issue.
+
+## Figure Out What the Cause Might Be
+
+With a Nuxt project, there are lots of moving pieces - from [Nuxt modules](/modules) to [other JavaScript libraries](https://www.npmjs.com). Try to report the bug at the most relevant and specific place. That will likely be the Nuxt module causing an issue, or the upstream library that Nuxt is depending on.

package/5.community/4.contribution.md

@@ -0,0 +1,205 @@
+---
+title: 'Contribution'
+description: 'Nuxt is a community project - and so we love contributions of all kinds! ❤️'
+navigation.icon: i-lucide-git-pull-request
+---
+
+There is a range of different ways you might be able to contribute to the Nuxt ecosystem.
+
+## Ecosystem
+
+The Nuxt ecosystem includes many different projects and organizations:
+
+* [nuxt/](https://github.com/nuxt) - core repositories for the Nuxt framework itself. [**nuxt/nuxt**](https://github.com/nuxt/nuxt) contains the Nuxt framework (both versions 2 and 3).
+* [nuxt-modules/](https://github.com/nuxt-modules) - community-contributed and maintained modules and libraries. There is a [process to migrate a module](/docs/guide/going-further/modules/#joining-nuxt-modules-and-nuxtjs) to `nuxt-modules`. While these modules have individual maintainers, they are not dependent on a single person.
+* [unjs/](https://github.com/unjs) - many of these libraries are used throughout the Nuxt ecosystem. They are designed to be universal libraries that are framework- and environment-agnostic. We welcome contributions and usage by other frameworks and projects.
+
+## How To Contribute
+
+### Triage Issues and Help Out in Discussions
+
+Check out the issues and discussions for the project you want to help. For example, here are [the issues board](https://github.com/nuxt/nuxt/issues) and [discussions](https://github.com/nuxt/nuxt/discussions) for Nuxt. Helping other users, sharing workarounds, creating reproductions, or even poking into a bug a little bit and sharing your findings makes a huge difference.
+
+### Creating an Issue
+
+Thank you for taking the time to create an issue! ❤️
+
+* **Reporting bugs**: Check out [our guide](/docs/community/reporting-bugs) for some things to do before opening an issue.
+
+* **Feature requests**: Check that there is not an existing issue or discussion covering the scope of the feature you have in mind. If the feature is to another part of the Nuxt ecosystem (such as a module), please consider raising a feature request there first. If the feature you have in mind is general or the API is not entirely clear, consider opening a discussion in the **Ideas** section to discuss with the community first.
+
+We'll do our best to follow our [internal issue decision making flowchart](https://mermaid.live/view#pako:eNqFlE1v2zAMhv8K4UuToslhx2Bo0TZt12Edhm7YMCAXWqJtorLk6qOpkfS_j7KdfpyWQ-BQr8mHL6nsCuU0FauiMm6rGvQRfq03FuRzvvvTYIQHthpcBT_ugQNwPHuZjheLxf4i1VDx8x4udrf5EBCOQvSsYg4ffS79KS9pmX9QALTgyid2KYB7Ih-4bmKWbDk2YB0E1gRUVaRi-FDmmjAmT3u4nB3DmoNKIUA1BsGSohA49jnVMQhHbDh_EZQUImyxh-gAtfaiG-KWSJ-N8nt6YtpCdgEeE5rXPOdav5YwWJIJU7zrvNADV9C7JBIyIC07Wxupkx3LFQ5vCkguRno5f9fP2qnUko0Y2dk9rGdvHAa9IIhVGlCp5FFNPN-ce4DKeXBd53xMliOLp9IZtyORQVsnrGm-WJzejtUu5fFqdr5FGQ3bLslYvGthjZbJTLpReZG5_lLYw7XQ_CbPVT92ws9gnEJj-v84dk-PiaXnmF1XGAaPsOsMKywNvYmG80ZohV8k4wDR9_N3KN_dHm5mh1lnkM5FsYzRfNiTvJoT5gnQsl6uxjqXLhkNQ9syHJ0UZZ8ERUIlNShr6N8gZDEliR-ow7QZa0fhY4LoHLRo-8N7ZxPwjRj5ZZYXpvOSNs9v3Jjs8NXB4ets92xan3zydXZHvj64lKMayh4-gZC1bjASW2ipLeWuzIuToiXfImu5rbucclMIc0ubYiWPGv3DptjYF9Fhiu5nb1Wxij7RSZE6jZHWjLXHtlhVaIJESXN0_m68_sO_wMs_oO9gyg) when responding to issues.
+
+### Send a Pull Request
+
+We always welcome pull requests! ❤️
+
+#### Before You Start
+
+Before you fix a bug, we recommend that you check whether **there's an issue that describes it**, as it's possible it's a documentation issue or that there is some context that would be helpful to know.
+
+If you're working on a feature, then we ask that you **open a feature request issue first** to discuss with the maintainers whether the feature is desired - and the design of those features. This helps save time for both the maintainers and the contributors and means that features can be shipped faster. The issue **should be confirmed** by a framework team member before building out a feature in a pull request.
+
+For typo fixes, it's recommended to batch multiple typo fixes into one pull request to maintain a cleaner commit history.
+
+For bigger changes to Nuxt itself, we recommend that you first [create a Nuxt module](#create-a-module) and implement the feature there. This allows for quick proof-of-concept. You can then [create an RFC](#make-an-rfc) in the form of a discussion. As users adopt it and you gather feedback, it can then be refined and either added to Nuxt core or continue as a standalone module.
+
+#### Commit Conventions
+
+We use [Conventional Commits](https://www.conventionalcommits.org) for commit messages, which [allows a changelog to be auto-generated](https://github.com/unjs/changelogen) based on the commits. Please read the guide through if you aren't familiar with it already.
+
+Note that `fix:` and `feat:` are for **actual code changes** (that might affect logic). For typo or document changes, use `docs:` or `chore:` instead:
+
+* ~~`fix: typo`~~ -> `docs: fix typo`
+
+If you are working in a project with a monorepo, like `nuxt/nuxt`, ensure that you specify the main scope of your commit in brackets. For example: `feat(nuxi): add 'do-magic' command`.
+
+#### Making the Pull Request
+
+If you don't know how to send a pull request, we recommend reading [the guide](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/creating-a-pull-request).
+
+When sending a pull request, make sure your PR's title also follows the [Commit Convention](#commit-conventions).
+
+If your PR fixes or resolves existing issues, please make sure you mention them in the PR description.
+
+It's ok to have multiple commits in a single PR; you don't need to rebase or force push for your changes as we will use `Squash and Merge` to squash the commits into one commit when merging.
+
+We do not add any commit hooks to allow for quick commits. But before you make a pull request, you should ensure that any lint/test scripts are passing.
+
+In general, please also make sure that there are no _unrelated_ changes in a PR. For example, if your editor has made any changes to whitespace or formatting elsewhere in a file that you edited, please revert these so it is more obvious what your PR changes. And please avoid including multiple unrelated features or fixes in a single PR. If it is possible to separate them, it is better to have multiple PRs to review and merge separately. In general, a PR should do _one thing only_.
+
+#### Once You've Made a Pull Request
+
+Once you've made a pull request, we'll do our best to review it promptly.
+
+If we assign it to a maintainer, then that means that person will take special care to review it and implement any changes that may be required.
+
+If we request changes on a PR, please ignore the red text! It doesn't mean we think it's a bad PR - it's just a way of easily telling the status of a list of pull requests at a glance.
+
+If we mark a PR as 'pending', that means we likely have another task to do in reviewing the PR - it's an internal note-to-self, and not necessarily a reflection on whether the PR is a good idea or not. We will do our best to explain via a comment the reason for the pending status.
+
+We'll do our best to follow [our PR decision making flowchart](https://mermaid.live/view#pako:eNp9VE1v2kAQ_SsjXzBSEqlALlaUisSh0ACK2l4qcVm8Y9hi7672Iwly-O-ZtYPt5FAOCHbee_PmzdpVlCmOURLlhXrJ9sw4-JNuJNBnWs1UQafIQVjrERyWumAOv58-AJeXt29_0b7BXbWwwL0uRPa1vlZvcB_fF8oiMMmB2QM4BXkt3UoON7Lh3LWaDz2SVkK6QGt7DHvw0CKt5sxCKaQoWQEGtVHcZ04oGdw04LTVngW_LHOeFcURGGz97mw6PSv-iJdsi0UCA4nI7SfNwc3W3JZit3eQ1SZFDlKB15yswQ2MgbOjbYeatY3n8bcr-IWlekYYaJRcyB04I9gOB1CEfkF5dAVTzmFAtnqn4-bUYAiMMmHZgWhNPRhgus5mW2BATxq0NkIZ4Y4NbNjzE2ZchBzcHmGLe_ZMSKCcyRXyLrVFa_5n_PBK2xKy3kk9eOjULUdltk6C8kI-7NFDr8f4EVGDoqlp-wa4sJm3ltIMIuZ_mTQXJyTSkQZtunPqsKxShV9GKdkBYe1fHXjpbcjlvONlO9Kqx_M7YHmOmav_luxfE5zKwVs09hM5DLSupgYDlr5flDkwo7ykixKG-xDsUly1LZ-uY32dgDc7lG7YqwbNp0msJwmIUivjWFtfd-xRrEcJ7Omydz37qFplHOtxEp4GskI2qB5dRCWakglOz3oV8JuITJa4iRL6yZk5bKKNPBGOead-H2UWJc54vIiaW53SPgwrz4fIhVNm1bw76lfI6R2_MW21) when responding and reviewing to pull requests.
+
+### Create a Module
+
+If you've built something with Nuxt that's cool, why not [extract it into a module](/docs/guide/going-further/modules), so it can be shared with others? We have [many excellent modules already](/modules), but there's always room for more.
+
+If you need help while building it, feel free to [check in with us](/docs/community/getting-help).
+
+### Make an RFC
+
+We highly recommend [creating a module](#create-a-module) first to test out big new features and gain community adoption.
+
+If you have done this already, or it's not appropriate to create a new module, then please start by creating a new discussion. Make sure it explains your thinking as clearly as possible. Include code examples or function signatures for new APIs. Reference existing issues or pain points with examples.
+
+If we think this should be an RFC, we'll change the category to RFC and broadcast it more widely for feedback.
+
+An RFC will then move through the following stages:
+
+* `rfc: active` - currently open for comment
+* `rfc: approved` - approved by the Nuxt team
+* `rfc: ready to implement` - an issue has been created and assigned to implement
+* `rfc: shipped` - implemented
+* `rfc: archived` - not approved, but archived for future reference
+
+### Conventions Across Ecosystem
+
+The following conventions are _required_ within the `nuxt/` organization and recommended for other maintainers in the ecosystem.
+
+#### Module Conventions
+
+Modules should follow the [Nuxt module template](https://github.com/nuxt/starter/tree/module). See [module guide](/docs/guide/going-further/modules) for more information.
+
+#### Use Core `unjs/` Libraries
+
+We recommend the following libraries which are used throughout the ecosystem:
+
+* [pathe](https://github.com/unjs/pathe) - universal path utilities (replacement for node `path`)
+* [ufo](https://github.com/unjs/ufo) - URL parsing and joining utilities
+* [unbuild](https://github.com/unjs/unbuild) - rollup-powered build system
+* ... check out the rest of the [unjs/](https://github.com/unjs) organization for many more!
+
+#### Use ESM Syntax and Default to `type: module`
+
+Most of the Nuxt ecosystem can consume ESM directly. In general we advocate that you avoid using CJS-specific code, such as `__dirname` and `require` statements. You can [read more about ESM](/docs/guide/concepts/esm).
+
+#### What's Corepack
+
+[Corepack](https://nodejs.org/api/corepack.html) makes sure you are using the correct version for package manager when you run corresponding commands. Projects might have `packageManager` field in their `package.json`.
+
+Under projects with configuration as shown below, Corepack will install `v7.5.0` of `pnpm` (if you don't have it already) and use it to run your commands.
+
+```jsonc [package.json]
+{
+  "packageManager": "pnpm@7.5.0"
+}
+```
+
+#### Use ESLint
+
+We use [ESLint](https://eslint.org) for both linting and formatting with [`@nuxt/eslint`](https://github.com/nuxt/eslint).
+
+##### IDE Setup
+
+We recommend using [VS Code](https://code.visualstudio.com) along with the [ESLint extension](https://marketplace.visualstudio.com/items?itemName=dbaeumer.vscode-eslint). If you would like, you can enable auto-fix and formatting when you save the code you are editing:
+
+```json [settings.json]
+{
+  "editor.codeActionsOnSave": {
+    "source.fixAll": "never",
+    "source.fixAll.eslint": "explicit"
+  }
+}
+```
+
+#### No Prettier
+
+Since ESLint is already configured to format the code, there is no need to duplicate the functionality with Prettier. To format the code, you can run `yarn lint --fix`, `pnpm lint --fix`, or `bun run lint --fix` or referring the [ESLint section](#use-eslint) for IDE Setup.
+
+If you have Prettier installed in your editor, we recommend you disable it when working on the project to avoid conflict.
+
+#### Package Manager
+
+We recommend `pnpm` as a package manager for modules, libraries and apps.
+
+It is important to enable Corepack to ensure you are on the same version of the package manager as the project. Corepack is built-in to new node versions for seamless package manager integration.
+
+To enable it, run
+
+```bash [Terminal]
+corepack enable
+```
+
+You only need to do this one time, after Node.js is installed on your computer.
+
+## Documentation Style Guide
+
+Documentation is an essential part of Nuxt. We aim to be an intuitive framework - and a big part of that is making sure that both the developer experience and the docs are perfect across the ecosystem. 👌
+
+Here are some tips that may help improve your documentation:
+
+* Avoid subjective words like _simply_, _just_, _obviously..._ when possible.
+
+  Keep in mind your readers can have different backgrounds and experiences. Therefore, these words don't convey meaning and can be harmful.
+
+  ::caution{ icon="i-lucide-circle-x"}
+  Simply make sure the function returns a promise.
+  ::
+
+  ::tip{icon="i-lucide-circle-check"}
+  Make sure the function returns a [promise](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise).
+  ::
+
+* Prefer [active voice](https://developers.google.com/tech-writing/one/active-voice).
+
+  ::caution{icon="i-lucide-circle-x"}
+  An error will be thrown by Nuxt.
+  ::
+
+  ::tip{icon="i-lucide-circle-check"}
+  Nuxt will throw an error.
+  ::
+
+::read-more{to="/docs/community/framework-contribution#documentation-guide"}
+Learn how to contribute to the documentation.
+::