Hi @hayabusa2009, try remove "declaration": true in tsconfig or move interface Props to script block.

<script lang="ts">
//step1: declear type
interface Props {
  foo: string;
}
</script>

<script lang="ts" setup>
// setp2: defineProps
defineProps<Props>(); 
</script>

Why Volar is complaining about the interface anyway?
Is it a bad practice?

@mobayen You just need move interface from <script setup> to <script> if it is a part of emit type, if in <script setup>, the interface is actually inside setup() scope so it can't be emit.

...
setup() {
	interface Props {
      foo: string;
    }
}

Hi @hayabusa2009, try remove "declaration": true in tsconfig or move interface Props to script block.

<script lang="ts">
//step1: declear type
interface Props {
  foo: string;
}
</script>

<script lang="ts" setup>
// setp2: defineProps
defineProps<Props>(); 
</script>

@johnsoncodehk thank you for your replay and I try your advices but failed.
I want to know is there a way to extends thrid-part library component types in the setup block?
for example

<script lang="ts" setup>
  import type { ModalProps } from 'third-part-library/Modal';
  interface Props extends ModalProps {
    visible: boolean;
  }
  const props = defineProps<Props>();

</script>

@hayabusa2009 Have you try move interface Props to <script> tag? If it not works please provide a minimal reproduction.

<script lang="ts">
  import type { ModalProps } from 'third-part-library/Modal';
  interface Props extends ModalProps {
    visible: boolean;
  }
</script>

<script lang="ts" setup>
  const props = defineProps<Props>();
</script>

@johnsoncodehk when remove composite:true from tsconfig.json, warning disappear. tks again!

@hayabusa2009 Have you try move interface Props to <script> tag? If it not works please provide a minimal reproduction.

<script lang="ts">
  import type { ModalProps } from 'third-part-library/Modal';
  interface Props extends ModalProps {
    visible: boolean;
  }
</script>

<script lang="ts" setup>
  const props = defineProps<Props>();
</script>

Life savier, ty very much!

@johnsoncodehk With the latest version, this is blowing up the IDE. According to the documentation:

As of now, the type declaration argument must be one of the following to ensure correct static analysis:
A type literal
A reference to an interface or a type literal in the same file

and it also gives a code example of it in the script setup documentation:

interface Props {
  msg?: string
  labels?: string[]
}

const props = withDefaults(defineProps<Props>(), {
  msg: 'hello',
  labels: () => ['one', 'two']
})

I believe it should not throw here based on vue's documentation. Would you be willing to agree and would you like me to open an issue for it?

Hi,

I found a lighter alternative to moving the interfaces: exporting them also works with Volar 0.38.1.

<script lang="ts" setup>
  export interface Props {
    msg?: string
    labels?: string[]
  }

  const props = withDefaults(defineProps<Props>(), {
    msg: 'hello',
    labels: () => ['one', 'two']
  })
</script>

But I totally agree with @buckeyez. Volar should comply with Vue, and not the other way around.

removing declaration from tsconfig.json file works for me

removing declaration from tsconfig.json file works for me

This is not a valid solution. Its fine if what you are building is the end all, but when building components and libs it would defeat the purpose of using TS to not have the declarations for consumers.

Hi, what is the current recommended way to use interface for props?
The above suggestion to use "export interface" seems to work with no Volar error.
Is that the recommended way then?

It didn't work having it in a separate script, I get varying errors: Expected ";" but found "(" , Expected ";" but found "__returned__" , Expected ";" but found "defaults".

I have "Vue Language Features (Volar)" v0.40.13
and Vue: 3.2.38

Hello, I have same issue when try to build in lib mode

Can you provide a minimal reproduction code?

I will try to describe the problem in more detail. I have a small component library. Vue 3 + TS + Vite.
In package.json I have this version of libraries:

"vue": "^3.2.37",
"vue-tsc": "^0.40.13"
"vite": "^3.1.0",
"typescript": "^4.8.3",

In tsconfig.json

{
  "compilerOptions": {
    "target": "esnext",
    "useDefineForClassFields": true,
    "module": "esnext",
    "moduleResolution": "node",
    "strict": true,
    "jsx": "preserve",
    "sourceMap": true,
    "resolveJsonModule": true,
    "esModuleInterop": true,
    "lib": ["esnext", "dom"],
    "declaration": true,
    "emitDeclarationOnly": true,
    "declarationDir": "./dist/types",
    "isolatedModules": true,
    "skipLibCheck": true,
    "types": [
      "vite/client"
    ],
    "baseUrl": ".",
    "paths": {
      "~/*": ["./*"],
      "@/*": ["./src/*"]
    }
  },
  "include": [
    "src/index.ts",
    "src/components/**/*.ts",
    "src/components/**/*.vue",
    "src/composables/**/*.ts",
    "src/mocks/**/*.ts",
    "src/env.d.ts"
  ]
}

In vite.config.ts

const path = require("path");
const { defineConfig } = require("vite");
import vue from "@vitejs/plugin-vue";

module.exports = defineConfig(() => {
  const rootPath = path.resolve(process.cwd());
  const srcPath = `${rootPath}/src`;
  return {
    resolve: {
      alias: {
        "~": rootPath,
        "@": srcPath,
      },
    },
    plugins: [vue()], 
    build: {
      lib: {
        entry: path.resolve(__dirname, "src/index.ts"),
        name: "UiKitNext",
      },
      rollupOptions: {
        external: [
          "vue",
        ], 
        output: {
          exports: "named",
          globals: {
            vue: "Vue",
          },
        },
      },
      emptyOutDir: false,
    },
  };
});

Example of component:

<template>
  <div v-show="active" class="tab">
    <slot />
  </div>
</template>

<script lang="ts">
import { IEvent } from "@/components/types";

export interface ISvTabProps {
  title: string;
  id: string;
  actions?: IEvent[];
  hidden?: boolean;
  parentId?: number;
}
</script>

<script setup lang="ts">
import { ComponentInternalInstance, getCurrentInstance, ref } from "vue";

const props = withDefaults(defineProps<ISvTabProps>(), {
  hidden: false,
});
... // some code stuff
</script>

Build script in package.json

"build": "rimraf dist && vue-tsc && vite build",

When I run the vue-tsc, everything works fine and the dist/types are generated.

When I run the build script I get the following error:

Unexpected "="
29 |    setup(__props: any) {
30 |
31 |  const props = __props as { t props = wit, aults(defi, ops<ISvTabProps>(), hiddenn: false,,
   |                                     ^
32 |
33 |  const active =  }

transforming (131) src\components\Widgets\SvDepositForm\SvDepositForm.vueerror during build:
Error: Transform failed with 1 error:
D:/dev/norvikbank-next/ui-kit-next/src/components/Base/SvTab/SvTab.vue?vue&type=script&setup=true&lang.ts:31:35: ERROR: Unexpected "="

My error had to do with Vitest: if I choose vitest when installing (npm init vue@latest) , the tsconfig is different and has some files included with "references":

{
  "files": [],
  "references": [
    {
      "path": "./tsconfig.config.json"
    },
    {
      "path": "./tsconfig.app.json"
    },
    {
      "path": "./tsconfig.vitest.json"
    }
  ]
}

I tried to change stuff in those three files, but didn't manage to get rid of the errors.
If I remove the references array and add this from the original vue tsconfig the errors disappear:

  "include": ["env.d.ts", "src/**/*", "src/**/*.vue"],
  "files": [],
  "compilerOptions": {
    "baseUrl": ".",
    "paths": {
      "@/*": ["./src/*"]
    }
  }

Here is a reproduction

Create some reproduction repo

Maybe all the same it's not in the library but in Vue itself
vitejs/vite#9836
vuejs/core#5830

Same problem here. I discovered it when using the new reactivity transform feature.
Anyway, this error occurs when using interface with defineProps in general I found out.

It is also worth noting that this is IDE error only. Compiler doesn't complain and everything works as expected.
The only problem is that ts4082 highlights my entire script setup in red :D

Can be solved by exporting the interface, but that doesn't seem right to me since no export is used in Vue docs.
Plus the aforementioned fact that it works, since (I believe) all types in script sertup are auto exported by default. So it is just IDE that should stop complaining.

Create some reproduction repo

The error is throw by vite build not vue-tsc, please consider reporting it to vite repo.

My error had to do with Vitest: if I choose vitest when installing (npm init vue@latest) , the tsconfig is different and has some files included with "references":

I can only got Cannot find module '../HelloWorld.vue' or its corresponding type declarations. error in the repo:

$ npm run type-check

> [email protected] type-check
> vue-tsc --noEmit -p tsconfig.vitest.json --composite false

src/components/__tests__/HelloWorld.spec.ts:4:24 - error TS2307: Cannot find module '../HelloWorld.vue' or its corresponding type declarations.

4 import HelloWorld from '../HelloWorld.vue'
                         ~~~~~~~~~~~~~~~~~~~


Found 1 error in src/components/__tests__/HelloWorld.spec.ts:4

@StepanMynarik could you provide repro case?

Why is this closed? Based on how Vue 3 outlines how to use <script setup>, volar is not working properly.

Littering a project with <script> as a work around is exhausting, cruft, and confusing in medium/large projects.

export interface works, but isn't necessary in other IDEs. Not to mention, if any code inserted above export interface that isn't an import breaks the workaround.

Apologies for coming off rude, but workarounds doesn't constitute closing an issue.

I agree with this, the plugin isnt working how the docs say it should work ..?

A workaround is to annotate Props using type instead of interface:

<template>test</template>
<script lang="ts" setup>
  type Props = { // <----- Use type instead of interface
    foo: string;
  }
  defineProps<Props>(); 
</script>

Works in Volar 1.0.24.

Why is this closed? Based on how Vue 3 outlines how to use <script setup>, volar is not working properly.

Littering a project with <script> as a work around is exhausting, cruft, and confusing in medium/large projects.

export interface works, but isn't necessary in other IDEs. Not to mention, if any code inserted above export interface that isn't an import breaks the workaround.

Apologies for coming off rude, but workarounds doesn't constitute closing an issue.

Same here!

Hey guys - for those who subscribes this issue - this is likely a limitation in Typescript. interface can be extended, but type aliases can't:

interface Foo {
  foo: 1
}
// No error! Foo has been extended
interface Foo {
  bar: 1
}
// -------
type Bar = {}
// Oops, error!
type Bar = {}

Why export interface works? Volar will hoist all export statements to top-level, so they can be imported from other files. However, though hoisting all interfaces seems to be a viable solution, it's un unacceptable (if the interface references some type alias or generics defined in script setup, what should we do?).

In looking for a doable solution and I can implement it in a PR. Any help is appreciated!

Please reopen this issue.

Having it closed sends the wrong message, and motivates folks to open new issues for the same topic.

My issue is the same as described above: I can't define props interface extending a third-party library interface.
It's in the non-setup script tag.

I don't seem to be able to ignore this error with /* @vue-ignore */ either.

And this is a library of components.

It really doesn't make the best sense to close the issue if the docs say one thing and the plugin faults the same thing. It's very confusing to follow what you think is convention then get dinged for it and use work arounds.

@frankypixels Any reproduction? I can't reproduce this issue anymore.

This is exactly that I had yesteday

interface Notes {
id: string
content: string
}

const notes = defineProps<Notes>()

It worked for me after updating volar to pre-release version 1.8.23

Starting from a certain version, when there is only one script setup block, the setup code will be generated to the file root instead of the function scope to avoid this problem.

2.1.4 - still actual. But with defineComponent syntax.

UPD:
Some cases solution (export interface):

<script setup lang="ts" generic="T">
export interface Props<T>

I created a repository to demonstrate the issue where a <script setup> component (with props defined via interface Props) is used within a defineComponent, causing a “Default export…” error.

Repository: https://github.com/charnog/vue-default-export

We initially started our project using only the defineComponent syntax (Vue 2). When Vue 3 was released, we began using the Composition API for all new components. Naturally, we use the “old” defineComponent components within the new ones. However, after some package updates, this error started appearing.

This might also be related to @mityaua’s issue, but I’m not entirely sure.

@KazariEX @johnsoncodehk let me know if you’d like me to create a distinct issue for this.

I created a repository to demonstrate the issue where a <script setup> component (with props defined via interface Props) is used within a defineComponent, causing a “Default export…” error.

Repository: https://github.com/charnog/vue-default-export

We initially started our project using only the defineComponent syntax (Vue 2). When Vue 3 was released, we began using the Composition API for all new components. Naturally, we use the “old” defineComponent components within the new ones. However, after some package updates, this error started appearing.

This might also be related to @mityaua’s issue, but I’m not entirely sure.

@KazariEX @johnsoncodehk let me know if you’d like me to create a distinct issue for this.

if u use export props it works: charnog/vue-default-export#1

@webdesignberlin Yep, thank you! This “workaround” was already described here. There’s also the type Props workaround, or you can use defineProps<{ msg: string }> instead. The official docs explain how to type Props in a more formal way without requiring an export.

My question isn’t about “how to fix it in a component” but rather “what is the best approach and is it possible to address this in volar/vue-tsc?” If not, then what should be considered the official approach?

This is a limitation of TS.

// setup.ts
import { defineComponent } from "vue";

interface Props {
  msg: string;
}

export default defineComponent({
  __typeProps: {} as Props
});

// define.ts
import { defineComponent } from "vue";
import Setup from "./setup";

export default defineComponent({
  components: {
    Setup,
  },
});

The currently discovered solution that can be implemented in this repository is:

export default defineComponent({
  __typeProps: {
    ...{} as Props
  }
});

@charnog please feel free to open a new issue.