@clerk/nuxt: calling updateRuntimeConfig() in setup prints NUXT_B8003 "Nitro is not initialized yet" on Nuxt 4.5
@wobsoriano arbeitet bereits daran.
Seit 23.9.2026.
Bewertung
Dieses Issue wurde noch nicht bewertet.
Beschreibung
Preliminary Checks
- I have reviewed the documentation: https://clerk.com/docs
- I have searched for existing issues: https://github.com/clerk/javascript/issues
- I have not already reached out to Clerk support via email or Discord
- This issue is not a question, general help request, or anything other than a bug report directly related to Clerk
Reproduction
Inline below: three files, no Clerk account or key needed. The warning appears at build time.
Publishable key
N/A. The warning appears with no key configured.
Description
On Nuxt 4.5, every nuxt build and nuxt dev that loads @clerk/nuxt prints:
WARN [NUXT_B8003] Nitro is not initialized yet: useNitro() was called before the ready hook ran.
╰▶ fix: Move the useNitro() call inside a hook that runs after initialization, such as nuxt.hook('ready', () => { ... }).
Nothing is broken, because the runtime config is still applied. But the warning shows up in every consumer's build output, and it tells them to fix something that isn't in their code.
Cause
packages/nuxt/src/module.ts calls updateRuntimeConfig() from @nuxt/kit inside setup(). Nitro hasn't been created at that point. The kit helper does two things:
// packages/kit/src/runtime-config.ts (nuxt/nuxt main)
export function updateRuntimeConfig (runtimeConfig) {
const nuxt = useNuxt()
Object.assign(nuxt.options.nitro.runtimeConfig, defu(runtimeConfig, nuxt.options.nitro.runtimeConfig))
try {
return useNitro().updateConfig({ runtimeConfig })
} catch {
// Nitro is not yet initialised - we can safely ignore this error
}
}
The first line does the real work at setup time. The useNitro() call is for updating a Nitro instance that's already running, and it throws here. The catch swallows the error, but since the diagnostics rework (Nuxt 4.5), building kitDiagnostics.NUXT_B8003() reports the warning to the console before it's thrown. So the try/catch no longer keeps it quiet.
Steps to reproduce:
-
Create a project with these files:
package.json{ "private": true, "type": "module", "scripts": { "build": "nuxt build" }, "dependencies": { "nuxt": "4.5.2", "vue": "latest", "@clerk/nuxt": "3.1.3" } }nuxt.config.tsexport default defineNuxtConfig({ compatibilityDate: '2025-07-15', modules: ['@clerk/nuxt'] })app/app.vue<template><div>hi</div></template> -
pnpm install && pnpm build -
The
NUXT_B8003warning prints. Remove@clerk/nuxtfrommodulesand it goes away.
Expected behavior:
Loading @clerk/nuxt produces no warning.
Actual behavior:
[NUXT_B8003] is printed on every build and dev start.
Possible solutions
-
Merge into the options directly in
setup()(Clerk-side, smallest change). This is the only part ofupdateRuntimeConfigthat has any effect during setup:import { defu } from 'defu' setup(options, nuxt) { const runtimeConfig = { public: { clerk: { /* …unchanged… */ } }, clerk: { /* …unchanged… */ } } Object.assign(nuxt.options.nitro.runtimeConfig, defu(runtimeConfig, nuxt.options.nitro.runtimeConfig)) // … }I patched this into the published 3.1.3
dist/module.jsin the repro above. The warning is gone, and the runtime config Nitro serializes (public.clerk.*andclerk.*, still overridable viaNUXT_PUBLIC_CLERK_*/NUXT_CLERK_*) is byte-for-byte the same as before.Merging into
nuxt.options.runtimeConfigwithdefuis another option. It's the documented module pattern, but it has different precedence from what the kit helper does today. -
Fix it in
@nuxt/kit.updateRuntimeConfigcould checktryUseNitro(), which already exists inpackages/kit/src/nitro.ts, instead of catching auseNitro()throw. That would fix it for every module that calls the helper during setup. It's worth raising with Nuxt either way, but option 1 is under Clerk's control and works on Nuxt 4.5.x as released. -
Defer the call to a hook, as the warning suggests (for example
nuxt.hook('ready', …)). I wouldn't recommend this, becausesetup()is exactly when the keys need to exist so that env overrides are picked up. Option 1 keeps the timing as it is now.
Environment
System:
OS: macOS 26.6.2
CPU: (10) arm64 Apple M4
Binaries:
Node: 26.8.2
npm: 11.19.1
pnpm: 12.4.1
npmPackages:
@clerk/nuxt: 3.1.3 => 3.1.3
nuxt: 4.5.2 => 4.5.2
vue: latest => 3.5.43
Also seen with @clerk/nuxt 2.6.22.
- Vorherrschende Sprache
- TypeScript
- Sterne
- 1.8k
- Forks
- 472
- Ø Merge
- 2 T. 12 Std.
- Gemergte PRs (30 T.)
- 222
Beitragsleitfaden
Erste Schritte
- Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
- Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
- Forken Sie das Repository und arbeiten Sie in einem Branch.
- Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.
Mehr aus clerk/javascript
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 74/100
clerk/javascript#9611 · 1 Kommentar ·
-
Schwierigkeit 4/5 3-5 Tage Anfängerfreundlichkeit 64/100
clerk/javascript#9775 · 1 Kommentar ·
-
Schwierigkeit 4/5 3-5 Tage Anfängerfreundlichkeit 48/100
clerk/javascript#9770 · 3 Kommentare ·
-
Schwierigkeit 3/5 1-2 Tage Anfängerfreundlichkeit 68/100
clerk/javascript#9667 · 1 Kommentar ·
-
needs-triage
Schwierigkeit 3/5 1-2 Tage Anfängerfreundlichkeit 58/100
clerk/javascript#9478 · 2 Kommentare ·
Alle Issues in clerk/javascript
Ähnliche Issues
-
bug(cli): hapi doctor inline-media prints a fabricated B:\ helper-script path in packaged installs Offen
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 70/100
-
Crush Offen
Schwierigkeit 1/5 Unter einer Stunde Anfängerfreundlichkeit 85/100
catppuccin/catppuccin#3125 ·
-
Add a SECURITY.md Offen
Schwierigkeit 1/5 Unter einer Stunde Anfängerfreundlichkeit 90/100
ElementsProject/cln-application#167 · 1 Kommentar · 1 Reaktion ·
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 75/100
Quantco/pnpm-licenses#17 ·
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 75/100