Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

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

Aperta
#9,891 0 commenti 0 reazioni 1 assegnatario Vedi su GitHub

@wobsoriano ci sta già lavorando.

Dal 23/9/2026.

Valutazione

Questa issue non è ancora stata valutata.

Descrizione

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.

Lingua principale
TypeScript
Stelle
1.8k
Fork
472
Merge medio
2g 12h
PR unite (30g)
222

Guida per i contributori

Apri la guida per i contributori

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di clerk/javascript

Tutte le issue di clerk/javascript

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.