Disable slots using defineSlots

[rtcpw]

I have a renderless component that does not use slots. I would like to specify that there are no slots using defineSlots, so that TypeScript users can catch the error early if they specify a slot content. Is there a way to do this? This is what I want:

In ComponentA:

defineSlots<{}>();

In ComponentB:

<template>
    <ComponentA>
        <div>Hello World</div>     <!-- Compiler should catch this as invalid use of ComponentA -->
    </ComponentA>
</template>

[aniruddhaadak80]

@rtcpw currently maintaining this approach?
To enforce "no slots" in defineSlots, you technically can pass a type that has no keys, but TypeScript''s behavior with empty interfaces/object types in slots can be permissive (treated as any or ignored).

However, defineSlots<{ [key: string]: never }>() or defineSlots<Record<string, never>>() is a stronger signal.
The compiler warnings for "invalid slot content" usually trigger based on the presence of v-slot directives matching known keys. If strict slot checking is enabled in Volar/VueTSC, passing children to a component that defines empty slots should indeed flag an error.
Test with:

defineSlots<{}>() // weak
defineSlots<Record<string, never>>() // stronger intent

[rtcpw]

May I ask where do you see the option to enable strict slot checking?
https://github.com/vuejs/language-tools/wiki/Vue-Compiler-Options#strictness

The defineSlots<Record<string, never>>() does not seem to achieve anything in my project, Vue still happily compiles the proejct and does not warn me when I project slot content through the component.

[GitNimay]

I do not think defineSlots<{}>() can currently be used as a reliable “no slots allowed” contract in Vue templates.

defineSlots is mainly for typing the slots that a component exposes, especially scoped slot props. For example:

defineSlots<{
  default(props: { item: string }): any;
}>();

Using an empty object:

defineSlots<{}>();

means “this component declares no typed slots”, but Vue template type checking generally does not treat arbitrary children as a hard error just because no slots are declared. At runtime, Vue will still accept children and expose them on $slots; if the component never renders them, they are simply ignored.

So this is not something I would expect to be caught consistently:

<ComponentA>
  <div>Hello World</div>
</ComponentA>

If you want a runtime development warning, you can check $slots or useSlots() yourself:

<script setup lang="ts">
import { useSlots, onMounted } from "vue";

const slots = useSlots();

onMounted(() => {
  if (import.meta.env.DEV && slots.default) {
    console.warn("ComponentA does not accept slot content.");
  }
});
</script>

Or, without waiting for mount:

const slots = useSlots();

if (import.meta.env.DEV && slots.default) {
  console.warn("ComponentA does not accept slot content.");
}

That will not be a TypeScript error, but it gives consumers quick feedback during development.

For library authoring, I would document it as a renderless component with no slot API, and optionally add the dev warning. Today, defineSlots is useful for positive slot typing, but not really for forbidding all slots at compile time.

[rtcpw]

Thank you for the detailed reply. I am already using the console.warn approach, but it's far from ideal and feels more like a workaround. Would be nice to see this improved in some future Vue version.

[nichitacebotari0]

Has this changed, or perhaps im misunderstanding something. If i try to use a named slot that is not in defined slots I will actually get a
Property 'a' does not exist on type slotsType when running vue-tsc (Note: i like this, not criticising).
Similarly works if i do defineSlots<{}> or defineSlots<Record<string, never>>.

Also is it intentional that this works by only checking inclusion? I.e. if i try to define slotsType as

type slotsType = 
    | ({a : boolean} & {b: never))
    | ({a : never} & {b: number))

using both a and b slots will not raise an error.

To give context on where the 2nd scenario can be useful: im trying to make a datatable where you can either override how certain cells are rendered, or get an escape hatch for the entire row, using both at the same time is not possible

[wyf027]

I think two separate layers are involved here.

At Vue runtime / @vue/compiler-sfc level, defineSlots is only a type macro. It gets compiled away to useSlots() and does not enforce a slot contract by itself. The diagnostics you are seeing come from vue-tsc / @vue/language-tools, not from core runtime behavior.

So yes, newer language-tools behavior can flag an undeclared named slot, including the defineSlots<{}> / Record<string, never> case. For the second case, I would not expect the checker to fully model mutually exclusive slot sets from a union. Template slot checking is mostly asking “is this provided slot name present on the exposed slots type?”, not “does this whole set of provided slots satisfy exactly one union branch?”

For a datatable API where consumers may provide either cell-level slots or a whole-row escape hatch, I would still keep a small dev/runtime assertion, or model the choice through an explicit prop/API shape. If you want vue-tsc to reject the “both a and b slots together” case, that sounds like a good feature request for vuejs/language-tools, since the behavior lives there rather than in Vue core.

[jibin7jose]

I have a renderless component that does not use slots. I would like to specify that there are no slots using defineSlots, so that TypeScript users can catch the error early if they specify a slot content. Is there a way to do this? This is what I want:

In ComponentA:

defineSlots<{}>();

In ComponentB:

<template>
    <ComponentA>
        <div>Hello World</div>     <!-- Compiler should catch this as invalid use of ComponentA -->
    </ComponentA>
</template>

I think there are two different layers involved here, and that is why the behavior can look a bit inconsistent depending on the tool/version being used.

`defineSlots` is a type macro. In Vue core / `@vue/compiler-sfc`, it does not create a runtime slot contract and it does not make the SFC compiler reject children passed to the component.

In the current Vue core implementation, `defineSlots` is described as:

> Vue `<script setup>` compiler macro for providing type hints to IDEs for slot name and slot props type checking.

The macro is compiled away. If its return value is assigned, the SFC compiler rewrites it to `useSlots()`:

```ts
const slots = defineSlots<{
  default(props: { msg: string }): any
}>()
```

becomes, effectively:

```ts
const slots = useSlots()
```

If the return value is not used:

```ts
defineSlots<{
  default(props: { msg: string }): any
}>()
```

then the macro disappears entirely from the generated output.

So at Vue runtime level, this:

```ts
defineSlots<{}>()
```

does **not** mean "reject all children passed to this component". Vue will still accept:

```vue
<ComponentA>
  <div>Hello World</div>
</ComponentA>
```

The passed content becomes a slot on the component instance. If `ComponentA` never renders `$slots.default`, the content is simply ignored.

The errors people are seeing for undeclared slots come from `vue-tsc` / `@vue/language-tools`, not from Vue core runtime behavior. Newer language-tools versions can flag some slots that are not declared by `defineSlots`, especially named slots. That means `defineSlots<{}>()` can be useful as a type-level signal saying "this component exposes no public slots", provided consumers are checked by `vue-tsc` or an IDE using the same language-tools behavior. I would still treat rejection of implicit default-slot children as language-tools/version-dependent, not as a Vue core guarantee.

For expressing "no slots", I would use:

```ts
defineSlots<{}>()
```

rather than:

```ts
defineSlots<Record<string, never>>()
```

`Record<string, never>` does not really mean "there are no slot names". It describes every possible string key as having the value type `never`, which is a different type-level shape. For a public component API, `{}` communicates the intended contract more directly: this component declares no slots.

For the union example:

```ts
type Slots =
  | ({ a: boolean } & { b: never })
  | ({ a: never } & { b: number })
```

I would not expect current template slot checking to fully model "the provided slot set must satisfy exactly one union branch". The current behavior is closer to checking whether each provided slot name is known/present on the exposed slots type. That explains why using both `a` and `b` may not raise an error even though the intended API is mutually exclusive.

For a datatable API where consumers may provide either cell-level slots or a whole-row escape hatch, I would not rely on `defineSlots` unions to enforce that exclusivity today. A few practical options are:

1. Use `defineSlots` for the positive slot names and slot prop types.
2. Add a dev-only runtime assertion if mutually exclusive slots are passed together.
3. Consider modeling the choice through an explicit prop/API if the distinction is central to the component behavior.
4. Open an issue/feature request in `vuejs/language-tools` for stricter slot-set validation, since that diagnostic behavior belongs there rather than in Vue core.

So my current understanding is:

- `defineSlots<{}>()` is the clearest type-level declaration for "this component has no public slots".
- Vue core does not enforce that at runtime or at SFC compile time.
- `vue-tsc` / language-tools may report undeclared slots, depending on version and template checking behavior, but implicit default-slot children are not something Vue core itself rejects.
- Mutually exclusive slot groups are not reliably enforced by the current slot checker.
- If stronger compile-time checking is desired, the right place to improve it is `vuejs/language-tools`.

Local Repo Notes

These are the core details I checked in the cloned Vue repo:

• packages/runtime-core/src/apiSetupHelpers.ts

  • defineSlots is documented as a macro for IDE/type hints for slot name and slot props checking.
  • It is documented as compiled away and not meant to be called at runtime.

• packages/compiler-sfc/src/script/defineSlots.ts

  • defineSlots() cannot accept runtime arguments.
  • If assigned to a variable, the compiler rewrites the call to useSlots().
  • If not assigned, the macro call is consumed by the compiler.

• packages/compiler-sfc/__tests__/compileScript/defineSlots.spec.ts

  • Tests assert that generated code no longer contains defineSlots.
  • Tests assert that assigned defineSlots() becomes _useSlots().
  • Tests assert that unassigned defineSlots() does not emit _useSlots().

• packages/runtime-core/src/componentSlots.ts

  • Vue runtime slots are an indexed slot object.
  • The type helpers unwrap declared slot types, but they do not create runtime enforcement.

Short Version

If you want a shorter comment, post this:

`defineSlots<{}>()` is the clearest way to express "this component exposes no public slots" at the type level, but Vue core itself does not enforce that as a runtime or SFC-compile-time contract. `defineSlots` is a type macro; it is compiled away, or rewritten to `useSlots()` if the return value is assigned.

So slot errors for undeclared slots come from `vue-tsc` / `@vue/language-tools`, not from Vue runtime. Newer language-tools versions can flag undeclared named slots, including when the component declares an empty slot type, but I would treat implicit default-slot children as version/tooling-dependent and would not expect current tooling to fully validate mutually exclusive slot unions like "slot `a` or slot `b`, but not both". That kind of stricter slot-set validation would need to be handled in `vuejs/language-tools`.

For "no slots", I would prefer `defineSlots<{}>()` over `defineSlots<Record<string, never>>()`, because `Record<string, never>` describes every string key with value `never`; it is not the same shape as "no declared slot keys".