Interface hoisting for defineProps

[skirtles-code]

Overview

Type-based props support the use of a local interface, such as:

<script setup lang="ts">
interface Foo {
  msg: string
}

defineProps<Foo>()
</script>

Or:

<script setup lang="ts">
interface Foo {
  name: string
}

defineProps<{
  bar: Foo
}>()
</script>

However, both of these usages can lead to an error:

Default export of the module has or is using private name 'Foo'. ts(4082)

This doesn't happen for all projects, it depends on the TS settings. For example, the following seems to trigger the error:

  "compilerOptions": {
    "composite": true,

create-vue sometimes includes this setting, depending on the set of options chosen when creating the project. For example, choosing TypeScript and Vitest leads to this setting being included.

Using "declaration": true instead of "composite": true will also trigger the error.

This error can also be seen using vue-tsc with --emitDeclarationOnly.

Why Does This Happen?

The props are part of the exported type of the component. The interface passed to defineProps is treated as though it is inside the setup function. It needs hoisting in the virtual code to avoid the error:

+ interface Props {
+   msg: string
+ }

export default defineComponent({
  setup() {
-   interface Props {
-     msg: string
-   }

    defineProps<Props>()
  }
})

Currently, the only way to trigger hoisting in Volar is to use export. This can be used as a workaround to resolve this error, but it isn't particularly intuitive that this should be required. The export default is being handled implicitly, so why not the things it depends on?

The problem only occurs for interface, not type. I'm not clear why that is, or what ramifications it has for the proposal to hoist interfaces.

How Would Hoisting Work?

Things used by defineProps<X>() would be hoisted, recursively hoisting anything that it depends on:

Thanks to LinusBorg for coming up with this example:

// should be hoisted up as its used in `defineProps`
interface Props {
  foo: string
  user?: User
  settings: ExtendedUserSettings
}

// needs to be hoised as well as it's being used in `Props`
type ExtendedUserSettings = Extract<User, 'settings'> & {
  additionalOption: boolean
}

const props = defineProps<Props>()

const state = {
  a: 'A',
  b: 'B'
} as const
// can't be hoisted because of `typeof`, and also doesn't need to be.
type ReturnShorthand = typeof state;

A note from Evan when discussing this:

The current compiler behavior is treating all type declarations in script setup as module-level (I.e. hoist by default)

The SFC compiler maybe has an easier task here than Volar. The compiler only needs enough information to generate the runtime props option, whereas Volar and vue-tsc need to be able to construct actual TS types that can be consumed externally, e.g. in other projects.

In cases where the props depend on something that can't be hoisted, my suggestion would be to provide a clearer error message explaining the problem.

Another edge case to consider is the potential for naming collisions. Things defined in a separate <script> block could have the same names as the things being hoisted.

Implications of 3.3

With the proposal for 3.3 to support importing types, I suspect we're going to get much wider use of interfaces for props:

<script setup lang="ts">
import BaseProps from './somewhere.ts'

interface Props extends BaseProps {
  msg: string
}

defineProps<Props>()
</script>

References

We've had this problem reported multiple times against the docs repo. For example:

• Default export of the module has or is using private name 'Props'.ts docs#1678
• Fix bad error inducing documentation docs#2191

The underlying complaint is that the code shown in the docs leads to an error in Volar. Understandably this makes people think the docs are wrong.

This has also been reported in this repo:

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

I think that issue should be reopened. It may not be considered a bug, but there is an unresolved DX issue here.

[johnsoncodehk]

Fixed by #2582

[jmcooper]

I see this was merged in April and a release in June, but still seeing this issue in the TypeScript Vue Plugin (Volar) v1.8.22.