The Intuitive Vue Framework.
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.
routeRules
It'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].js',
entryFileNames: '_nuxt/[name].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.
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.
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.
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)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 usinguseAsyncData
to fetch data related to a particular page, you should provide a key that uniquely matches that data. (useFetch
should 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.options
It'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
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.
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)2.17.3 is the next patch release for the 2.x branch.
hookable
package (#24426)npm pkg fix
(4d0474c4b)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)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).
callOnce
Sometimes 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)