Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

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

Abierto
#9,891 0 comentarios 0 reacciones 1 asignado Ver en GitHub

@wobsoriano ya está trabajando en esto.

Desde el 23/9/2026.

Evaluación

Este issue todavía no se ha evaluado.

Descripción

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.

Lenguaje dominante
TypeScript
Estrellas
1.8k
Forks
472
Merge medio
2 d 12 h
PR fusionados (30 d)
222

Guía de contribución

Abrir la guía de contribución

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de clerk/javascript

Todos los issues de clerk/javascript

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.