NewYour coding agent can read the release notes before it upgrades.Set up the MCP server →
npm · #4082 most downloaded on npm
Toolkit for authoring modules and interacting with Nuxt
Last release 2 months ago
05 Aug 2026
Ships fairly regularly
a new release about every 3 weeks
Nearly every release is documented
notes for 55 of the last 60 stable releases
12 versions withdrawn
withdrawn after publishing
6 years old
151 releases · first in 2021
One column per quarter.
> 3.15.4 is the next patch release.
3.15.4 is the next patch release.
As usual, our recommendation for upgrading is to run:
npx nuxi@latest upgrade --force
This will refresh your lockfile as well, and ensures that you pull in updates from other dependencies that Nuxt relies on, particularly in the unjs ecosystem.
acorn (#30754)@nuxt/schema from nuxt package dir (#30774)srcDir (#30771)useRoute in SFC setup (#30788)externality for dev server externals (#30802)chunk.names for asset names (#30780)This is a significant/breaking change we would not normally ship in a patch but it is a security fix (see https://github.com/nuxt/nuxt/security/adviso…
3.15.3 is the next regularly scheduled patch release.
Alongside a range of improvements, we've also shipped a significant fix to impose CORS origin restrictions on the dev server. This applies to your Vite or Webpack/Rspack dev middleware only.
This is a significant/breaking change we would not normally ship in a patch but it is a security fix (see https://github.com/nuxt/nuxt/security/advisories/GHSA-4gf7-ff8x-hq99 and https://github.com/nuxt/nuxt/security/advisories/GHSA-2452-6xj8-jh47) and we urge you to update ASAP.
You can configure the allowed origins and other CORS options via the devServer.cors options in your nuxt.config, which may be relevant if you are developing with a custom hostname:
export default defineNuxtConfig({
devServer: {
cors: {
origin: ['https://custom-origin.com'],
},
},
})
As usual, our recommendation for upgrading is to run:
npx nuxi@latest upgrade --force
This will refresh your lockfile as well, and ensures that you pull in updates from other dependencies that Nuxt relies on, particularly in the unjs ecosystem.
mkdirSync calls (#30651)findPath and resolvePath (#30682)Transition component only on client side (#30720)#app-manifest alias (#30618)plugin.src for variable name generation (#30649)dev/test environment value (#30667)invalidateModule call (9bd71e498)[[ optional dynamic params (#30619)devServer.cors (406db5b4d)externality and use vite internal config (#30634)useFetch example (#30629)nuxi source code (4fabe0025)NuxtLink (#30614)addRouteMiddleware (#30656)ClientOnly with onMounted hook (#30670)navigation mode in callOnce composable (#30612)inlineDependencies option (01adefcec)lodash-es (0c01273f5)> 3.15.2 is the next regularly scheduled patch release.
3.15.2 is the next regularly scheduled patch release.
It is worth noting that this release includes some pretty significant performance improvements which you should notice particularly in the startup time. In my tests in the nuxt monorepo,
| fixture | time to vite build complete (v3.15.1) | time to vite build complete (v3.15.2) |
|---|---|---|
| minimal | 850ms | 710ms |
| everything bagel | 3,021ms | 1,690ms |
There's more improvement to do here but hopefully these are good numbers!
To improve performance within Nuxt projects, we've published a new @nuxt/cli distribution of nuxi, which is used under-the-hood in nuxt (see issue). This should behave exactly the same and nothing needs to be updated in your projects (for example, you will continue to use the nuxi or nuxt commands). The only significant change is that it no longer inlines dependencies. Feedback is welcome 🙏
As usual, our recommendation for upgrading is to run:
npx nuxi@latest upgrade --force
This will refresh your lockfile as well, and ensures that you pull in updates from other dependencies that Nuxt relies on, particularly in the unjs ecosystem.
@nuxt/cli dependency (#30526)definePageMeta when extracting page metadata (#30490)#build to the end of tsConfig paths (#30520)fullPath instead of empty string in router hmr (#30500)@nuxt/cli (618bbc6da)page:loading:end only once with nested pages (#29009)#app-manifest (#30587)shouldPrefetch on the server side (#30591)--dev option for the module command (#30477)url in useFetch (#30531)@nuxt/module-builder source (509cf4a5c)status detail and enhance getCachedData readability (#30536)useNuxtData (#30570)useAsyncData side effects (#30479)nuxt/app (1adf3e31f)> 3.15.1 is the next regularly scheduled patch release.
3.15.1 is the next regularly scheduled patch release.
As usual, our recommendation for upgrading is to run:
npx nuxi@latest upgrade --force
This will refresh your lockfile as well, and ensures that you pull in updates from other dependencies that Nuxt relies on, particularly in the unjs ecosystem.
lodash-es dependency (#30409)pathe browser dep for deep server components (#30456)nuxt instance to resolvePagesRoutes (e4a372e12)location instead of range for route meta property extraction (#30447)vueCompilerOptions.plugins type (#30454)baseURL when ignoring prerendered manifest (#30446)router.options when hmring routes (#30455)consola with nuxt tag instead of console (#30408)lodash and recommend es-toolkit (8e2ca5bdc)Nuxt v3.15 includes Vite 6 for the first time. Although this is a major version, we expect that this won't be a breaking change for Nuxt users (see fu…
Happy holidays! You'll notice when you start Nuxt that (if you're in the Northern Hemisphere) there's some snow on the loading screen (#29871).
Nuxt v3.15 includes Vite 6 for the first time. Although this is a major version, we expect that this won't be a breaking change for Nuxt users (see full migration guide). However, please take care if you have dependencies that rely on a particular Vite version.
One of the most significant changes with Vite 6 is the new Environment API, which we hope to use in conjunction with Nitro to improve the server dev environment. Watch this space!
You can read the full list of changes in the Vite 6 changelog.
We talk a lot about the Nuxt DevTools, but v3.15 ships with better integration in dev mode for Chromium-based browser devtools.
We now use the Chrome DevTools extensibility API to add support for printing nuxt hook timings in the browser devtools performance panel.
callOncecallOnce is a built-in Nuxt composable for running code only once. For example, if the code runs on the server it won't run again on the client. But sometimes you do want code to run on every navigation - just avoid the initial server/client double load. For this, there's a new mode: 'navigation' option that will run the code only once per navigation. (See #30260 for more info.)
await callOnce(() => counter.value++, { mode: 'navigation' })
We now implement hot module reloading for Nuxt's virtual files (like routes, plugins, generated files) as well as for the content of page metadata (within a definePageMeta macro) (#30113).
This should mean you have a faster experience in development, as well as not needing to reload the page when making changes to your routes.
We now support extracting extra page meta keys (likely used by module authors) via experimental.extraPageMetaExtractionKeys (#30015). This enables module authors to use this information at build time, in the pages:resolved hook.
We also now support local functions in definePageMeta (#30241). This means you can do something like this:
function validateIdParam(route) {
return !!(route.params.id && !isNaN(Number(route.params.id)))
}
definePageMeta({
validate: validateIdParam,
})
We now preload the app manifest in the browser if it will be used when hydrating the app (#30017).
We'll also tree shake vue-router's hash mode history out of your bundle if we can - specifically, if you haven't customised your app/router.options.ts (#30297).
A few more changes shipped for the new defaults for v4, including only inlining styles by default for Vue components (#30305).
As usual, our recommendation for upgrading is to run:
npx nuxi@latest upgrade --force
This will refresh your lockfile as well, and ensures that you pull in updates from other dependencies that Nuxt relies on, particularly in the unjs ecosystem.
extraPageMetaExtractionKeys (#30015)definePageMeta (#30241)mode: 'navigation' to callOnce (#30260)hashMode option (#30297)addServerTemplate (a02af2348)extraExtractionKeys on runtime route.meta (ae9f42f4a)style value for head components (#29999)useId implementation (40f437d25)buildDir to normalizeTemplate (#30115)useRequestFetch (#30117)nitropack rather than nitro import (2d5b53b23)engines.node to match dependencies (#30139)routerOptions.history to return null (#30192)useId for island client component teleport id (#30151)nuxt and nuxt/app (#30148)getRouteRules works with nitro signature (#30277)replace in middleware with navigateTo (#30283)nitropack (f220314a5)<RouterLink> for links starting with # (#30190)#app-manifest (ec613e533)useId for client-fallback component uid (#30314)@vitest/ (4171a1076)addTemplate if undefined (#30348)import.meta.hot.data (b1cf5781d)composable-keys plugin into nuxt core (#30029)nuxt: (#30028)event.waitUntil (#29583)vite.dev (#30111)nuxi upgrade channel flag (#30184)useLazyFetch (#30171)vite.css.preprocessorMaxWorkers (eb1ba017c)compatibilityVersion feature flag (#30274)nuxi command pages (#30199)inlineStyles (2660bffbc)unimport (7ee455969)installed-check dependency (0e84cb9a4)engines.node to reflect only deps (d3d276919)rimraf (cf9d82c5a)div wrapper in client-only page (#30359)> 3.14.1592 is the next patch release.
3.14.1592 is the next patch release.
webpackbar with support for rspack (#29823)dst to deduplicate templates when adding them (#29895)dst to invalidate modules (6cd3352de)change events (#29954)<NuxtWelcome> when building (#29956)Remove outdated cloudflare tip (auto minify deprecated)
3.14.159 is a hotfix release to address regressions in v3.14.
We're leaning into the π theme - future patch releases of this minor version will just continue adding digits. (Sorry for any inconvenience! 😆)
module.json (#29793)mlly to resolve module paths to avoid cjs fallback (#29799)webpack-dev-middleware (#29806)> 3.14.0 is the next minor release.
3.14.0 is the next minor release.
Behind the scenes, a lot has been going on in preparation for the release of Nuxt v4 (particularly on the unjs side with preparations for Nitro v3!)
jitiLoading the nuxt config file, as well as modules and other build-time code, is now powered by jiti v2. You can see more about the release in the jiti v2 release notes, but one of the most important pieces is native node esm import (where possible), which should mean a faster start. ✨
You should never import Vue app code in your nitro code (or the other way around). But this has meant a friction point when it comes to sharing types or utilities that don't rely on the nitro/vue contexts.
For this, we have a new shared/ folder (#28682). You can't import Vue or nitro code into files in this folder, but it produces auto-imports you can consume throughout the rest of your app.
If needed you can use the new #shared alias which points to this folder.
The shared folder is alongside your server/ folder. (If you're using compatibilityVersion: 4, this means it's not inside your app/ folder.)
rspack builderWe're excited to announce a new first-class Nuxt builder for rspack. It's still experimental but we've refactored the internal Nuxt virtual file system to use unplugin to make this possible.
Let us know if you like it - and feel free to raise any issues you experience with it.
👉 To try it out, you can use this starter - or just install @nuxt/rspack-builder and set builder: 'rspack' in your nuxt config file.
We have new useResponseHeader and useRuntimeHook composables (#27131 and #29741).
We now have a new addServerTemplate utility (#29320) for adding virtual files for access inside nitro runtime routes.
We've merged some changes which only take effect with compatibilityVersion: 4, but which you can opt-into earlier.
previously, if you had a component like ~/components/App/Header.vue this would be visible in your devtools as <Header>. From v4 we ensure this is <AppHeader>, but it's opt-in to avoid breaking any manual <KeepAlive> you might have implemented. (#28745).
Nuxt scans page metadata from your files, before calling pages:extend. But this has led to some confusing behaviour, as pages added at this point do not end up having their page metadata respected. So we now do not scan metadata before calling pages:extend. Instead, we have a new pages:resolved hook, which is called after pages:extend, after all pages have been augmented with their metadata. I'd recommend opting into this by setting experimental.scanPageMeta to after-resolve, as it solves a number of bugs.
They didn't quite make it in time for v3.14 but for the next minor release you can expect (among other things):
As usual, our recommendation for upgrading is to run:
npx nuxi@latest upgrade --force
This will refresh your lockfile as well, and ensures that you pull in updates from other dependencies that Nuxt relies on, particularly in the unjs ecosystem.
jiti (#29073)addServerTemplate utility (#29320)useResponseHeader composable (#27131)rspack builder (#29142)pages:resolved hook + scan meta post extend (#28861)definePageMeta (#29586)shared/ folder and #shared alias (#28682)useRuntimeHook composable (#29741)useNuxtApp (#29514)InjectionType template conditional (#29023)webpack memfs (#29027)DOMException as fetch abort exception (#29058)devServer.https (#29049)buildDir in dev mode (#29068)node_modules/ from parent urls (5bd42c893)crossorigin attribute for stylesheets (#29138)routeRules to hint pages to prerender (#29172)link:prefetch (#29321)ConfigLayer type from c12 (#29370)typedPages (#29352)configFile as required in layer type (3bbcd7d21)createIsExternal (686be8168)props value in definePageMeta (#29683)nitropack/types to ensure api routes are typed (54096875e)addBuildPlugin internally (#29157)defineNuxtComponent instead of defineComponent (#29011)useRequestFetch and event.$fetch (#29099)useFetch errors (#29253)ofetch headers for interceptors (#29118).env.test (#29398)mockImplementation() call (#29669)$fetch (#29755)--envName flag (#28909)beasties (1b5391182)unbuild update (71e0fb06f)jiti.import (7ece49f9b)unctx transform (d81196122)> 3.13.2 is the next regularly scheduled patch release.
3.13.2 is the next regularly scheduled patch release.
As usual, our recommendation for upgrading is to run:
npx nuxi@latest upgrade --force
This will refresh your lockfile as well, and ensures that you pull in updates from other dependencies that Nuxt relies on, particularly in the unjs ecosystem.
propsDestructure by default (#28830)route has enumerable keys (#28841)asyncData (#28842)ssr: false (#28834)injectAtEnd to reduce circular auto-imports (#28822)buildDir for unimport (#28899)<NuxtErrorBoundary> (#28901)modules array (#28922)filePath (#28925)runWithContext generic (#28926)inheritAttrs: false for fragment components (#28939)<script> blocks (4fd24381c)isNuxtMajorVersion export (#29016)useError (#28996)vite:preloadError event (#28862)useFetch parameter signature (#28993)noUncheckedSideEffectImports (#28903)pending triage to blank issues (#28923)htmlnano + pin workflow deps (#28946)route in template (#28967)> 3.13.1 is the next regularly scheduled patch release.
3.13.1 is the next regularly scheduled patch release.
Although this is a patch release, there are two features I'd love to draw your attention to.
useId now uses a built-in Vue composable for stable ids between server + client! https://github.com/nuxt/nuxt/pull/28285experimental.buildCache feature now allows for quicker app rebuilds https://github.com/nuxt/nuxt/pull/28726As always, feedback is appreciated 🙏 ❤️
As usual, our recommendation for upgrading is to run:
npx nuxi@latest upgrade --force
This will refresh your lockfile as well, and ensures that you pull in updates from other dependencies that Nuxt relies on, particularly in the unjs ecosystem.
ServerPlaceholder for ssr client components (#28563)serverDir relative to root (#28700)MiddlewareKey (#28676)NuxtLink (#28738)NuxtOptions as well as config (#28747)CookieStore events (#28760)appConfig with non-iterable objects (#28773)isNuxtError type inference (#28814)useId (#28285)query returned value from useRoute() (#28743)--frozen-lockfile when installing dependencies (#28794)tinyexec internally (#28684)tinyglobby internally (#28686)I'm pretty excited about this release - we've ported some features we had planned for Nuxt v4 back to v3, as well as a raft of bug fixes and performan
I'm pretty excited about this release - we've ported some features we had planned for Nuxt v4 back to v3, as well as a raft of bug fixes and performance improvements - as usual.
Here are a few of things I'm most excited about.
We now support naming directories with parentheses/brackets to organise your routes without affecting the path.
For example:
-| pages/
---| index.vue
---| (marketing)/
-----| about.vue
-----| contact.vue
This will produce /, /about and /contact pages in your app. The marketing group is ignored for purposes of your URL structure.
Read more in the original PR.
It's now possible for server component islands to manipulate the head, such as by adding SEO metadata when rendering.
Read more in #27987.
We now support custom prefetch triggers for NuxtLink (#27846).
For example:
<template>
<div>
<NuxtLink prefetch-on="interaction">
This will prefetch when hovered or when it gains focus
</NuxtLink>
<!-- note that you probably don't want both enabled! -->
<NuxtLink :prefetch-on="{ visibility: true, interaction: true }">
This will prefetch when hovered/focus - or when it becomes visible
</NuxtLink>
</div>
</template>
It's also possible to enable/disable these globally for your app and override them per link.
For example:
export default defineNuxtConfig({
experimental: {
defaults: {
nuxtLink: {
prefetch: true,
prefetchOn: { visibility: false, interaction: true }
}
}
}
})
When running with node --enable-source-maps, you may have noticed that the source maps for the Vue files in your server build pointed to the Vite build output (something like .nuxt/dist/server/_nuxt/index-O15BBwZ3.js).
Now, even after your Nitro build, your server source maps will reference your original source files (#28521).
Note that one of the easiest ways of improving your build performance is to turn off source maps if you aren't using them, which you can do easily in your nuxt.config:
export default defineNuxtConfig({
sourcemap: {
server: false,
client: true,
},
})
In the run-up to Nuxt v4, we're working on adding some key functionality for module authors, including a new isNuxtMajorVersion utility where required (#27579) and better inferred typing for merged module options using the new defineNuxtModule().with() method (#27520).
We no longer warn when using data fetching composables in middleware (#28604) and we warn when user components' names begin with Lazy (#27838).
For a while, in the Vue ecosystem, we've been augmenting @vue/runtime-core to add custom properties and more to vue. However, this inadvertently breaks the types for projects that augment vue - which is now the officially recommended in the docs way to augment these interfaces (for example, ComponentCustomProperties, GlobalComponents and so on).
This means all libraries must update their code (or it will break the types of libraries that augment vue instead).
We've updated our types in Nuxt along these lines but you may experience issues with the latest vue-router when used with libraries which haven't yet done so.
Please create an issue with a reproduction - I'll happily help create a PR to resolve in the upstream library in question. Or you may be able to work around the issue by creating a declarations.d.ts in the root of your project with the following code (credit):
import type {
ComponentCustomOptions as _ComponentCustomOptions,
ComponentCustomProperties as _ComponentCustomProperties,
} from 'vue';
declare module '@vue/runtime-core' {
interface ComponentCustomProperties extends _ComponentCustomProperties {}
interface ComponentCustomOptions extends _ComponentCustomOptions {}
}
As usual, our recommendation for upgrading is to run:
npx nuxi@latest upgrade --force
This will refresh your lockfile as well, and ensures that you pull in updates from other dependencies that Nuxt relies on, particularly in the unjs ecosystem.
routes function in router.options (#27644)isNuxtMajorVersion compatibility util (#27579).with for better module options types (#27520)Lazy (#27838)usePreviewMode (#28371)prepend option to addRouteMiddleware (#28496)__NUXT__ when using multi-app (#27263)decode function only for named cookie (#28215)getCachedData (#28472)definePageMeta in client-only pages (#28246)dist/runtime/ in tsconfig includes (#28237)assetsDir (59f0099f4)serverDir (#28249)vite-plugin-vue (#28307)scroll-padding-top: auto in scrollBehavior (#28320)runtimeConfig.public is reactive on client (#28443)nuxt/scripts (#28449)@vue/runtime-core and @vue/runtime-dom (#28446)baseURL for public assets in dev (#28482)useFetch (#28517)vue, not sub-packages (#28542)route.meta (#28441)validate method (#28612)prefetchOn prop (#28630)vue lang to sample code (#28247)splitSetCookieString from cookie-es (29f95ae0d)headers.getSetCookie (45c6df9a4)bunx -> bun x (#28277)@see blocks (#28270)mountSuspended (#28463)options type in custom useFetch recipe (#28389)pageTransition in client-only page (#27839)SharedComponent in server head (510f3e28f)Remove deprecated pending variable from data fetching docs
3.12.4 is the next regularly scheduled patch release.
resolveId in layers (#27971)noScripts (#27972)/ as fallback if page can't be identified (e6109b226)html-validate (#28024)unhead key for ad-hoc module options (#28088)getNuxtVersion returns string (#28125)scroll-padding-top in scrollBehavior (#28083)useAsyncData returns undefined (#28154)getCachedData null response (d10cea11b)app/ as srcDir if it doesn't exist (#28176)serverDir within layers using v4 compat (#28177)getCachedData to return undefined (#28187)addEventListener to register cookie store listener (#28193)set-cookie headers (#28211)postcss module loading (#27946)_registeredComponents from ssrContext (#27819)errx to handle dev log traces (#28027)nuxtApp.runWithContext (#28000)pending variable from data fetching docs (#28011)layers/ directory (#28128)typeCheck test in minimal build (#28166)Allow changelogs with breaking changes
3.12.3 is the next regularly scheduled patch release.
fs-extra (#27787)chokidar when a custom srcDir is provided (#27871)prefetchComponents is treeshaken on server (#27905)dir.app (0c73cb734)navigateTo called with open (#27742)refresh type in server component refs (#27778)#vue-router alias for backwards compat (#27896)nuxt types (#27900)?raw from head when in dev mode (#27940)performance.now to measure time (d14f7ec46)refreshCookie on useCookie doc page (#27744)main branch (e7fbc9f81)useFetch/AsyncData in wrappers (#27785)vue-router docs (#27895)compatibilityVersion is available in the latest release (#27919)Nuxt 3 -> Nuxt or Nuxt 3+ (3c16c890c)refs (#27933)4x tag for v4 nightly releases (9d5dd5494)dev-bundler (e3448fa0d)2.x branch (8003cf72f)main branch (7abd982f8)@vitejs/plugin-vue again (56660cbdd)nuxt: Replace deprecated app.rootId with app.rootAttrs.id
3.12.2 is the a regularly scheduled patch release.
As usual, our recommendation for upgrading is to run:
npx nuxi@latest upgrade --force
This will refresh your lockfile as well, and ensures that you pull in updates from other dependencies that Nuxt relies on, particularly in the unjs ecosystem.
onNuxtReady callback without arguments (#27428)app/ dir backwards compatibility (#27529)ssr: false (#27542)runtimeConfig key (9e56b60c6)#app/defaults rather than augmenting (#27567)useRouteAnnouncer (#27562)_installedModules (e4bfea642)app.rootId with app.rootAttrs.id (#27630)mergeProps import in islands transform (#27622)vite.cacheDir if defined (#27628)close is called (#27637)/ even if pages module isn't enabled (dabcb5ecc)head (#27575)clear() function added in 3.11 (#27615)webpack-virtual-modules (58dd7f3a6)> 3.12.1 is a hotfix release to address a typo in the nuxt/script stub auto-imports.
3.12.1 is a hotfix release to address a typo in the nuxt/script stub auto-imports.
@nuxt/scripts (0252000d7)CompatibilityDateSpec (#27521)nuxt: Deprecate process.* flags
We're on the road to the release of Nuxt 4, but we've not held back in Nuxt v3.12. A huge thank you to the 75+ Nuxt contributors and community members who have been part of this release. ❤️
Nuxt 4 is on the horizon, and it's now possible to test out the behaviour changes that will be coming in the next major release (#26925) by setting an option in your nuxt.config file:
export default defineNuxtConfig({
future: {
compatibilityVersion: 4,
},
})
As we've been merging PRs for Nuxt 4, we've been enabling them behind this flag. As much as possible we're aiming for backwards compatibility - our test matrix is running the same fixtures in both v3 and v4 compatibility mode.
There is a lot to say here, with 10+ different PRs and behaviour changes documented and testable, but for full details, including migration steps, see the v4 upgrade documentation.
We'd be very grateful for early testing of what's coming in Nuxt 4! 🙏
We've been gradually working to release Nuxt Scripts. It's currently in public preview, but we're near a public release, so we've added some stubs for composables that (when used) will prompt installing the @nuxt/scripts module.
👉 Watch out for the launch - and an article explaining more!
Just like ~/modules, any layers within your project in the ~/layers directory will now be automatically registered as layers in your project (#27221).
We also now correctly load layer dependencies, which should resolve a range of issues with monorepos and git installations (#27338).
We now have a built-in <NuxtRouteAnnouncer> component and corresponding useRouteAnnouncer composable, which will be added by default to new Nuxt templates going forward.
For full details, see the original PR (#25741) and documentation.
We're continuing to work on nuxt/a11y - expect to hear more on that in future!
We've landed some performance improvements as well, many of which are behind the compatibilityVersion: 4 flag, such as a move away from deeply reactive asyncData payloads.
Significant improvements include deduplicating modules (#27475) - which will apply mostly to layer users who specify modules in their layers. In one project, we saw 30s+ improvement in starting Nuxt.
We've also improved Vite dev server start up time by excluding common ESM dependencies from pre-bundling, and would suggest module authors consider doing the same (#27372).
We improved chunk determinism, so sequential builds should be less likely to have completely different chunk hashes (#27258).
And we tree shake more client-only composables from your server builds (#27044), and have reduced the size of server component payloads (#26863).
We've landed a couple of changes that take us toward a place of supporting multi-app natively in Nuxt, including a multiApp experimental flag (#27291) and the ability to have multiple Nuxt app instances running in parallel at runtime (#27068).
While it's not yet ready, please do follow along on the tracker issue, and feel free to pitch in if this is interesting to you.
We now serialise more things in your dev server logs, including VNodes (#27309) and URLs. We also addressed a bug that could lead to a frozen dev server.
When accessing private runtime config in the browser, we now let you know with a more informative error message (#26441).
We've removed some experimental options that have been stabilised and which we feel no longer need to be configurable:
experimental.treeshakeClientOnly (enabled by default since v3.0.0)experimental.configSchema (enabled by default since v3.3.0)experimental.polyfillVueUseHead (disabled since v3.4.0) - implementable in user-land with pluginexperimental.respectNoSSRHeader (disabled since v3.4.0) - implementable in user-land with server middlewareWe've also enabled scanPageMeta by default (#27134). This pulls out any page metadata in your definePageMeta macro, and makes it available to modules (like @nuxtjs/i18n) so they can augment it.
This unlocks much better module/typed routing integration, but has a potential performance cost - so please file an issue if you experience any problems.
We now have support for typed #fallback slots in server components (#27097).
We've also improved some defaults in your generated tsconfig.json, including setting module: 'preserve' if you have a locally installed TypeScript v5.4 version (see docs) - see #26667, #27485.
We have shipped a range of type improvements for module authors, including:
installModule (#26744)onPrehydrate hook for hooking into the browser hydration cycle (#27037)useRuntimeConfig and updateRuntimeConfig utils (#27117)If you previously used @nuxt/ui-templates then it may be worth knowing that we have moved them from a separate repository into the nuxt/nuxt monorepo. (This is purely a refactor rather than a change, although you can expect some new designs for Nuxt v4.)
As usual, our recommendation for upgrading is to run:
npx nuxi@latest upgrade --force
This will refresh your lockfile as well, and ensures that you pull in updates from other dependencies that Nuxt relies on, particularly in the unjs ecosystem.
useRequestURL (#26687)imports.scan option (#26576)<NuxtRouteAnnouncer> and useRouteAnnouncer (#25741)resolvePath and findPath (#26465)useLink from NuxtLink (#26522)future.compatibilityVersion (#26925)app.rootAttrs and teleportAttrs (#27014)cookieStore by default (f597ca59a)onUpdated and onUnmounted on server (#27044)nuxt/scripts on usage (#27010)<NuxtPage> (#27050)renderSSRHeadOptions config for unhead (#26989)onPrehydrate lifecycle hook (#27037)#fallback slot to server components types (#27097)useRuntimeConfig and updateRuntimeConfig utils (#27117)layers/ directory (#27221)appId and improve chunk determinism (#27258)multiApp flag (#27291)compatibilityVersion (#27305)URL serialiser for dev server logs (a549b46e9)this.$route (#27313)installModule (#26744).with for better module options types (#26850)compatibilityDate flag for future (#27512)asyncData watch when unmounted (#26821)ssrContext.styles reference (from unused vue-style-loader) (2d1ab61b2)shallowReactive (#27214)getCachedData from shaping type of useAsyncData (#25946)hasSuffix (#26725)moduleDetection to 'force' (#26667)nuxt._ignore after all modules run (#26680)v-for to slot in islands (#26880)_scope is active before calling run function (#26756, #26904)enabled is false (#26906)lang="ts" (#26912)updateAppConfig (#26949)useState in NuxtClientFallback setup function (#26928).js extension from template imports (0d4a622f3)runWithContext (#26976)app.vue exists in rootDir (1af81ed0f)URL constructor to resolve external protocols (5f0693a69)URL for parsing URLs rather than parseURL (ea22d3f98)process.* flags (#27089)NuxtTeleportIslandComponent (#27093)spaLoadingTemplate function (0e12b6eb8)jiti and not file URL (#27252)buildId in schema (#27274)location header in navigateTo (#27280)undefined rather than null for data fetching defaults (#27294)app.cdnURL for extracted payloads (#26668)VNode reviver & don't deduplicate dev logs (#27309)app.config files in nitro build (#27342)app.config.d.ts (#27350)optimizeDeps in ssr (#27356)hmr.server is set (#27326)app options (#27478)app.head arrays (#27480)tsconfig.json (#27485)buildAssetsDir in island teleport dev chunk (#27469)module: preserve unelss ts v5.4 is installed (b08dfc98b)pages:extend hook (#27134)esnext target (7bb02735e)boolean value for dedupe in v4 compat (#27511)scopeId to server components (#27497)dependsOn works not just for parallel plugins (#26707)--preset flag for nuxi build (#26759)useFetch (#26748)callWithNuxt (#26771)srcDir description mentioning deprecated static/ directory (#26804)pageRef from a child page (#26806)pending value in data fetching composables (#26766)@vue/test-utils getting started guide (#26205)a -> an (#26856)usePreviewMode explanation (#26602)defineConfig (a60de743a)@since annotations to exported functions (#25365).eslintrc.js to eslint.config.js (#27020)future.compatibilityVersion (e7789a257)nuxi init (#27051)ignorePrefix to clarify ignored files (#27065)app.config.ts to nuxt 4 testing/migration (#27164)useFetch recipe (#27208)nuxt/scripts (#27229)<NuxtLink> (#27284)baseURL and cdnURL (#27273)partitioned attribute of useCookie (#27297)error hook type (61766702c)srcDir in upgrade steps (3383a2df2)moduleResolution to Bundler (#26658)@nuxt/eslint-config (#26653)devcontainer.json syntax (#26776)conventionalcommits.org (9ba1ebe98)@nuxt/ui-templates to core monorepo (fe6bdcc01)ui-templates (15781c608)@internal comment (cf736e274)eslint-plugin-regexp (#27271)ui-templates when stubbing packages (#27446)jiti and @vitejs/plugin-vue (2a2847e4b)shamefully-hoist within repo (#27483)jiti (#27479)ui-templates as valid scope (5afd75b88)> 3.11.2 is the next regularly scheduled patch release.
3.11.2 is the next regularly scheduled patch release.
As usual, our recommendation for upgrading is to run:
nuxi upgrade --force
This will refresh your lockfile as well, and ensures that you pull in updates from other dependencies that Nuxt relies on, particularly in the unjs ecosystem.
useServerHead in dev (#26421)navigateTo open option on server side (#26392)definePageMeta in server pages (#26422)joinRelativeURL + share paths on server (#26407)<srcDir>/index.html from import protection (#26430)refreshCookie on server (22ada37b4)v-if to wrapper in islands transform (#26386)getLatestManifest (#26486)GlobalComponents in multiple vue modules (#26541)transformAssetUrls + pass hoistStatic to vite plugin (#26563)typescript.shim (#26607)useRoute (#26633)navigateTo for server (#26546)runtimeConfig initialization of client side (#26558)prerenderRoutes in dynamic routes (#26547)process.* with import.meta.* (#26611)typescript.shim JSDoc (#26626)> 3.11.1 is a patch release addressing regressions in v3.11.0.
3.11.1 is a patch release addressing regressions in v3.11.0.
As usual, our recommendation for upgrading is to run:
nuxi upgrade --force
This will refresh your lockfile as well, and ensures that you pull in updates from other dependencies that Nuxt relies on, particularly in the unjs ecosystem.
ofetch in typescript.hoist defaults (#26316)tsx parser (#26314)finish types and add to docs (0d9c63b82)undefined name when resolving trailing slash (#26358)usePreviewMode (#26303)useId must be used with single root element (401370b3a)<DevOnly> component in api section (#26029)@nuxt/schema should be used by module authors (#26190)routeNameSplitter example in migration docs (#25838)This is possibly the last minor release before Nuxt v4, and so we've packed it full of features and improvements we hope will delight you! ✨
This is possibly the last minor release before Nuxt v4, and so we've packed it full of features and improvements we hope will delight you! ✨
When developing a Nuxt application and using console.log in your application, you may have noticed that these logs are not displayed in your browser console when refreshing the page (during server-side rendering). This can be frustrating, as it makes it difficult to debug your application. This is now a thing of the past!
Now, when you have server logs associated with a request, they will be bundled up and passed to the client and displayed in your browser console. Asynchronous context is used to track and associate these logs with the request that triggered them. (#25936).
For example, this code:
<script setup>
console.log('Log from index page')
const { data } = await useAsyncData(() => {
console.log('Log inside useAsyncData')
return $fetch('/api/test')
})
</script>
will now log to your browser console when you refresh the page:
Log from index page
[ssr] Log inside useAsyncData
at pages/index.vue
👉 We also plan to support streaming of subsequent logs to the Nuxt DevTools in future.
We've also added a dev:ssr-logs hook (both in Nuxt and Nitro) which is called on server and client, allowing you to handle them yourself if you want to.
If you encounter any issues with this, it is possible to disable them - or prevent them from logging to your browser console.
export default defineNuxtConfig({
features: {
devLogs: false
// or 'silent' to allow you to handle yourself with `dev:ssr-logs` hook
},
})
A new usePreviewMode composable aims to make it simple to use preview mode in your Nuxt app.
const { enabled, state } = usePreviewMode()
When preview mode is enabled, all your data fetching composables, like useAsyncData and useFetch will rerun, meaning any cached data in the payload will be bypassed.
We now automatically cache-bust your payloads if you haven't disabled Nuxt's app manifest, meaning you shouldn't be stuck with outdated data after a deployment.
routeRulesIt's now possible to define middleware for page paths within the Vue app part of your application (that is, not your Nitro routes) (#25841).
export default defineNuxtConfig({
routeRules: {
'/admin/**': {
// or appMiddleware: 'auth'
appMiddleware: ['auth']
},
'/admin/login': {
// You can 'turn off' middleware that would otherwise run for a page
appMiddleware: {
auth: false
}
},
},
})
clear data fetching utilityNow, useAsyncData and useFetch expose a clear utility. This is a function that can be used to set data to undefined, set error to null, set pending to false, set status to idle, and mark any currently pending requests as cancelled. (#26259)
<script setup lang="ts">
const { data, clear } = await useFetch('/api/test')
const route = useRoute()
watch(() => route.path, (path) => {
if (path === '/') clear()
})
</script>
#teleports targetNuxt now includes a new <div id="teleports"></div> element in your app within your <body> tag. It supports server-side teleports, meaning you can do this safely on the server:
<template>
<Teleport to="#teleports">
<span>
Something
</span>
</Teleport>
</template>
It's now possible to set custom timings for hiding the loading indicator, and forcing the finish() method if needed (#25932).
There's also a new page:view-transition:start hook for hooking into the View Transitions API (#26045) if you have that feature enabled.
This release sees server- and client-only pages land in Nuxt! You can now add a .server.vue or .client.vue suffix to a page to get automatic handling of it.
Client-only pages will render entirely on the client-side, and skip server-rendering entirely, just as if the entire page was wrapped in <ClientOnly>. Use this responsibly. The flash of load on the client-side can be a bad user experience so make sure you really need to avoid server-side loading. Also consider using <ClientOnly> with a fallback slot to render a skeleton loader (#25037).
⚗️ Server-only pages are even more useful because they enable you to integrate fully-server rendered HTML within client-side navigation. They will even be prefetched when links to them are in the viewport - so you will get instantaneous loading (#24954).
When you are using server components, you can now use the nuxt-client attribute anywhere within your tree (#25479).
export default defineNuxtConfig({
experimental: {
componentIslands: {
selectiveClient: 'deep'
}
},
})
You can listen to an @error event from server components that will be triggered if there is any issue loading the component (#25798).
Finally, server-only components are now smartly enabled when you have a server-only component or a server-only page within your project or any of its layers (#26223).
[!WARNING]
Server components remain experimental and their API may change, so be careful before depending on implementation details.
We've shipped a number of performance improvements, including only updating changed virtual templates (#26250), using a 'layered' prerender cache (#26104) that falls back to filesystem instead of keeping everything in memory when prerendering - and lots of other examples.
We have shipped a reimplementation of Vite's public asset handling, meaning that public assets in your public/ directory or your layer directories are now resolved entirely by Nuxt (#26163), so if you have added nitro.publicAssets directories with a custom prefix, these will now work.
We have changed the default _nuxt/[name].[hash].js file name pattern for your JS chunks. Now, we default to _nuxt/[hash].js. This is to avoid false positives by ad blockers triggering off your component or chunk names, which can be a very difficult issue to debug. (#26203)
You can easily configure this to revert to previous behaviour if you wish:
export default defineNuxtConfig({
vite: {
$client: {
build: {
rollupOptions: {
output: {
chunkFileNames: '_nuxt/[name].[hash].js',
entryFileNames: '_nuxt/[name].[hash].js'
}
}
}
}
},
})
Previously users with shamefully-hoist=false may have encountered issues with types not being resolved or working correctly. You may also have encountered problems with excessive type instantiation.
We now try to tell TypeScript about certain key types so they can be resolved even if deeply nested (#26158).
There are a whole raft of other type fixes, including some regarding import types (#26218 and #25965) and module typings (#25548).
As usual, our recommendation for upgrading is to run:
nuxi upgrade --force
This will refresh your lockfile as well, and ensures that you pull in updates from other dependencies that Nuxt relies on, particularly in the unjs ecosystem.
nuxt-client in all components (#25479)page:view-transition:start hook (#26045)finish() (#25932)<NuxtIsland> can't fetch island (#25798)usePreviewMode composable (#21705)#teleports element for ssr teleports (#25043)typescript.hoist (85166cced)getCachedData (#26287)nuxtMiddleware route rule (#25841)clear utility to useAsyncData/useFetch (#26259)isPrerendered in dev for server page (#26061).config/nuxt.config (5440ecece).config/nuxt.* (7815aa534)error in showError/createError with h3 (#25945)useId (#25969)vueCompilerOptions property to tsConfig (#25924)useRuntimeConfig in Nuxt renderer (#26058)typescript.shim in favour of volar (#26052)defu/h3 paths in type templates (#26085)toExports from unimport (#26086)AsyncDataRequestStatus type (#26023)<html> and <body> attrs (#26027)node_modules for modulesDir (#25548)routeRules (#26120)cookieRef values deeply (#26151)ssrRender (#26162)ssr: false (f080c426a)baseUrl within server components (#25727)useNuxtData (#22277)publicAssetsURL (9d08cdfd1)buildAssetsDir (81933dfc3)joinRelativeURL for build assets (#26282)deep to selectiveClient (357f8db41)consola for now (adbd53a25)window access more carefully (977377777)request computation (#26191)nuxtMiddleware to appMiddleware (cac745470)useId composable was introduced (#25953)domEnvironment option to testing example (#25972)fallback prop for <NuxtLayout> (#26091)vue-tsc (#26083)macros.pageMeta and typescript.esbuild option (#26136)definePageMeta page (#26139)app:manifest:update hook (#26192)zhead (e889a7df5)clear (24217a992)appMiddleware docs (da8e8eba8)scrollY (#26298)networkidle (9b5bffbbb)> 3.10.3 is a regularly-scheduled patch release.
3.10.3 is a regularly-scheduled patch release.
As usual, our recommendation for upgrading is to run:
nuxi upgrade --force
This will refresh your lockfile as well, and ensures that you pull in updates from other dependencies that Nuxt relies on, particularly in the vue and unjs ecosystems.
dedupe option in useFetch (#25815)css files with ?inline query (#25822)external to navigate in custom <NuxtLink> (#25887)@__PURE__ (#25842)setTimeout before scrolling when navigating (#25817)head in defineNuxtComponent (#25410)undefined paths in resolveTrailingSlashBehavior (ba6a4132b)to.name to be undefined rather than deleting entirely (4ca1ab7cf).ts extension when adding compiled files (#25855)callout to new components (#25897)nuxt.config to enable pages for docs typecheck (72a2e23cc)> 3.10.2 is a regularly-scheduled patch release.
3.10.2 is a regularly-scheduled patch release.
As usual, our recommendation for upgrading is to run:
nuxi upgrade --force
This will refresh your lockfile as well, and ensures that you pull in updates from other dependencies that Nuxt relies on, particularly in the vue and unjs ecosystems.
refreshCookie (#25635).pcss extension as a CSS extension (#25673)<ClientOnly> (#25714)baseURL on server useRequestURL (#25765)rootDir, not process.cwd, for modulesDir (#25766)useId if attrs were not rendered (#25770)useAsyncData docs (#25644)addComponentsDir (#25683)event to useRuntimeConfig (#25788)> 3.10.1 is a regularly-scheduled patch release.
3.10.1 is a regularly-scheduled patch release.
As usual, our recommendation for upgrading is to run:
nuxi upgrade --force
This will refresh your lockfile as well, and ensures that you pull in updates from other dependencies that Nuxt relies on, particularly in the vue and unjs ecosystems.
refresh functions (#25568)useId type signature (#25614)$ from generated id in useId (#25615)rel for same-site external links (#25600)inheritAttrs: false when using useId (#25616)NuxtLink types (#25599)<NuxtLink> defaults in nuxt config (#25610)pathe in internal tests (e33cec958)nuxt -> nuxtApp internally for consistency (c5d5932f5)nuxt: Deprecate boolean values for dedupe
3.10.0 is the next minor/feature release.
v3.10 comes quite close on the heels of v3.9, but it's packed with features and fixes. Here are a few highlights.
asyncData when prerenderingWhen prerendering routes, we can end up refetching the same data over and over again. In Nuxt 2 it was possible to create a 'payload' which could be fetched once and then accessed in every page (and this is of course possible to do manually in Nuxt 3 - see this article).
With #24894, we are now able to do this automatically for you when prerendering. Your useAsyncData and useFetch calls will be deduplicated and cached between renders of your site.
export defineNuxtConfig({
experimental: {
sharedPrerenderData: true
}
})
[!IMPORTANT]
It is particularly important to make sure that any unique key of your data is always resolvable to the same data. For example, if you are usinguseAsyncDatato fetch data related to a particular page, you should provide a key that uniquely matches that data. (useFetchshould do this automatically.)
👉 See full documentation.
We now ship a useId composable for generating SSR-safe unique IDs (#23368). This allows creating more accessible interfaces in your app. For example:
<script setup>
const emailId = useId()
const passwordId = useId()
</script>
<template>
<form>
<label :for="emailId">Email</label>
<input
:id="emailId"
name="email"
type="email"
>
<label :for="passwordId">Password</label>
<input
:id="passwordId"
name="password"
type="password"
>
</form>
</template>
app/router.optionsIt's now possible for module authors to inject their own router.options files (#24922). The new pages:routerOptions hook allows module authors to do things like add custom scrollBehavior or add runtime augmenting of routes.
👉 See full documentation.
We now support (experimentally) polyfilling key Node.js built-ins (#25028), just as we already do via Nitro on the server when deploying to non-Node environments.
That means that, within your client-side code, you can import directly from Node built-ins (node: and node imports are supported). However, nothing is globally injected for you, to avoid increasing your bundle size unnecessarily. You can either import them where needed.
import { Buffer } from 'node:buffer'
import process from 'node:process'
Or provide your own polyfill, for example, inside a Nuxt plugin.
// ~/plugins/node.client.ts
import { Buffer } from 'node:buffer'
import process from 'node:process'
globalThis.Buffer = Buffer
globalThis.process = process
export default defineNuxtPlugin({})
This should make life easier for users who are working with libraries without proper browser support. However, because of the risk in increasing your bundle unnecessarily, we would strongly urge users to choose other alternatives if at all possible.
We now allow you to opt-in to using the CookieStore. If browser support is present, this will then be used instead of a BroadcastChannel to update useCookie values reactively when the cookies are updated (#25198).
This also comes paired with a new composable, refreshCookie which allows manually refreshing cookie values, such as after performing a request. See full documentation.
In this release, we've also shipped a range of features to detect potential bugs and performance problems.
setInterval is used on server (#25259).<NuxtPage /> but have the vue-router integration enabled (#25490). (<RouterView /> should not be used on its own.)It's now possible to control view transitions support on a per-page basis, using definePageMeta (#25264).
You need to have experimental view transitions support enabled first:
export default defineNuxtConfig({
experimental: {
viewTransition: true
},
app: {
// you can disable them globally if necessary (they are enabled by default)
viewTransition: false
}
})
And you can opt in/out granularly:
// ~/pages/index.vue
<script setup lang="ts">
definePageMeta({
viewTransition: false
})
</script>
Finally, Nuxt will not apply View Transitions if the user's browser matches prefers-reduced-motion: reduce (#22292). You can set viewTransition: 'always'; it will then be up to you to respect the user's preference.
It's now possible to access routing metadata defined in definePageMeta at build-time, allowing modules and hooks to modify and change these values (#25210).
export default defineNuxtConfig({
experimental: {
scanPageMeta: true
}
})
Please, experiment with this and let us know how it works for you. We hope to improve performance and enable this by default in a future release so modules like @nuxtjs/i18n and others can provide a deeper integration with routing options set in definePageMeta.
With #24837, we are now opting in to the TypeScript bundler resolution which should more closely resemble the actual way that we resolve subpath imports for modules in Nuxt projects.
'Bundler' module resolution is recommended by Vue and by Vite, but unfortunately there are still many packages that do not have the correct entries in their package.json.
As part of this, we opened 85 PRs across the ecosystem to test switching the default, and identified and fixed some issues.
If you need to switch off this behaviour, you can do so. However, please consider raising an issue (feel free to tag me in it) in the library or module's repo so it can be resolved at source.
export default defineNuxtConfig({
future: {
typescriptBundlerResolution: false
}
})
As usual, our recommendation for upgrading is to run:
nuxi upgrade --force
This will refresh your lockfile as well, and ensures that you pull in updates from other dependencies that Nuxt relies on, particularly in the unjs ecosystem.
-->
tryUseNuxtApp composable (#25031)bundler module resolution (#24837)pages:routerOptions hook (#24922)setInterval is used on server (#25259)refreshCookie + experimental CookieStore support (#25198)useId composable (#23368)endsWith when checking for whitespace (#24746)prefers-reduced-motion (#22292)fallback in island response (#25296)defineModel option as it is now stable (#25306)hidden sourcemap values to vite (#25329)dedupe (#25334)instance.attrs in client-only components (#25381)callOnce callbacks (#25431)nuxt-client within template code (#25464)dependsOn (#25409)NuxtError (#25398)vue-router warning with routeRule redirect (#25391)useRequestEvent (#25480)useRuntimeConfig signatures (#25440)pages:routerOptions hook (#25509)currentRoute non-ref warning (#25337)@since annotations to exported composables (#25086)useAsyncData explanation (#25392)error.vue (#25320)error.vue (#25396).cjs extension for ecosystem.config (#25459)routeRules example of swr/isr (#25436)sharedPrerenderData (b0f50bec1)pages:routerOptions (46b533671)NuxtPage is not used when pages enabled (#25490)data-island-uid replacement (#25346)$fetch (a1fb399eb)> 3.9.3 is a hotfix release to address a regression with CSS in development
3.9.3 is a hotfix release to address a regression with CSS in development
As usual, our recommendation for upgrading is to run:
nuxi upgrade --force
This will refresh your lockfile as well, and ensures that you pull in updates from other dependencies that Nuxt relies on, particularly in the vue and unjs ecosystems.
data-island-uid for island children (#25245)> 3.9.2 is a regularly scheduled patch release.
3.9.2 is a regularly scheduled patch release.
As usual, our recommendation for upgrading is to run:
nuxi upgrade --force
This will refresh your lockfile as well, and ensures that you pull in updates from other dependencies that Nuxt relies on, particularly in the vue and unjs ecosystems.
Object.fromEntries (#24953)options in addTemplate (#25109)pages/ files in en-US locale (#25195)nextTick (#25197)data-island-component (#25232)<NuxtPage> rather than <RouterView> (#25106)@nuxt/bridge-edge (3f09ddc31)--log-level description (#25211)immediate: false in the appropriate example (#25224).global.vue filename for global components (#25144)lagon from deployment providers (#24955)definePageMeta (#25073)addDevServerHandler API (#25233)nuxi for bridge (637f5622d)v3 branch sandbox in issue template (#25174)> 3.9.1 is a regularly scheduled patch release.
3.9.1 is a regularly scheduled patch release.
As usual, our recommendation for upgrading is to run:
nuxi upgrade --force
This will refresh your lockfile as well, and ensures that you pull in updates from other dependencies that Nuxt relies on, particularly in the vue and unjs ecosystems.
useRequestHeaders (#24853)startsWith to array access (#24744)NuxtErrorBoundary with ssr: false (#24896)any in inferred injections (#25010)<ClientOnly> (#25009)currentRoute in Ref (#25026)nuxt-config-schema (#25067)features/future docs (f5676fba5)vue-router docs link (#24948)readValidatedBody and getValidatedQuery (#24990)getValidatedRouterParams (#25057)Remove deprecated loadNuxt options
3.9.0 is the next minor release.
A very merry Christmas to you and yours from all Nuxters involved in this release! 🎁🎄
We have lots of features packed into v3.9.0 and can't wait for you to try them out.
This release comes with Vite 5 and Rollup 4 support. Module authors may need to check to ensure that any vite plugins you're creating are compatible with these latest releases.
This comes with a whole host of great improvements and bug fixes - check out the Vite changelog for more info.
This release is tested with the latest Vue 3.4 release candidate, and has the necessary configuration to take advantage of new features in Vue 3.4, including debugging hydration errors in production (just set debug: true) in your Nuxt config.
👉 To take advantage, just update your vue version once v3.4 is released, or try out the release candidate today:
{
"dependencies": {
"nuxt": "3.9.0",
"vue": "3.4.0-rc.1",
"vue-router": "latest"
}
}
This is a highly-experimental update, but it's now possible to play around with interactive components within Nuxt server components. You'll need to enable this new feature additionally to component islands:
export default defineNuxtConfig({
experimental: {
componentIslands: {
selectiveClient: true
}
}
})
Now, within a server component, you can specify components to hydrate by using the nuxt-client directive:
<NuxtLink :to="/" nuxt-client />
We're pretty excited about this one - so do let us know how you're using it! 🙏
We now use Vite's new AST-aware 'define' to perform more accurate replacements on server-side code, meaning code like this will no longer throw an error:
<script setup lang="ts">
if (document) {
console.log(document.querySelector('div'))
}
</script>
This hasn't been possible until now because we haven't wanted to run the risk of accidentally replacing normal words like document within non-JS parts of your apps. But Vite's new define functionality is powered by esbuild and is syntax-aware, so we feel confident in enabling this functionality. Nevertheless, you can opt out if you need to:
export default defineNuxtConfig({
hooks: {
'vite:extendConfig' (config) {
delete config.define!.document
}
}
})
We now have a new hook-based system for <NuxtLoadingIndicator>, including a useLoadingIndicator composable that lets you control/stop/start the loading state. You can also hook into page:loading:start and page:loading:end if you prefer.
You can read more in the docs and in the original PR (#24010).
callOnceSometimes you only want to run code once, no matter how many times you load a page - and you don't want to run it again on the client if it ran on the server.
For this, we have a new utility: callOnce (#24787).
<script setup>
const websiteConfig = useState('config')
await callOnce(async () => {
console.log('This will only be logged once')
websiteConfig.value = await $fetch('https://my-cms.com/api/website-config')
})
</script>
Note that this utility is context-aware so it must be called in component setup function or Nuxt plugin, as with other Nuxt composables.
For a while now, errors returned by useAsyncData and useFetch have been typed pretty generically as Error. We've significantly improved the type possibilities for them to make them more accurate in terms of what you'll actually receive. (We normalise errors with the h3 createError utility under the hood, so they can be serialised from server to client, for example.)
We've tried to implement the type change in a backwards compatible way, but you might notice that you need to update the generic if you're manually configuring the generics for these composables. See (#24396) for more information, and do let us know if you experience any issues.
We've taken some time in this release to make some minor performance improvements, so you should notice some things are a bit faster. This is an ongoing project and we have ideas for improving initial load time of the Nuxt dev server.
As usual, our recommendation for upgrading is to run:
nuxi upgrade --force
This will refresh your lockfile as well, and ensures that you pull in updates from other dependencies that Nuxt relies on, particularly in the unjs ecosystem.
<NuxtLayout> (#24116)addComponentsDir (#24309)useCookie (#24503)error.data when throwing 404 errors (#24674)/module or /nuxt module subpath if it exists (#24707)refresh on islands and server components (#24261)dedupe option for data fetching composables (#24564)undefined on server (#24711)addServerScanDir composable (#24001)setup within defineComponent options (#24515)useRequestHeader utility (#24781)callOnce util to allow running code only once (#24787)NuxtIsland (#22649)bundler module resolution (#22821)toArray util (#24857)resolve operation (#24736)join operation (#24717)get operations (#24734)useRuntimeConfig call (#24843)JSON.stringify operation (#24848)import.d.ts (#24413)reactivityTransform (vue 3.4) (#24477)<DevOnly> (#24511)isBuiltin polyfill for greater node support (#24512)<NuxtLayout> usage in islands (#24529)error in useAsyncData has correct type (#24396)appManifest middleware after modules run (#24786)setup within defineComponent (#24784)__VUE_PROD_HYDRATION_MISMATCH_DETAILS__ (#24836)mode from filePath for addComponent (#24835)bundler module resolution due to lack of support (22ce98d61)~/modules dirs to modulesDir (#24457)defineComponent to infer prop types for router-link stub (dc0e8347b)jiti.import for schema (#24526)process.* usage in nuxt vue app (#24749)future and features namespace (#24880)typedPages (#24436)defineNuxtConfig to deployment example (#24451)~ to @ alias in examples (#24574)-o option to --open (#24644)<NuxtPage> (#24675)getCachedData option (#24697)addServerScanDir example (7cd02e290)loadNuxt options (#24201)nuxi module (#24790)useFetch and useAsyncData #24407 (#24775, #24407)addComponentsDir example to modules author guide (#24876)dev:prepare instead of build:stub (802b3e28c)nuxt/bridge when composables change (#24752)> 3.8.2 is a patch release focusing on bug fixes
3.8.2 is a patch release focusing on bug fixes
3.8.2 is a patch release and we've deferred some exciting features in our next release (3.9.0, expected in December) but it does bring a significant Nitro minor release: v2.8.0. It's well worth checking out the release notes.
👉 Note that as Nitro has updated to rollup v4, but as Nuxt's vite dependency is still on rollup v3 until v3.9, you may experience type mismatches in modules or your projects if you are dependent on particular rollup plugins or plugin types.
As usual, our recommendation for upgrading is to run:
nuxi upgrade --force
This will refresh your lockfile as well, and ensures that you pull in updates from other dependencies that Nuxt relies on, particularly in the unjs ecosystem.
transformAssetUrls (#24173)createError (#24093)plugins.d.ts if they will be written (#23943)typeof optimisations (#23903)KeepAlive cache (#24024)runtimeConfig type hints (#23696)useFetch key (#24307)useFetch key from headers (#23462, #24333)ignoreOptions (#24337)useFetch (#24364)useCookie timeout (#24253)app:error (#24376)import.meta (#24186).nuxtrc in nuxt/starter (56147b4a8)defineNuxtPlugin syntax in bridge migration (#23036)nuxt3-vuex-module in migration guide (#24260).gitignore in directory structure (#24338)app.config placement with custom srcDir (#24252)<ContentDoc> in example (#24244)@nuxt/kit-nightly in example (bdedc3207)nuxi-edge to nuxi-nightly (#24347)@nuxt/test-utils to separate repo (#24146)repository fields in package.json (54529c17d)package.jsons (#24189)@nuxt/eslint-config (#24209)> 3.8.1 is a patch release focused on bug fixes and performance improvements.
3.8.1 is a patch release focused on bug fixes and performance improvements.
pages on nuxt app and deduplicate calls (#24032)extends (#23795)target: blank links with base (#23751)std-env to detect whether app is being tested (#23830).json extension for server components (#23802)@unhead/vue in template code (#23858)baseURL (#23884)cloneDeep again (#23888)$fetch at entry start (#23906)postcss-url and duplicate postcss-import (#23861)useCookie value when it expires (#23549)h3 cors handler for vite routes only (#23995)addServerImportsDir implementation (#24000)isChangingPage util in scrollBehavior (#24091)useCookie (#24043)ClientFallback (#24086)typeCheck plugin (#24114)useRequestEvent() internally (#23916)useFetch key generation logic (#24082)addPrerenderRoutes name (#24102)NuxtIsland (#23801)Remove huntr + encourage GitHub vulnerability reporting
We have a lot of exciting features in v3.8, and can't wait for you to try it out.
Just to remind you, we're now using the new Nuxt CLI which is now versioned separately. There are some exciting improvements there to follow, so do check out the latest releases. (For example, we now share the same port with the Vite websocket, meaning better support for docker containers in development.)
Nuxt DevTools v1.0.0 is out and we now think it's ready to be shipped as a direct dependency of Nuxt.
👉 You can check out the release notes for more information - and stay tuned for an article detailing our roadmap for the future.
We've now made <NuxtImg> and <NuxtPicture> first-class built-in components, documenting them and auto-installing @nuxt/image the first time that they are used (#23717).
https://github.com/nuxt/nuxt/assets/28706372/597c9307-5741-4d9c-8eab-aad5bfef2ef2
We would definitely advise using @nuxt/image if you're using images in your site; it can apply optimisations to make your site more performant.
🚨 This is a behaviour change so do take care with this one: 🚨
We now support scanning layouts within subfolders in ~/layouts in the same way as we do with ~/components.
| File | Layout name |
|---|---|
| ~/layouts/desktop/default.vue | 'desktop-default' |
| ~/layouts/desktop-base/base.vue | 'desktop-base' |
| ~/layouts/desktop/index.vue | 'desktop' |
See #20190 for more information
We now support a built-in app manifest (see #21641), which generates a manifest at /_nuxt/builds/meta/<buildId>.json.
Initially this enables loading payloads only for prerendered routes, if a site is static (preventing 404s). It also enables client-side route rules. To begin with, only redirect route rules will have an effect; they will now redirect when performing client-side navigation. (More coming soon...!)
The app manifest also enables future enhancements including detection of outdated deployments by checking /_nuxt/builds/latest.json.
You can switch off this behaviour if you need to (but do let us know if you have any issues):
export default defineNuxtConfig({
experimental: {
appManifest: false
}
})
We now define a 'scope' for Nuxt composables executed in plugins (#23667), which allows running synchronous cleanup before navigating away from your site, using the Vue onScopeDispose lifecycle method. This should fix an edge case with cookies (#23697) and also improves memory management, for example in Pinia stores (#23650). You can read more about Vue effect scopes.
We also now support native async context for the Vue composition API (#23526). In case you're unaware, we support native async context on Node and Bun, enabled with experimental.asyncContext. This can help address issues with missing a Nuxt instance. But it didn't previously affect missing Vue instances.
If you experience issues with 'Nuxt instance unavailable', enabling this option may solve your issues, and once we have cross-runtime support we are likely to enable it by default.
export default defineNuxtConfig({
experimental: {
asyncContext: true
}
})
We've supported defining your own NuxtLink components with the defineNuxtLink utility. We now support customising the options for the built-in <NuxtLink>, directly in your nuxt.config file (#23724). This can enable you to enforce trailing slash behaviour across your entire site, for example.
export default defineNuxtConfig({
experimental: {
defaults: {
nuxtLink: {
activeClass: 'nuxt-link-active',
trailingSlash: 'append'
}
}
}
})
We have two very significant new features for useAsyncData and useFetch:
deep: false to prevent deep reactivity on the data object returned from these composables (#23600). It should be a performance improvement if you are returning large arrays or objects. The object will still update when refetched; it just won't trigger reactive effects if you change a property deep within the data.getCachedData option to handle custom caching for these composables (#20747)const nuxtApp = useNuxtApp()
const { data } = await useAsyncData(() => { /* fetcher */ }, {
// this will not refetch if the key exists in the payload
getCachedData: key => nuxtApp.payload.static[key] ?? nuxtApp.payload.data[key]
})
We also support configuring some default values for these composables in an app-wide way (#23725):
export default defineNuxtConfig({
experimental: {
defaults: {
useAsyncData: {
deep: false
},
useFetch: {
retry: false,
retryDelay: 100,
retryStatusCodes: [500],
timeout: 100
}
}
}
})
We now more carefully load layer plugins (#22889 and #23148) and middleware (#22925 and #23552) in the order of the layers, always loading your own plugins and middleware last. This should mean you can rely on utilities that layers may inject.
We've also added a test suite to cover these layer resolution changes.
And probably one of the most significant changes - if you are using remote layers we now clone these within your node_modules/ folder (#109) so layers can use dependencies with your project. See c12 release notes for full details.
Every commit to the main branch of Nuxt is automatically deployed to a new release, for easier testing before releases. We've renamed this from the 'edge release channel' to the 'nightly release channel' to avoid confusion with edge deployments. And probably also with Microsoft Edge (though I haven't heard that anyone was confused with that one!)
➡️ nuxt3 is now nuxt-nightly
➡️ nuxi-edge is now nuxi-nightly
➡️ @nuxt/kit-edge is now @nuxt/kit-nightly
... and so on.
You can read more about how it works.
Nitro v2.7 has been released with lots of improvements and bug fixes - do check out the full changelog.
🔥 One of the most significant is that we now save ~40% of bundle size in production by using native fetch (which is supported in Node 18+) (#1724). So if possible, we'd recommend you update your Node version to at least 18.
🚨 This is likely to need code changes in your project 🚨
Vue requires that type imports be explicit (so that the Vue compiler can correctly optimise and resolve type imports for props and so on). See core Vue tsconfig.json.
We've therefore taken the decision to turn on verbatimModuleSyntax by default in Nuxt projects, which will throw a type error if types are imported without an explicit type import. To resolve it you will need to update your imports:
- import { someFunction, SomeOptions } from 'some-library'
+ import { someFunction } from 'some-library'
+ import type { SomeOptions } from 'some-library'
You may also encounter modules in the Nuxt ecosystem that need to be updated; please open an issue for those modules. I'm also very happy to help if you're encountering any problems with this, if you're a module author. Just tag me and I'll take a look.
If for whatever reason you need to undo this change in your project you can set the following configuration:
export default defineNuxtConfig({
typescript: {
tsConfig: {
compilerOptions: {
verbatimModuleSyntax: false
}
}
}
})
However, we'd recommend only doing that temporarily, as Vue does need this option to be set for best results.
As usual, our recommendation for upgrading is to run:
nuxi upgrade
addServerImports and addServerImportsDir (#23288)prerenderRoutes ssr composable (#22863)appManifest by default (#23448)withAsyncContext (#23526)-nightly extension (#23508)@nuxt/devtools as dependency and enable (#23576)deep: false for data composables (#23600)@nuxt/image when it is used (#23717)<NuxtLink> options (#23724)asyncData errors with null (#23428)vue-router (#23440)config.autoImport in addServerImports (#23472)clearNuxtState called w/o keys (#23483)addPrerenderRoutes name (#23509)test/dev as manifest buildId when appropriate (#23512)<DevOnly> (#23466)useFetch (#23693)lodash-es + simplify postcss resolution (#23692)useAsyncData (#23351)prerenderedAt to override app manifest (#23781)prerenderedAt behaviour pending next patch (108b1bdf7)listhen options on nuxi dev page (#23415)handler for useAsyncData (#23389)nitro to use runtimeConfig (#23454)bridge.typescript option must be set. (#23503)nuxt kit section (#22375)/edge-channel page to /nightly-release-channel (#23648)routeRules example (818dc626c)<NuxtImg> and <NuxtPicture> (#23741)> 3.7.4 is a regularly scheduled patch release.
3.7.4 is a regularly scheduled patch release.
As usual, our recommendation for upgrading is to run:
nuxi upgrade
nuxt/* exports (#23357)consola and improve test dx (#23302)nuxt2 command (#23211)code-block in migration guide (#23224)callHook method (#23231)srcDir JSDoc (#23250)nuxtApp.runWithContext (#23258)devtools.nuxt.com (#23350)await to clarify sendRedirect is async (#23345)tryUseNuxt to kit context utils list (#23373)linkChecker job to link-checker (#23319)> 3.7.3 is a hotfix release to address a regression introduced in 3.7.2.
3.7.3 is a hotfix release to address a regression introduced in 3.7.2.
#components (#23188)> 3.7.2 is a regularly scheduled patch release.
3.7.2 is a regularly scheduled patch release.
As usual, our recommendation for upgrading is to run:
nuxi upgrade
joinURL with remote sources on NuxtIsland (#23093)data-v attrs from server component props (#23095)useFetch auto key (#23086)cssCodeSplit (#23049)spaLoadingTemplate if file exists (#23048)tsconfig.json defaults (#23121)0 (#23127)name param to PageMeta interface description (#23107)experimental.componentIslands (#23138)nuxi init command (#23155)> 3.7.1 is a regularly scheduled patch release.
3.7.1 is a regularly scheduled patch release.
As usual, our recommendation for upgrading is to run:
nuxi upgrade --force
This will refresh your lockfile as well, and ensures that you pull in updates from other dependencies that Nuxt relies on, particularly in the unjs ecosystem.
ssr: false (#22869)priority when registering components dirs (#22882)addLayout (#22902)true (#22905)write: false for type templates (#22972)shouldExternalize (#22991)destr in more places over JSON.parse (#22997)<NuxtPage> (#22912)pageKey (#22920)env object for nuxt plugins (#22963)NuxtLayout (#22989)GITHUB_REF_NAME to get branch for release (d49ea58de)We've refactored nuxi using unjs/citty and this marks the first Nuxt release that depends on the new version, safely in its own repository. We have gr
We've refactored nuxi using unjs/citty and this marks the first Nuxt release that depends on the new version, safely in its own repository. We have grand plans for this - check out some of the features + roadmap discussions in nuxt/cli and please feel free to contribute!
Nuxi is now decoupled from the main nuxt version - we plan to iterate and release nuxi more quickly in future so you can expect new things coming soon!
ResponseWith improvements in unjs/h3 and unjs/nitro, it's now possible to directly return a Response object from server routes, meaning it's also possible to return and handle streams natively in Nuxt.
👉 Check out the full detail in the unjs/h3 and unjs/nitro release notes.
This release comes with a couple of improvements in rendering HTML responses from the server. We now determine whether to preload/prefetch resources at build time (so you can customise this in the build:manifest hook). We also now manage rendering the HTML for them directly in unhead (#22179), which means you can configure the order for <link>, <meta>, <script>, <style>, and more. And - in our preliminary testing - it's even faster!
It's possible to opt-in to upcoming head improvements with the experimental.headNext flag. This currently includes a new ordering algorithm based on capo.js (#22431) and allows enabling future optimisations as they are released in unhead:
export default defineNuxtConfig({
experimental: {
headNext: true
}
})
We'd love your thoughts - you can respond with any issues/feedback in this discussion.
In your Nuxt config you can now use $client and $server shortcuts to easily define configuration that is specific to just the Vite client/server (#22302) or webpack client/server (#22304) builds. This previously was only possible with the vite:extendConfig and webpack:config hooks.
For example:
export default defineNuxtConfig({
vite: {
$client: {
build: {
rollupOptions: {
output: {
chunkFileNames: '_nuxt/[hash].js',
assetFileNames: '_nuxt/[hash][extname]',
entryFileNames: '_nuxt/[hash].js'
}
}
}
}
}
})
We've chosen to unpin Vite from minor versions, meaning whenever Vite releases a new feature version you can opt-in straight away. Vite 4.4 brings a lot of exciting things, including experimental Lightning CSS support - and much more!
👉 Check out the Vite release notes for more.
We now use purely relative paths in the generated tsconfig.json instead of setting a baseUrl. This means better support for dev environments like docker images where the absolute path may not match your IDE (#22410).
We also set a couple of additional compiler flag defaults to match Vite/TS recommendations (#22468).
Plus, you should now get type hinted access to layouts in setPageLayout and also in <NuxtLayout name> (#22363).
If you've ever got an issue with 'Nuxt context unavailable' this might be one for you. We now support native async context for Bun and Node under an experimental flag, in both Nuxt and Nitro (#20918).
This enables using Nuxt composables on the server without needing to ensure they are being called directly in a setup function. It also allows the same in Nitro, with a new useEvent() utility that is usable in server routes.
To try it out, you can enable experimental.asyncContext:
export default defineNuxtConfig({
experimental: {
asyncContext: true
}
})
We've fixed a couple of issues with watchers, meaning that you should need to restart your server less often - and you should see a significant performance increase if you are using layers.
There lots more exciting features coming directly from Nitro 2.6, including smaller, lighter servers and new persistent data storage in a .data directory.
👉 Read more in the full release article.
As usual, our recommendation for upgrading is to run:
npx nuxi upgrade --force
This will refresh your lockfile as well, and ensures that you pull in updates from other dependencies that Nuxt relies on, particularly in the unjs ecosystem.
$client and $server vite env overrides (#22302)$client and $server overrides (#22304)scrollToTop page meta (#21741)app:templatesGenerated hook (#21935)unhead (#22179)@nuxt/webpack-builder when needed (#21747)writeTypes utility (#22385)setPageLayout/<NuxtLayout> (#22362)import.meta.* build flags (#22428)node_modules (#22478)webpack/nitro/postcss config (#22521)global: 'sync' components (#22558)app.rootId optional (#22528)experimental.headNext unhead integration (#22620)bun package manager (#22673)routeRules defined within pages (#20391)hidden sourcemaps (#22787)nuxt/cli (#22799)./schema/config.schema.json subpath (#22813)nuxt/config (#22391)capo.js head tag order (#22431).toLowerCase() (#22743)prerender:routes hook (#22247)scrollBehaviorType (#22264)asyncData generic + default (#22258)createClientOnly render function to ctx (#22289)build.extend (#22305)validate return typing to be either error or boolean (#22323)hasNuxtModule (#22316)builder:watch (#22333)useFetch hash (#22378)watch paths against all layer srcDirs (#22307)name is an optional prop for <NuxtLayout> (0d9a0b753)useFetch (#22418)baseUrl and use relative paths in tsconfig (#22410)injectHead usage (#22447)useCookie (#22474)internal:nuxt namespace (9b0d371b0)normalize call (14bf2b02f)webpack options should be optional (#22524)app.config.ts files (#22494)hookable to externals list (4552d39c4)app.{rootId ([rootTag} (#22543)](https://github.com/nuxt/nuxt/commit/rootTag}` (#22543)))import.meta build vars in define as well (#22576)page:finish (#22566)distDir after first build (#22614)'' key for root scope in variable collector (#22679)exclude paths to nitro tsconfig.server.json (#22768)asyncData when immediate is disabled (#20980)spaLoadingTemplate to false (#22798)unctx where possible (#22811)nuxi-ng for edge releases (#22413)useNitroApp from subpath (#22785)#components import for dynamic component (#22231).env section (#22369)NuxtIsland (#22434)] in code-block filenames (#22389)scrollToTop (#22503)status type for useAsyncData (#22511)useSeoMeta parameters (#22513)pick (#22531)ReadMore components (#22541)addServerHandler example to modules author guide (#22603)server: false doesn't await on initial load (#22619)import.meta.* update until v3.7 release (98c17e5d4)NuxtIsland in server only components docs (#22685)useFetch docs (#22755)useAsyncData (#22760)nuxi (df2bc8a72).eslintignore file with 'ignorePatterns' (#22547)h3-nightly on edge releases (#22593)networkidle dependency (#22596)> 3.6.5 is a hotfix patch release addressing the regression with nuxt/content introduced in v3.6.4.
3.6.5 is a hotfix patch release addressing the regression with nuxt/content introduced in v3.6.4.
As usual, our recommendation for upgrading is to run:
nuxi upgrade --force
This will refresh your lockfile as well, and ensures that you pull in updates from other dependencies that Nuxt relies on, particularly in the unjs ecosystem.
dist from the default ignore list (#22227)> 3.6.4 is a patch release, brought forward to allow releasing some important bug fixes before work begins on 3.7.
3.6.4 is a patch release, brought forward to allow releasing some important bug fixes before work begins on 3.7.
Warning We're currently investigating a regression with nuxt/content and will be releasing 3.6.5 later today.
As usual, our recommendation for upgrading is to run:
nuxi upgrade --force
This will refresh your lockfile as well, and ensures that you pull in updates from other dependencies that Nuxt relies on, particularly in the unjs ecosystem.
buildDir and node_modules (#22214)toLowerCase for possible moduleResolution (#22160)baseURL to island fetch requests (#22009)--inspect in dev mode (#22205)> 3.6.3 is the next patch release, including a number of fixes. It's anticipated this will be the last patch release before 3.7.
3.6.3 is the next patch release, including a number of fixes. It's anticipated this will be the last patch release before 3.7.
As usual, our recommendation for upgrading is to run:
nuxi upgrade --force
This will refresh your lockfile as well, and ensures that you pull in updates from other dependencies that Nuxt relies on, particularly in the unjs ecosystem.
unctx options (4e32e70bb)isExternal (#21966)experimental option (0643d4315)bundler module resolution flag (#22142)/ (#22118)> 3.6.2 is the next patch release, with a raft of fixes including preparations for use without --shamefully-hoist and some fixes for data fetching wit
3.6.2 is the next patch release, with a raft of fixes including preparations for use without
--shamefully-hoistand some fixes for data fetching within nested layouts/pages.
As usual, our recommendation for upgrading is to run:
nuxi upgrade --force
This will refresh your lockfile as well, and ensures that you pull in updates from other dependencies that Nuxt relies on, particularly in the unjs ecosystem.
@nuxt/ui-templates from modulesDir (#21836)nuxi generate (#21860)tsconfig.json scope (#21917)typedPages (#21659)node_modules to tsconfig include (#21929)$fetch.raw in dev client mode for islands (#21904)vite.publicDir (#21847)spaLoadingTemplate link (#21845)<NuxtLoadingIndicator> (#21952)nuxt-vitest and composable unit tests (#21884)> 3.6.1 is a bugfix/patch release with some significant patches merged since 3.6.0
3.6.1 is a bugfix/patch release with some significant patches merged since 3.6.0
As usual, our recommendation for upgrading is to run:
nuxi upgrade --force
This will refresh your lockfile as well, and ensures that you pull in updates from other dependencies that Nuxt relies on, particularly in the unjs ecosystem.
typescript dep (#21729)false to disable spa loading template (#21739)path from SPA payload (#21732)ssr: false route rule (#21763)#imports (#21796)defineNuxtRouteMiddleware migration (#21718)Remove example of deprecated reactivity transform
3.6.0 is the next minor release, packed with improvements and bug fixes.
In the coming week you can expect two announcements:
nuxt/cli by @pi0 - a new, drop-in replacement for nuxi featuring more extensibility and better DX. We are aiming to release this alongside Nuxt 3.7, but you would be very welcome to test and contribute to nuxi-ng before then!This minor release contains quite a lot, and we have big plans
If your site is served with ssr: false or you have disabled server-rendering on some of your pages, you might be particularly interested in the new built-in SPA loading indicator.
You can now place an HTML file in ~/app/spa-loading-template.html with some HTML you would like to use to render a loading screen that will be rendered until your app is hydrated on these pages.
👉 By default an animated Nuxt icon is rendered. You can completely disable this indicator by setting spaLoadingTemplate: false in your nuxt configuration file.
The first thing that happens when your app is hydrated is that your plugins run, and so we now perform build-time optimisations on your plugins, meaning they do not need to be normalised or reordered at runtime.
We also include your error component JS in your main entrypoint, meaning that if an error occurs when a user has no connectivity, you can still handle it with your ~/error.vue. (This also should decrease your total bundle size.)
👉 Compared to Nuxt 3.5.3, the minimal client bundle has decreased by ~0.7kB. Let's keep this up!
It has been possible to use server components on static pages, but until now they would increase the payload size of your application. That is no longer true. We now store rendered server components as separate files, which are preloaded before navigation.
👉 This does rely on the new, richer JSON payload format, so make sure you have not disabled this by setting experimental.renderJsonPayloads to false.
If you're monitoring your metrics closely and have not turned off experimental.inlineSSRStyles, you should see more CSS inlined in your page, and a significantly external CSS file. We're now better at deduplicating global CSS, particularly added by libraries like tailwind or unocss.
To give you more fine-grained control over your page/layout components, for example to create custom transitions with GSAP or other libraries, we now allow you to set pageRef on <NuxtPage> and layoutRef on <NuxtLayout. These will get passed through to the underlying DOM elements.
Up to now, running nuxt generate produced the same output on every deployment provider, but with Nuxt 3.6 we now enable static provider presets automatically. That means if you are deploying a static build (produced with nuxt generate) to a supported provider (currently vercel and netlify with cloudflare and github pages coming soon) we'll prerender your pages with special support for that provider.
This means we can configure any route rules (redirects/headers/etc) that do not require a server function. So you should get the best of both worlds when deploying a site that doesn't require runtime SSR. It also unblocks use of Nuxt Image on Vercel (with more potential for automatic provider integration coming soon).
We now have better support for server-specific #imports and augmentations if you are using the new ~/server/tsconfig.json we shipped in Nuxt 3.5. So when importing from #imports in your server directory, you'll get IDE auto-completion for the right import locations in Nitro, and won't see Vue auto-imports like useFetch that are unavailable within your server routes.
You should now also have type support for runtime Nitro hooks.
Finally, we have removed more locations where objects had a default any type. This should improve type safety within Nuxt in a number of locations where unspecified types fell back to any:
RuntimeConfigPageMetaNuxtApp['payload'] (accessible now from NuxtPayload interface)ModuleMetaYou can find out more about how to update your code if this affects you in the original PR.
This release ships with new Nitro 2.5, which has a whole list of exciting improvements that are worth checking out.
Of particular note is experimental support for streaming, which is also enabled by a couple of changes in Nuxt itself.
This release brings a number of utilities for modules authors to easily add type templates and assert compatibility with a given version of another module.
In addition, this release will finally unlock a new nuxt/module-builder mode that should improve type support for module authors. If you're a module author, you might consider following these migration steps to try it out in the coming days.
As usual, our recommendation for upgrading is to run:
nuxi upgrade --force
This will refresh your lockfile as well, and ensures that you pull in updates from other dependencies that Nuxt relies on, particularly in the unjs ecosystem.
useCookie state between tabs (#20970)renderResult to app:rendered (#18610)esbuild-loader options (#21436)open option in navigateTo helper (#21333)clearNuxtState composable (#21409)addTypeTemplate helper with auto-registration (#21331)status from useAsyncData (#21045)NuxtPage ref via pageRef (#19403)NuxtLayout ref via layoutRef (#19465)ssr-error event (#21547)defineNuxtModule (#20763)useNuxtApp to window for convenience (#21636)resolveId workaround and update vite-node (#21423)nitro.autoImport option (#21485)dst not src (#21501)navigateTo (#21500)window.location (#21521)<Title> (#21613): in rendered server components (for win) (#21645)baseUrl in tsconfig.json (#21632)BroadcastChannel (#21653)@typescript-eslint/typescript-estree (#21664)res.end() calls with check if event is handled (#21665)redirect type for NuxtPage type (#21713)render when defining rendering (#21490)addTypeTemplate typos (#21520)nuxt with bridge if nitro is false (#21586)parallel option on plugins (#21622)examples/ from repository (#21538)@latest to install commands (#21702)vitest renovate group (7695aca93)octokit/request-action (dd5955caf)webpack-dev-middleware updates on 2.x branch (7f7ae96d1)> 3.5.3 is expected to be the last patch release before our next raft of features lands in v3.6.
3.5.3 is expected to be the last patch release before our next raft of features lands in v3.6.
As usual, our recommendation for upgrading is to run:
nuxi upgrade --force
This will refresh your lockfile as well, and ensures that you pull in updates from other dependencies that Nuxt relies on, particularly in the unjs ecosystem.
--no-clear config through to vite (#21262)vue-loader options type (#21363)typeCheck (#21064)std-env in runtime code (#21372)lodash.template from lodash-es (#20892)index.vue to page routing example (#21240)$fetch and fetch composables (#21228)env property to match runtimeConfig (#21265)> 3.5.2 is a patch release focusing on bug fixes.
3.5.2 is a patch release focusing on bug fixes.
As usual, our recommendation for upgrading is to run:
nuxi upgrade --force
This will refresh your lockfile as well, and ensures that you pull in updates from other dependencies that Nuxt relies on, particularly in the unjs ecosystem.
.test and hoist regexps where possible (#21011)@default jsdoc tag (#21010)pages/ integration (397c54c9d)<DevOnly> with webpack (#21013)refreshNuxtData (#21008)abortNavigation (#21047)Set-Cookie header if value is null (#21072)render:island hook (#21065)> 3.5.1 is a patch release, with bug fixes and performance improvements.
3.5.1 is a patch release, with bug fixes and performance improvements.
As usual, our recommendation for upgrading is to run:
nuxi upgrade --force
This will refresh your lockfile as well, and ensures that you pull in updates from other dependencies that Nuxt relies on, particularly in the unjs ecosystem.
/ route (#20894)useFetch method when generic is passed (#20797)refresh when hydrating when data is present (#20916)default type for initial value for composables (#20968)resolvePath to handle edge cases for modules (#20975)pnpm test command to run whole test suite (4907660ff)experimental.renderJsonPayloads (891ba880e)useAsyncData and useFetch types (#20935)useState (#20249)pages/ docs (#20976)…the webpack builder. We are now explicitly deprecating this and will remove it in a future minor version.
3.5.0 is a minor (feature) release with lots of new features to play with.
Vue 3.3 has been released, with lots of exciting features, particularly around type support. This also brings a significant improvement to data fetching when navigating between nested pages (https://github.com/nuxt/nuxt/pull/20777), thanks to @antfu and @baiwusanyu-c.
defineOptions macroRead the full release announcement for more details.
We've been working on lots of improvements to Nitro and these have landed already in Nitro v2.4 - you may already have this upgrade, which contains a lot of bug fixes, updates to the module worker format for Cloudflare, Vercel KV support and more.
One note: if you're deploying to Vercel or Netlify and want to benefit from incremental static regeneration, you should now update your route rules:
routeRules: {
-- '/blog/**': { swr: 3000 },
++ '/blog/**': { isr: 3000 },
}
Read the full release notes.
Rich JSON payload serialisation is now enabled by default (https://github.com/nuxt/nuxt/pull/19205, https://github.com/nuxt/nuxt/pull/20770). This is both faster and allows serialising complex objects in the payload passed from the Nuxt server to client (and also when extracting payload data for prerendered sites).
This now means that various rich JS types are supported out-of-the-box: regular expressions, dates, Map and Set and BigInt as well as NuxtError - and Vue-specific objects like ref, reactive, shallowRef and shallowReactive.
You can find an example in our test suite.
This is all possible due to Rich-Harris/devalue#58. For a long time, Nuxt has been using our own fork of devalue owing to issues serialising Errors and other non-POJO objects, but we now have transitioned back to the original.
You can even register your own custom types with a new object-syntax Nuxt plugin:
export default definePayloadPlugin(() => {
definePayloadReducer('BlinkingText', data => data === '<original-blink>' && '_')
definePayloadReviver('BlinkingText', () => '<revivified-blink>')
})
You can read more about how this works here.
This feature should be considered highly experimental, but thanks to some great work from @huang-julien we now support interactive content within server components via slots (https://github.com/nuxt/nuxt/pull/20284).
You can follow the server component roadmap at https://github.com/nuxt/nuxt/issues/19772.
You can now configure fully typed, per-environment overrides in your nuxt.config:
export default defineNuxtConfig({
$production: {
routeRules: {
'/**': { isr: true }
}
},
$development: {
//
}
})
If you're authoring layers, you can also use the $meta key to provide metadata that you or the consumers of your layer might use.
Read more: https://github.com/nuxt/nuxt/pull/20329.
You can benefit from fully typed routing within your Nuxt app via this experimental integration with https://github.com/posva/unplugin-vue-router - thanks to some great work from @posva! Out of the box, this will enable typed usage of navigateTo, <NuxtLink>, router.push() and more. You can even get typed params within a page by using const route = useRoute('route-name').
export default defineNuxtConfig({
experimental: {
typedPages: true
}
})
We now have full support within Nuxt for the bundler strategy of module resolution. We would recommend adopting this if possible. It has type support for subpath exports, for example, but more exactly matches the behaviour of build tools like Vite and Nuxt than Node16 resolution.
export default defineNuxtConfig({
typescript: {
tsConfig: {
compilerOptions: {
moduleResolution: 'bundler'
}
}
}
})
This turns on TypeScript's ability to 'follow' Node subpath exports. For example, if a library has a subpath export like mylib/path that is mapped to mylib/dist/path.mjs then the types for this can be pulled in from mylib/dist/path.d.ts rather than requiring the library author to create mylib/path.d.ts.
We plan to improve clarity within your IDE between the 'nitro' and 'vue' part of your app, and we've shipped the first part of this via a separate generated tsconfig.json for your ~/server directory (https://github.com/nuxt/nuxt/pull/20559). You can use by adding an additional ~/server/tsconfig.json with the following content:
{
"extends": "../.nuxt/tsconfig.server.json"
}
Although right now these values won't be respected when type checking, you should get better type hints in your IDE.
Although we have not typed or documented the build.extend hook from Nuxt 2, we have been calling it within the webpack builder. We are now explicitly deprecating this and will remove it in a future minor version.
As usual, our recommendation for upgrading is to run:
nuxi upgrade --force
This will refresh your lockfile as well, and ensures that you pull in updates from other dependencies that Nuxt relies on, particularly in the unjs ecosystem.
prepend option to addImportsDir (#20307)vite:configResolved hook (#20411)webpack:configResolved hook (#20412)addVitePlugin and addWebpackPlugin (#20525)nuxi analyze from cli (#20387)nuxtApp.runWithContext (#20608)typedPages option (#20367)runWithContext within callWithNuxt (#20775)useRequestURL helper (#20765)<DevOnly> (#20817)addBuildPlugin for builder-agnostic implementation (#20587)NuxtClientFallback (#20336)@nuxt/devtools module before core modules (#20595)<FragmentWrapper> (#20607)useError is called with nuxt app context (#20585)nuxt_component ssr style and isVue (#20679)build.extend hook (#20605)fs.allow dirs to include app files (#20755).env changes (#20501)<DevOnly> from parsed html (#20840)pages:extend to enable pages module (#20806)scrollBehavior (#20859)runtimeCompiler option out of experimental (#20606)resolvePath (#20756)useCookie does not share state (#20665)navigateTo examples (#20678)useSeoMeta and useServerSeoMeta pages (#20656)<NuxtLayout> when migrating error.vue (#20690)await before lazy composable examples (7e7e006e9)pinia (#20778)markdownlint-cli update and prevent auto-update (675445f98)@ts-ignore (4f0d3d4ae).only in tests (ad97cb45a).mjs files (#20711)pnpm-workspace.yaml (#20751)externalVue removal (a33d2e7ae)> 3.4.3 is a patch release with the latest bug fixes. 🐞 It is expected that the next release will be v3.5, in approximately two weeks' time.
3.4.3 is a patch release with the latest bug fixes. 🐞 It is expected that the next release will be v3.5, in approximately two weeks' time.
As usual, our recommendation for upgrading is to run:
nuxi upgrade --force
This will refresh your lockfile as well, and ensures that you pull in updates from other dependencies that Nuxt relies on, particularly in the unjs ecosystem.
timeEnd unless we're debugging (#20424)<ClientOnly> (f1ded44e8)event.node.req in cookie utility (#20474)devServer.https: true (#20498)/__nuxt_error directly (#20497)callAsync for executing hooks with context (#20510)app:error in SSR before rendering error page (#20511)asyncData (#20535)#components imports into direct component imports (#20547)RenderResponse for redirects (#20496)vue-router docs (#20454)nuxt-edge with provenance (753c4c2a3)> 3.4.2 is a patch release with the latest bug fixes and performance improvements
3.4.2 is a patch release with the latest bug fixes and performance improvements
Apart from the normal bug fixes, we have a couple things we should call out.
@parcel/watcher for the Nuxt dev watcher (#20179). This may improve performance if you're on Windows. You'll probably also want to install watchman in that case.As usual, our recommendation for upgrading is to run:
nuxi upgrade --force
This will refresh your lockfile as well, and ensures that you pull in updates from other dependencies that Nuxt relies on, particularly in the unjs ecosystem.
@parcel/watcher for dev watcher (#20179)useRequestHeaders keys as optional (#20286)@jest/globals (#20360)rootDir when preparing project (#20401)isJS and isVue utilities consistently (#20344)isFileServingAllowed util (#20414)@ts-ignore and fix some issues (#20273)> 3.4.1 is a patch release. We've pulled it forward slightly to fix a couple of breaking bugs in 3.4.0.
3.4.1 is a patch release. We've pulled it forward slightly to fix a couple of breaking bugs in 3.4.0.
ssrContext in spa renderer (#20216)<NuxtClientFallback> (#20237)vue-router normalises url (#20247)transform/pick (#20186)We've removed the (deprecated) `#head` alias and also disabled the polyfill for `@vueuse/head` behaviour by default. (It can still be enabled with exp…
3.4.0 is a minor (feature) release for Nuxt 3 bringing exciting new features, including support for the View Transitions API, transferring rich JavaScript payloads from server to client - and much more.
https://user-images.githubusercontent.com/904724/231222082-6bd4aeae-3026-407e-b3be-658df6305748.mp4
<br>
You can see a demo on https://nuxt-view-transitions.surge.sh
You may have noticed that Chromium-based browsers now ship a new web platform API: the View Transitions API. This is an exciting new ability for native browser transitions which (among other things) have the ability to transition between unrelated elements on different pages.
Nuxt now ships with an experimental implementation, which will be under active development during the v3.4 release cycle. See the known issues in the linked PR.
export default defineNuxtConfig({
experimental: {
viewTransition: true
}
})
We've merged a significant change to how Nuxt handles payloads (under an experimental flag). Payloads are used to send data from the server to the client when doing server-side rendering and avoid double data-fetching during the hydration phase.
export default defineNuxtConfig({
experimental: {
renderJsonPayloads: true
}
})
With this new option enabled, this now means that various rich JS types are supported out-of-the-box: regular expressions, dates, Map and Set and BigInt as well as NuxtError - and Vue-specific objects like ref, reactive, shallowRef and shallowReactive.
You can find an example in our test suite.
This is all possible due to Rich-Harris/devalue#58. For a long time, Nuxt has been using our own fork of devalue owing to issues serialising Errors and other non-POJO objects, but we now have transitioned back to the original.
You can even register your own custom types with a new object-syntax Nuxt plugin:
export default definePayloadPlugin(() => {
definePayloadReducer('BlinkingText', data => data === '<original-blink>' && '_')
definePayloadReviver('BlinkingText', () => '<revivified-blink>')
})
You can read more about how this works here.
Note: this only affects payloads of the Nuxt app, that is, data stored within useState, returned from useAsyncData or manually injected via nuxtApp.payload. It does not affect data fetched from Nitro server routes via $fetch or useFetch although this is one area I am keen to explore further.
Preliminary testing shows a significant speed-up: 25% faster in total server response time for a very minimal app with a large JSON payload, but I'd urge you to run your own tests and share the results with us.
As mentioned, we're merging this behind a flag so we can test this broadly and gather feedback on the new approach. The most significant potential change is that the payload is now no longer available on window.__NUXT__ immediately. Instead, we now need to initialise the Nuxt app to parse the payload so any code that accesses __NUXT__ will need to be run in a plugin or later in the Nuxt app lifecycle. Please feel free to raise an issue if you foresee or encounter issues in your projects.
We now support object-syntax Nuxt plugins for better control over plugin order and easier registration of hooks.
export default defineNuxtPlugin({
name: 'my-plugin',
enforce: 'pre', // or 'post'
async setup (nuxtApp) {
// this is the equivalent of a normal functional plugin
},
hooks: {
// You can directly register Nuxt app hooks here
'app:created'() {
const nuxtApp = useNuxtApp()
//
}
}
})
In future we plan to enable build optimizations based on the metadata you pass in your Nuxt plugins.
It's even easier to enable Nuxt DevTools in your project: just set devtools: true in your nuxt.config file to enable devtools.
export default defineNuxtConfig({
devtools: true
})
If it's not already installed, Nuxt will prompt to install it locally. This means you no longer need to have Nuxt DevTools enabled globally.
Note: the DevTools is still experimental and under active development, so do be prepared for occasional unexpected behaviour, and please report issues directly to https://github.com/nuxt/devtools 🙏
We now support transforming ~/~~/@/@@ aliases within layers, meaning you now no longer need to use relative paths when importing within layers.
This should mean it is much easier to use a 'normal' Nuxt project as a layer without needing to specially write it as one.
We now transform certain keys of definePageMeta and defineNuxtComponent which means you should have fewer issues with a missing Nuxt instance. This includes support accessing the Nuxt instance after an await within asyncData and setup functions for those still using the Options API. And you no longer need to wrap middleware and validate with defineNuxtRouteMiddleware when using async functions.
As usual, this release will pull in upstream improvements, including the new Consola v3 and Nitropack v2.3.3 (a new minor is expected shortly).
We've also taken the opportunity to do some cleanup in this minor release.
x-nuxt-no-ssr header (undocumented) to force SPA rendering. We've now disabled this behaviour by default but you can get it back by setting experimental.respectNoSSRHeader to true. Alternatively, you can set event.context.nuxt.noSSR on the server to force SPA rendering.#head alias and also disabled the polyfill for @vueuse/head behaviour by default. (It can still be enabled with experimental.polyfillVueUseHead.)experimental.viteNode option. It can be configured instead with vite.devBundler.public key. This was an undocument compatibility measure with Nuxt 2 and we plan to remove it entirely in v3.5.As usual, our recommendation for upgrading is to run:
nuxi upgrade --force
This will refresh your lockfile as well, and ensures that you pull in updates from other dependencies that Nuxt relies on, particularly in the unjs ecosystem.
With Nuxt v3.4.0, we now advise that you explicitly install the @types/node version that matches your Node version.
useRoute is used in middleware (#20050)watch with useFetch (#19823)~/~~/@/@@ aliases within layers (#19986)dir.pages in page placeholder (#20079)devtools when it's enabled (#20126)experimentalNoScripts route rule (#19805)@vueuse/head polyfill by default (#20131)x-nuxt-no-ssr header by default (#20024)$config object (#20081)useFetch (#20052)@types/node as a peerDependency (#20025)any (#20105).client component placeholders (#20093)undefined type for useCookie return value (4f0b3c722)imports.autoImport (#20180)ignorePrefix to be changed (#20202)imports configuration (#20073)headers option for useFetch (#20148)@pinia/nuxt module name (#20199)overrides (4a6f85277)overrides (a15a9b66f)JITI_ESM_RESOLVE (#20172)head_ref for dependency deduping (ae5df72c5)> 3.3.3 is your regularly scheduled bugfix/patch release.
3.3.3 is your regularly scheduled bugfix/patch release.
As usual, our recommendation for upgrading is to run:
nuxi upgrade --force
This will refresh your lockfile as well, and ensures that you pull in updates from other dependencies that Nuxt relies on, particularly in the unjs ecosystem.
setResponseStatus signature with h3 (#19987)pages:extend example (72724076b)mkdist to 1.2.0 (a96451d2d)Removing deprecated coming soon banner
3.3.2 is a patch release with plenty of bug fixes.
As usual, our recommendation for upgrading is to run:
nuxi upgrade --force
This will refresh your lockfile as well, and ensures that you pull in updates from other dependencies that Nuxt relies on, particularly in the unjs ecosystem.
performance.mark() (#19687)h3 utilities to set response status/code (#19713)useAsyncData (#19225)$fetch in top-level <script setup> (#19357)return statement (fc7867fb0)@nuxt/kit example with node built-ins (#19873)…we've dropped support for some internal (deprecated) utilities using CJS resolve patterns (https://github.com/nuxt/nuxt/pull/19537, https://github.com…
3.3.0 is a minor (feature) release with lots of new features to play with. 3.3.1 was a swiftly following release to patch an issue with nuxi on Windows.
We've landed a raft of changes to enable local modules and improve DX. We now auto-scan your ~/modules folder and register top level files there as modules in your project (https://github.com/nuxt/nuxt/pull/19394). When these files are changed, we'll automatically restart the nuxt server.
export default defineNuxtConfig({
modules: [
'@nuxtjs/tailwindcss',
- '~/modules/purge-comments'
]
})
We also now expose nuxt/kit for easy access to kit composables in your local project without having to install @nuxt/kit (https://github.com/nuxt/nuxt/pull/19422).
You can add files to the watch array to automatically restart the server (https://github.com/nuxt/nuxt/pull/19530). This is likely to be particularly useful for module authors. You can also trigger a restart of the Nuxt server with the new restart hook (https://github.com/nuxt/nuxt/pull/19084). We also landed a couple of fixes on restarting the Nuxt server which should improve your experience when developing.
We've increased static asset maxAge to 1yr as a matter of best practice (https://github.com/nuxt/nuxt/pull/19335), and support tree-shaking more of your build (https://github.com/nuxt/nuxt/pull/19508). We also now support preloading <NuxtLink>s with a route in object-syntax (https://github.com/nuxt/nuxt/pull/19120).
We also track how long it takes each module you use to perform its setup, and warn if it takes too long. You can see all these values by running your dev server with DEBUG=1
You can also opt-in to some of Nuxt's internal optimisations by configuring composables to be treeshaken in a particular environment (https://github.com/nuxt/nuxt/pull/19383), or to have magic keys automatically injected (https://github.com/nuxt/nuxt/pull/19490) - primarily useful for module authors.
We now handle chunk errors by default (https://github.com/nuxt/nuxt/pull/19086), meaning if your site updates with a redeploy, we automatically handle reloading it on navigation. You can disable this and handle it yourself with the new reloadNuxtApp composable. You can also set experimental.restoreState to preserve some of your app state across reloads.
We also have a new experimental error handling component: <NuxtClientFallback> (https://github.com/nuxt/framework/pull/8216) which can capture errors rendering on server, replace them with fallback content, and granularly trigger rerendering the part with an error on the client. This can be enabled with experimental.clientFallback - feedback very welcome!
We've migrated to use unhead directly (https://github.com/nuxt/nuxt/pull/19519) - and automatically tree-shake server-only head composables like useServerHead from your client build (https://github.com/nuxt/nuxt/pull/19576), meaning you can have great SEO without needing to include meta tag logic that's relevant only for crawlers in your client build.
There's also a new useHeadSafe composable that handles santising untrusted user input (https://github.com/nuxt/nuxt/pull/19548).
Working with the Chrome DevTools team, we've landed a couple of features across the unjs + Nuxt ecosystem meaning we now have first-class support for hiding Nuxt internal stack traces from logs in your (Chromium-based, for now) browser (https://github.com/nuxt/nuxt/pull/19243). We also landed a couple of improvements with stacktraces involving Nuxt hooks (https://github.com/unjs/hookable/pull/69 and https://github.com/unjs/hookable/pull/68) implementing console.createTask.
| Before | After |
|---|---|
Types for server API routes are now more correct - with non-serialisable types stripped out of the return type (https://github.com/unjs/nitro/pull/1002).
We also now type more of NuxtApp and correctly type unknown injections for greater type-safety (https://github.com/nuxt/nuxt/pull/19643).
And if you were struggling with correct types when using transform + default with Nuxt data fetching composables, fear no more - we now infer the types correctly (https://github.com/nuxt/nuxt/pull/19487).
This release comes with Nitro v2.3, which brings lots of improvements of its own. Check out the release for more info.
We now support useAppConfig in nitro server routes (https://github.com/nuxt/nuxt/pull/19489) - a long-awaited change. Now useAppConfig is consistently available throughout your app for non-runtime configuration from layers, modules, etc.
We've also added a nitro:build:public-assets hook to allow modifying assets output from nitro's prerender/build phase (https://github.com/nuxt/nuxt/pull/19638).
As part of moving towards first-class support for PNP and pnpm support without --shamefully-hoist, we've dropped support for some internal (deprecated) utilities using CJS resolve patterns (https://github.com/nuxt/nuxt/pull/19537, https://github.com/nuxt/nuxt/pull/19608). We also now resolve dependencies like nuxt, @nuxt/kit and more using ESM search-paths. We'll be keeping a close eye on this.
We're also preparing the groundwork for support of new TypeScript Node16 module resolution (https://github.com/nuxt/nuxt/issues/19606), and as part of this have changed the format of our runtime output (using .js instead of .mjs extensions, providing types fields for subpath exports, and more).
We've been testing out an experimental feature to allow modules and users to extend the Nuxt config schema (https://github.com/nuxt/nuxt/issues/15592), and we've now enabled this by default (https://github.com/nuxt/nuxt/pull/19172). We expect this will be particularly useful for module and layer/theme authors, and should result in some nicer DX for their users.
restart hook is called (#19084)versions to runtime nuxtApp (#19064)node_modules and buildDir to x_google_ignoreList (#19243)nuxt/kit subpath for local use (#19422)~/modules (#19394)priority to allow overriding (#19252)trailingSlashBehavior in defineNuxtLink (#19458)logLevel (#19369)<NuxtClientFallback> component (#8216)watch option and refactor dev server restarting (#19530)useHeadSafe and remove layer around head imports (#19548)nitro:build:public-assets hook (#19638)@vueuse/head dependency (#19519)NuxtLink (#19379)import.meta types (#19338)/ from sourcemapIgnoreList for windows support (73ade185b)kit.* files to published package (#19430)transform (#19487)boolean from inline module definitions (#19621)payloadExtraction warning only when unset (#18516)versions and modules (#19448)routeRules (#19455)devServer.https example (#19486)~/server/utils directory in ~/utils page (#19500)addComponent jsdoc comment (#19503)--log-level (06b9233b1)@nuxt/test-utils package as external group (#19419)hasProtocol options format (#19555)Nothing published for this version
> 3.2.3 is a patch release with bug fixes and performance improvements.
3.2.3 is a patch release with bug fixes and performance improvements.
distDir is unlinked (#19131)<NuxtLink> (#19144)rel attribute on internal link (#19309)noExternal option (#19256)> 3.2.1 is a patch release with (lots of) bug fixes and performance improvements since last week's minor release.
3.2.1 is a patch release with (lots of) bug fixes and performance improvements since last week's minor release. 3.2.2 was a swiftly following release to patch an issue with
nuxi init
As a patch release, there are mostly bug fixes and performance improvements in the changelog. (Nevertheless, it's always worth reading through!) But one point of note is an experimental reload strategy when chunk errors are encountered. We're hoping to finalise the API and land it in v3.3 (our next feature release) with https://github.com/nuxt/nuxt/pull/19086, but you can test out an experimental version with the following config:
export default defineNuxtConfig({
experimental: {
emitRouteChunkError: 'reload'
}
})
With this strategy, your app will hard reload on route changes if there's a chunk error. More info at https://github.com/nuxt/nuxt/pull/19038.
app:chunkError hook and reload strategy (#19038)#components (#19008)nuxt/schema subpath for augmentation (#18922)statusCode is a number (#19001)nuxt/app by default (#19009)nuxt/app from optimised deps (9e789c76c)isCustomElement config for jsx transform (#19053)devServer options from nuxt config (#19055)// in path when constructing payload url (#19085)nuxi devtools command (#18888)static property (80f73d39c)sendRedirect usage (#19070)Nothing published for this version
> 3.2.0 is the first minor release since we've started our new release schedule. We've brought it forward by a couple of weeks to include some goodies
3.2.0 is the first minor release since we've started our new release schedule. We've brought it forward by a couple of weeks to include some goodies we want you to be able to play with soon.
⚡️ Nuxt DevTools
You can opt-in to Nuxt DevTools per-project by going to the project root and running:
npx nuxi@latest devtools enableRestart your Nuxt server and open your app in browser. Click the Nuxt icon on the bottom (or press
Alt+D) to toggle the DevTools.
More information in the docs!
✨ Better DX for overriding runtimeConfig, including inline type helpers <br><br><img src="https://user-images.githubusercontent.com/28706372/215903089-9f071c5f-50a1-45cd-841d-173f3b5e66db.png" width="65%">
🪄 Automatically inferred return type for useFetch and $fetch based on method.
It'll be a type error to use the wrong method when hitting an endpoint.
Plus, if you have multiple methods served by a single endpoint (like
~/server/api/test.get.tsand~/server/api/test.post.tsthen the response type will match the kind of response you make.
🍪 useFetch is now integrated with event.$fetch, meaning cookies and context are now passed to api requests automagically within internal requests.
🔥 We now treeshake client-only components out of the server build more effectively using the experimental treeshakeClientOnly feature
This is turned on by default but if you experience any issues, you can turn this off via:
export default defineNuxtConfig({ experimental: { treeshakeClientOnly: false } })
🛠️ New addRouteMiddleware kit utility for module authors
💪 Nitropack v2.2 has been released
Lots of features, including runtime proxy support using route rules, nested fetch calls, binary and raw storage operations, exposed
event.context.cf(cloudflare) and built-in session support.For full details see release notes
addRouteMiddleware method (#18553)ssr: false (#18783)useFetch return based on the method (#18526)ssr: false (#18782)ssr: false (#18828)<ClientOnly> (#8713)useError composable (#8912)preloadRouteComponents page heading error (#18804)> 3.1.2 is a patch release with bug fixes (particularly focusing on performance and DX).
3.1.2 is a patch release with bug fixes (particularly focusing on performance and DX).
defu in all places (#18624)__publicAssetsURL set before loading assets (#18642)_installedModules (#18647)onNuxtReady safe to run on server-side (#18706)vue-gtag plugin example (#18528)useHead (#18552)defineEventHandler() to avoid warnings (#18557)JSON.stringify() (#18590)@types/node manually (6b2bc680b).env to directory structure and improve config docs (#18594)head() (#18650)validate example (#18728)2.x branch name (727cf7958)assertNumber helper (aa646f065)nuxt-edge for nuxt v2 (dd0e2643c)> 3.1.1 is a bugfix release to address a problem rendering components injected by Vue or Nuxt plugins.
3.1.1 is a bugfix release to address a problem rendering components injected by Vue or Nuxt plugins.
There's also a Nitro upgrade to v2.1.0 released shortly after v3.1.1, so when upgrading, please either run nuxt upgrade --force or refresh your lockfile.
<NuxtPage> (#18495)vue (#18505)app.vue file name consistent (#18517)nuxt: Remove deprecated req/res access
3.1.0 is the first minor release after Nuxt 3.0 including bug fixes and enhancements.
onNuxtReady, useNuxtData and useSeoMeta composablesonNuxtReady composable (#9478)useNuxtData composable (#9262)useCookie ref value by default (#9664)imports:context hook for unimport context (#9971)build.transpile as function (#7767)extendRouteRules method (#9771)<NuxtLoadingIndicator> (#18432)useSeoMeta composable (#18441)@unhead/ssr (#9826)useServerSeoMeta composable (#18476)postcss.config from schema (#9181)<NuxtPage> component props (#9204)useCookie with defaults should return non-null value (#9449).nuxtignore within external layers (#9599)req/res access (#9636)<NuxtLoadingIndicator> after throttle (#9832)--template flag (#9946)runtime dir in build output (#10046)build.transpile strings to nitro inline list (#10094)definePageMeta (#9161)class prop type for head components (#9133)globalThis (#9627)ignore (#15884)sourcemap (#18446)callWithNuxt calls (#18443)onServerPrefetch (629d2c099)pathe.join for layer lookup (#9540)vue-meta for head support (#9638)globalThis (#9630)<NuxtLink> (#9869)commands/add (#9206)404.vue (#9155).client onMounted hook (#9263)layout in example of definePageMeta (#9322)imports.dirs (#9346)vite monospace too (#9490)@nuxt/test-utils (#9543)preloadRouteComponents (#9607)navigateTo options are optional (#9672)utils/ to directory-based auto-imports (#9739)pnpm (#9775)layouts typo in nuxtignore page (#9893)runtimeConfig extension in config-extends example (#9912)app.config.ts in the source directory (#9937)guide/.output (#9994)generate doc to include --dotenv (#9991)generate schema (#10002)Nuxt: A vision for 2023 post (#10141)ecosystem.config (#10076)nuxt.com (#18425)vue-lite-youtube-embed upgrade (6652983ba)2.x branch also (0fb147be4)nuxt/nuxt (081dc3254)nuxt/framework discussions (a683b1a20)issue-up on upstream vite repo (c28f1e429)3.x label to feature request template (fa129cb83)Your coding agent can read these notes before it upgrades. Set up the MCP server →