Default export of the module has or is using private name 'Props'

[ly-sniper]

when upgrade volar to ^0.34.9 , there is a ts warning Default export of the module has or is using private name 'Props' at the top of template

//error info -> Default export of the module has or is using private name 'Props'. ts(4082)
<template>test</template>
<script lang="ts" setup>
  //step1: declear type
  interface Props {
    foo: string;
  }
 // setp2: defineProps
  defineProps<Props>(); 
</script>

but if definePorps like below, the warning disappear

<template>test</template>
<script lang="ts" setup>
  defineProps<{
    foo: string;
  }>();
</script>

[johnsoncodehk]

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>

[mobayen]

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

[johnsoncodehk]

@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;
    }
}

[ly-sniper]

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>

[johnsoncodehk]

@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>

[ly-sniper]

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

[cn-2k]

@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!

[buckeyez]

@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?

[HugoMuller]

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.

[iamgabrielsoft]

removing declaration from tsconfig.json file works for me

[buckeyez]

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.

[chesterlaykin]

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

[vaban-ru]

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

[iamgabrielsoft]

Can you provide a minimal reproduction code?

[vaban-ru]

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 "="

[chesterlaykin]

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

[vaban-ru]

Create some reproduction repo

[vaban-ru]

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

[StepanMynarik]

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.

[johnsoncodehk]

Create some reproduction repo

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

[johnsoncodehk]

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

> vue3-ts-volar-vitest-issue@0.0.0 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

[johnsoncodehk]

@StepanMynarik could you provide repro case?

[ffxsam]

Just ran into this today. Exporting the interface got rid of the error, but this is not a good developer experience.

[vknowles-rv]

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.

[rezelute]

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

[panzerdp]

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.

[Ge6ben]

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!

[so1ve]

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!

[amalitsky]

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.

[frankypixels]

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.

[so1ve]

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

[frankypixels]

This is exactly that I had yesteday

interface Notes {
id: string
content: string
}

const notes = defineProps<Notes>()

[Grenek]

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