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