Nuxt•6mo ago

Extending public runtime config type

I have a featureFlags property on my runtimeConfig.public config. However, when I try to do something like:

const { featureFlags: runtimeFeatureFlags = '' } = useRuntimeConfig().public;
const featureFlags = ref(runtimeFeatureFlags.split(','));

const { featureFlags: runtimeFeatureFlags = '' } = useRuntimeConfig().public;
const featureFlags = ref(runtimeFeatureFlags.split(','));

The featureFlags property type is unknown. I tried adding this to <srcDir>/index.d.ts:

declare module 'nuxt/schema' {
  interface PublicRuntimeConfig {
    featureFlags: string;
  }
}
export {};

declare module 'nuxt/schema' {
  interface PublicRuntimeConfig {
    featureFlags: string;
  }
}
export {};

Still same error. I am an app extending from a layer if that makes any difference. Where am I going wrong here?

5 Replies

kapa.ai•6mo ago

Hi @dmarr. I'm kapa.ai, your friendly support bot. I will try to answer your question by searching through the knowledge base. :wave: ---------------------- You're on the right track by augmenting the PublicRuntimeConfig interface in index.d.ts. However, when using Nuxt layers (i.e., your app extends from a base layer), type augmentation can sometimes be tricky because the type merging must happen in the context of the final app, not just the layer. Here are some key points and recommendations based on the knowledge sources: 1. Type Augmentation Location
Your augmentation should be in the root of your final app (not just the layer), typically in a file like index.d.ts at the project root. This ensures Nuxt picks up your type changes after merging all layers. If you put the augmentation only in the layer, the extending app might not see it. 2. Correct Module to Augment
For end-users (i.e., in your app), you should augment nuxt/schema as you did. Module authors should use @nuxt/schema instead. Your code is correct for an app:

   declare module 'nuxt/schema' {
     interface PublicRuntimeConfig {
       featureFlags: string;
     }
   }
   export {};

   declare module 'nuxt/schema' {
     interface PublicRuntimeConfig {
       featureFlags: string;
     }
   }
   export {};

See: Typing Runtime Config 3. Ensure the File is Included
Make sure your index.d.ts is included in your tsconfig.json or is in a location that TypeScript will pick up automatically. 4. Restart TypeScript Server
Sometimes, after adding or changing type augmentations, you need to restart your IDE's TypeScript server or even restart nuxt dev to pick up the new types. 5. Type Generation Caveats with Layers
When using layers, type merging can be affected if the layer also provides its own type augmentations. The final app's types should take precedence, but if you see issues, ensure there are no conflicting or duplicate augmentations. 6. Type Generation
Nuxt tries to automatically generate types for runtime config, but manual augmentation is supported and recommended for custom properties. If you still see unknown, double-check that your augmentation is being picked up and that there are no typos or path issues. Summary:
- Place your index.d.ts in the root of your final app. - Augment nuxt/schema as you did. - Ensure the file is included in your TypeScript project. - Restart your dev environment after changes. If you follow these steps and still see unknown, it's likely a type resolution or file inclusion issue, not a Nuxt limitation. The knowledge sources confirm this approach is correct for extending runtime config types, even when using layers Typing Runtime Config. If you need to see a minimal working example, let me know! ---------------------- Note: you can ask me a follow up question by @ mentioning me again :speech_balloon: ----------------------

kapa.ai•6mo ago

<@139883350096740354> Kapa.ai is still learning and improving, please let me know how I did by reacting below.

dmarrOP•6mo ago

@kapa.ai If I change to declare module '@nuxt/schema' things work! I am confused because this is not a layer, but an app that extends a layer

kapa.ai•6mo ago

Let me check the knowledge base for you again. One moment! :books: ---------------------- You're right to be confused—according to the Nuxt documentation, end-users (apps) should augment nuxt/schema, while module authors should augment @nuxt/schema:

nuxt/schema is provided as a convenience for end-users to access the version of the schema used by Nuxt in their project. Module authors should instead augment @nuxt/schema Typing Runtime Config.

However, in practice, there have been some inconsistencies and ongoing changes in how Nuxt handles type augmentation, especially with layers and type generation. Some recent pull requests and discussions indicate that there have been issues with where type augmentations are picked up, and sometimes augmenting @nuxt/schema works when nuxt/schema does not, even in apps. For example, this PR mentions duplication because both are being extended, and there is ongoing work to clarify and improve this behavior. In summary:
- Officially, you should augment nuxt/schema in your app. - If augmenting @nuxt/schema works and nuxt/schema does not, it's likely due to current implementation details or a bug in Nuxt's type resolution, especially when using layers. - This is a known area of active development and may change in future Nuxt releases. If you want to be future-proof, keep an eye on the Nuxt documentation and release notes for updates on this behavior. For now, using @nuxt/schema as a workaround is acceptable if it resolves your issue, but the official guidance is to use nuxt/schema for apps. ---------------------- Note: you can ask me a follow up question by @ mentioning me again :speech_balloon: ----------------------

kapa.ai•6mo ago

<@139883350096740354> Kapa.ai is still learning and improving, please let me know how I did by reacting below.

Gaming

Programming

Extending public runtime config type

Did you find this page helpful?