Nuxt•2mo ago

Various "Failed to resolve extends base type" when extending interfaces and using them as props

This is new in Nuxt 4.1 with Vite rolldown I have something like this: interface Props extends Omit<SomeInterface, 'createdAt' | 'editedAt' | 'category'> { createdAt: Date | string; editedAt?: Date | string | null; order: number; summary?: string; } And Im getting errors like:

 Pre-transform error: [@vue/compiler-sfc] Failed to resolve extends base type.                                                                                      11:26:47 AM
If this previously worked in 3.2, you can instruct the compiler to ignore this extend by adding /* @vue-ignore */ before it, for example:

 Pre-transform error: [@vue/compiler-sfc] Failed to resolve extends base type.                                                                                      11:26:47 AM
If this previously worked in 3.2, you can instruct the compiler to ignore this extend by adding /* @vue-ignore */ before it, for example:

Any ideas? Is this not valid in Vue?

25 Replies

kapa.ai•2mo ago

Hi @hiimmox. I'm kapa.ai, your friendly support bot. I will try to answer your question by searching through the knowledge base. :wave: ---------------------- The error you're seeing—Pre-transform error: [@vue/compiler-sfc] Failed to resolve extends base type—is related to how TypeScript types are resolved in Vue SFCs (Single File Components) when using generics or extending interfaces, especially with Nuxt 4 and Vite. From the knowledge sources, there are several related issues: 1. Global Types and defineProps: If you use a global type or interface (e.g., one generated by a module or defined in a layer) as a generic parameter in defineProps, and that type is not properly resolved or included in the Vue compiler's type resolution, you can get errors like this. This is especially problematic if the type is defined in a layer or module and not directly in your project, or if the type is not present in the files that the Vue compiler scans for types. There are workarounds, such as ensuring your type declarations are present in the global type files used by Vue, or by adjusting your vite.vue.script.globalTypeFiles config to include the relevant .d.ts files. See the workaround here:

   import { resolve } from 'node:path'

   export default defineNuxtConfig({
     vite: {
       vue: {
         script: {
           globalTypeFiles: [
             resolve('.nuxt/types/sampleModule.base.d.ts'),
           ]
         }
       }
     }
   })

   import { resolve } from 'node:path'

   export default defineNuxtConfig({
     vite: {
       vue: {
         script: {
           globalTypeFiles: [
             resolve('.nuxt/types/sampleModule.base.d.ts'),
           ]
         }
       }
     }
   })

Global types as generic type parameter in defineProps causing an exception 2. Layer and Module Type Issues: If your types are defined in a Nuxt layer or a module (especially if the layer is installed as a dependency or is inside node_modules), there are known issues with type resolution. One recommendation is to avoid shipping a tsconfig.json in your layer, as this can interfere with type resolution. Also, Nuxt previously excluded node_modules from TS projects, which could prevent your types from being included at all. This is being addressed, but you may need to ensure your types are accessible and not rely on a layer's tsconfig.json for type resolution. See the discussion here: Layer aliases not resolving, when it is installed as dependency 3. Workarounds: If you need to use an interface as a prop type and it's not resolving, you can sometimes work around the issue by inlining the type or by using a local type definition instead of extending from a global or imported interface. Alternatively, as the error message suggests, you can use /* @vue-ignore */ to instruct the compiler to skip the problematic type extension, but this will disable type checking for that line. 4. Recent Regressions: There are reports that this issue is new in Nuxt 4.1 with Vite, and that it previously worked in Nuxt 3.2. This suggests a regression or a change in how type resolution is handled in the latest versions. Summary:
This is a known issue with type resolution in Nuxt 4 (especially with layers, modules, and global types). The best immediate steps are: - Ensure your types are accessible to the Vue compiler (possibly by adjusting vite.vue.script.globalTypeFiles). - Avoid shipping a tsconfig.json in your layer if possible. - Inline types or use local type definitions as a workaround. - Use /* @vue-ignore */ as a last resort to suppress the error, but be aware this disables type checking for that line. If these steps do not resolve your issue, it may be necessary to wait for a fix in Nuxt or Vue, as this appears to be a regression in recent versions. The knowledge sources do not provide a definitive fix for all scenarios, but they do confirm this is a recognized and discussed problem in the Nuxt community. If you need more specific help, providing a minimal reproduction (as suggested in the issues) can help the Nuxt team address the problem more directly. ---------------------- Note: you can ask me a follow up question by @ mentioning me again :speech_balloon: ----------------------

kapa.ai•2mo ago

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

hiimmoxOP•2mo ago

@kapa.ai can you link me to the reports you mention?

kapa.ai•2mo ago

Let me check the knowledge base for you again. One moment! :books: ---------------------- Certainly! Here are links to the relevant reports from the knowledge sources above that discuss issues with type resolution, interface extension, and related problems in Nuxt 4: - Global types as generic type parameter in defineProps causing an exception: This issue details problems when using global types/interfaces as generic parameters in defineProps, resulting in errors from the Vue compiler about unresolvable type references. - Layer aliases not resolving, when it is installed as dependency: This report covers issues with type and alias resolution when a Nuxt layer is installed as a dependency, including comments about tsconfig.json and type accessibility. If you need more details or context from these reports, let me know! ---------------------- Note: you can ask me a follow up question by @ mentioning me again :speech_balloon: ----------------------

kapa.ai•2mo ago

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

hiimmoxOP•2mo ago

I tried changint my tsconfig from:

{
  "extends": "./.nuxt/tsconfig.json"
}

{
  "extends": "./.nuxt/tsconfig.json"
}

to the recommended:

{
  "files": [],
  "references": [
    { "path": "./.nuxt/tsconfig.app.json" },
    { "path": "./.nuxt/tsconfig.server.json" },
    { "path": "./.nuxt/tsconfig.shared.json" },
    { "path": "./.nuxt/tsconfig.node.json" }
  ]
}

{
  "files": [],
  "references": [
    { "path": "./.nuxt/tsconfig.app.json" },
    { "path": "./.nuxt/tsconfig.server.json" },
    { "path": "./.nuxt/tsconfig.shared.json" },
    { "path": "./.nuxt/tsconfig.node.json" }
  ]
}

with no luck. Any other ideas @kapa.ai ? This was working in 4.0

kapa.ai•2mo ago

Let me check the knowledge base for you again. One moment! :books: ---------------------- Switching your root tsconfig.json to use TypeScript project references, as recommended for Nuxt 4, is the correct approach for improved type safety and IDE support. The structure you posted is correct and matches the official guidance:

{
  "files": [],
  "references": [
    { "path": "./.nuxt/tsconfig.app.json" },
    { "path": "./.nuxt/tsconfig.server.json" },
    { "path": "./.nuxt/tsconfig.shared.json" },
    { "path": "./.nuxt/tsconfig.node.json" }
  ]
}

{
  "files": [],
  "references": [
    { "path": "./.nuxt/tsconfig.app.json" },
    { "path": "./.nuxt/tsconfig.server.json" },
    { "path": "./.nuxt/tsconfig.shared.json" },
    { "path": "./.nuxt/tsconfig.node.json" }
  ]
}

Nuxt 4 TypeScript project references However, if you are still experiencing issues (especially with type resolution or interface extension), here are some additional steps and considerations based on the knowledge sources: 1. Type Augmentation Location:
Make sure any type augmentations or custom types are placed in the correct directory: - Use app/ for app-specific types. - Use server/ for server-specific types. - Use shared/ for types shared between app and server. Types outside these directories will not be recognized with the new project references setup Nuxt 4 TypeScript concepts. 2. Remove Manual tsconfig.json in Layers/Modules:
If you are using Nuxt layers or modules, ensure you do not have a tsconfig.json in those directories, as it can interfere with type resolution Layer aliases not resolving. 3. Type Checking Script:
Update your type checking script to use the -b (build) flag for project references:

   "typecheck": "nuxt prepare && vue-tsc -b --noEmit"

   "typecheck": "nuxt prepare && vue-tsc -b --noEmit"

This ensures TypeScript checks all referenced projects Migration steps. 4. Shared Types in Server:
There was a recent fix to ensure that types in the shared/ directory are included in the server context. Make sure you are on the latest Nuxt version, as older versions may not include this fix Include shared types in tsconfig.server.json. 5. Aliases and Imports:
If you need custom path aliases, add them to the alias property in your nuxt.config, not directly in tsconfig.json, to avoid breaking auto-generated paths Nuxt 4 tsconfig docs. If you have followed all these steps and the issue persists, it may be related to a regression or a specific bug in the latest Nuxt 4.1 release, as there are reports of type resolution issues that did not exist in 4.0. In that case, you may want to follow or report your issue on the Nuxt GitHub for further assistance, as the knowledge sources do not provide a definitive fix for all scenarios. If you can share more details about your directory structure or a minimal reproduction, it may help pinpoint the problem. ---------------------- Note: you can ask me a follow up question by @ mentioning me again :speech_balloon: ----------------------

kapa.ai•2mo ago

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

hiimmoxOP•2mo ago

My interfaces are usually from a private repo, like this: import type { MyDTO } from 'some-random-package'; Then used like this:

interface Props extends Omit<MyDTO, 'createdAt' | 'editedAt' | 'category'> {
  createdAt: Date | string;
  editedAt?: Date | string | null;
  order: number;
}

const props = defineProps<Props>();

interface Props extends Omit<MyDTO, 'createdAt' | 'editedAt' | 'category'> {
  createdAt: Date | string;
  editedAt?: Date | string | null;
  order: number;
}

const props = defineProps<Props>();

Is this no longer valid @kapa.ai ?

kapa.ai•2mo ago

Let me check the knowledge base for you again. One moment! :books: ---------------------- Based on the knowledge sources, importing interfaces or types from external packages (such as a private repo) and using them in your Props interface—then passing that to defineProps<Props>()—is a valid and supported TypeScript pattern in Vue and Nuxt. This approach is documented and widely used, for example:

import type { MyDTO } from 'some-random-package';

interface Props extends Omit<MyDTO, 'createdAt' | 'editedAt' | 'category'> {
  createdAt: Date | string;
  editedAt?: Date | string | null;
  order: number;
}

const props = defineProps<Props>();

import type { MyDTO } from 'some-random-package';

interface Props extends Omit<MyDTO, 'createdAt' | 'editedAt' | 'category'> {
  createdAt: Date | string;
  editedAt?: Date | string | null;
  order: number;
}

const props = defineProps<Props>();

However, there are known issues in Nuxt 4 (especially with Vite and the latest versions) where type resolution for imported or global types used in defineProps can fail, resulting in errors like "Failed to resolve extends base type" or "Unresolvable type reference" from the Vue compiler. This is particularly problematic if the type is not directly present in your project or is not properly included in the type resolution context. These issues have been reported and discussed in the Nuxt community, and some workarounds or configuration changes may be required, but the knowledge sources do not indicate that this pattern is fundamentally invalid in Nuxt 4.1—just that it may be affected by current bugs or regressions in type resolution logic Global types as generic type parameter in defineProps causing an exception, Layer aliases not resolving, when it is installed as dependency. In summary:
Your usage is valid TypeScript and should work in Nuxt, but recent changes in Nuxt 4.1 and Vite may cause type resolution issues with imported types. If you encounter errors, they are likely due to these known issues rather than your code being invalid. The knowledge sources do not provide a definitive fix, but confirm this is a recognized problem. ---------------------- Note: you can ask me a follow up question by @ mentioning me again :speech_balloon: ----------------------

kapa.ai•2mo ago

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

Alwe•2mo ago

I'm having the same error, I tried going back to 4.0.3 but now I can't get rid of this. @hiimmox do you know how to temp fix this?

hiimmoxOP•2mo ago

@Alwe rm -rf node_modules/ && rm -rf .nuxt && yarn works for me I think the most important thing is deleting .nuxt

Alwe•2mo ago

sorry I missed a part... I'm having this problem with my dockerfile 🥲 locally it works fine (I'm using Bun) but withing docker it seems nothing works (pnpm, npm, bun)

hiimmoxOP•2mo ago

Ah, sorry not sure, Im testing this locally for now But maybe try building without cache? docker build --no-cache -t your-image-name .

Alwe•2mo ago

already tried... same error but on different file for some reason

Cake•2mo ago

pretty sure this is a compiler-sfc limitation

flapili•2mo ago

Had same error in different context, had to install typescript as dep (even if, was already present as transitive)

Alwe•2mo ago

already did, can't get rid of this error

Cake•2mo ago

@Alwe

Alwe•2mo ago

yeah I know...

Cake•2mo ago

you can assign it to a property

Alwe•2mo ago

i fixed the errors in my code, but now the errors come from inside NuxtUI @Cake this is another error that shows up sometimes when trying to build:

[nuxi]  ERROR  Nuxt Build Error: [vite:vue] A 'const' initializer in an ambient context must be a string or numeric literal or literal enum reference. (6:14)
#17 25.81 file: /app/app/components/mi/SelectMenu.vue:6:14

[nuxi]  ERROR  Nuxt Build Error: [vite:vue] A 'const' initializer in an ambient context must be a string or numeric literal or literal enum reference. (6:14)
#17 25.81 file: /app/app/components/mi/SelectMenu.vue:6:14

but line 6 is empty, it's between the imports and this:

defineOptions({ inheritAttrs: false })

const props = withDefaults(defineProps<MiSelectMenuProps<T, VK, M>>(), {
  all: false,
  removable: true,
})

defineOptions({ inheritAttrs: false })

const props = withDefaults(defineProps<MiSelectMenuProps<T, VK, M>>(), {
  all: false,
  removable: true,
})

Cake•2mo ago

what's the minimal code example that gives this error? could you share a playground maybe never seen this error before.

Alwe•2mo ago

i created a component to extend the SelectMenu from NuxtUI v3, everything was working just fine with 4.0.3 of nuxt, but since i updated (and reverted) I get this error while building in docker with pnpm. I'll share a playground as soon as I can

Gaming

Programming

Various "Failed to resolve extends base type" when extending interfaces and using them as props

Did you find this page helpful?