Hacktoberfest 2026: die Issues, die Maintainer für den Oktober markiert haben – offen und einsteigerfreundlich. Hacktoberfest-Issues durchsuchen

@clerk/nuxt: calling updateRuntimeConfig() in setup prints NUXT_B8003 "Nitro is not initialized yet" on Nuxt 4.5

Offen
#9,891 0 Kommentare 0 Reaktionen 1 zugewiesene Person Auf GitHub ansehen

@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:

  1. 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.ts

    export default defineNuxtConfig({ compatibilityDate: '2025-07-15', modules: ['@clerk/nuxt'] })
    

    app/app.vue

    <template><div>hi</div></template>
    
  2. pnpm install && pnpm build

  3. The NUXT_B8003 warning prints. Remove @clerk/nuxt from modules and 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
  1. Merge into the options directly in setup() (Clerk-side, smallest change). This is the only part of updateRuntimeConfig that 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.js in the repro above. The warning is gone, and the runtime config Nitro serializes (public.clerk.* and clerk.*, still overridable via NUXT_PUBLIC_CLERK_* / NUXT_CLERK_*) is byte-for-byte the same as before.

    Merging into nuxt.options.runtimeConfig with defu is another option. It's the documented module pattern, but it has different precedence from what the kit helper does today.

  2. Fix it in @nuxt/kit. updateRuntimeConfig could check tryUseNitro(), which already exists in packages/kit/src/nitro.ts, instead of catching a useNitro() 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.

  3. Defer the call to a hook, as the warning suggests (for example nuxt.hook('ready', …)). I wouldn't recommend this, because setup() 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

Beitragsleitfaden öffnen

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus clerk/javascript

Alle Issues in clerk/javascript

Ähnliche Issues

Weitere Issues zu TypeScript

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.