Skip to content

feat: add unknown on props class in public props #5539

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed

Conversation

fuegoio
Copy link

@fuegoio fuegoio commented Jul 20, 2025

Hello 👋

Trying to play around with class inheritance with components, I experimented something a bit un-documented from VueJS: even if a props class is defined, the class compilation (transformining an object with conditions to a string) will still happen.

Here is a simple reproduction: Vue Playground.

This behavior is quite interesting as it allows the child component to get the class without having the need to use defineOptions({ inheritAttrs: false }) and useAttrs. The typing on the class is therefore better, even if the user can in theory put any kind of type like boolean for the class props, not resulting in a type error, even if the class will be a string after VueJS compilation.

I would like to propose a change in the typing tools in this repository to allow this behavior from a typing perspective. The vue-tsc and language server are raising errors about the type of the class props being given to the child component, even if VueJS will always compile this props to a string.

I'm trying to put the default type of class from VueJS which is unknown: https://github.com/vuejs/core/blob/e60edc06f29b32c8f3a44d0ab3558a0569515e8f/packages/runtime-core/src/component.ts#L185, but only on the public interface of a component, as it will be a string inside.

I think enforcing the prop class to always be a string inside the component in itself needs to be done in the VueJS core repository, but I'm not sure.

This is clearly a proposal, happy to discuss this but I find the behavior quite useful and would like to push more usage of this in the VueJS community.

Copy link

pkg-pr-new bot commented Jul 20, 2025

Open in StackBlitz

vue-component-meta

npm i https://pkg.pr.new/vuejs/language-tools/vue-component-meta@5539

vue-component-type-helpers

npm i https://pkg.pr.new/vuejs/language-tools/vue-component-type-helpers@5539

@vue/language-core

npm i https://pkg.pr.new/vuejs/language-tools/@vue/language-core@5539

@vue/language-plugin-pug

npm i https://pkg.pr.new/vuejs/language-tools/@vue/language-plugin-pug@5539

@vue/language-server

npm i https://pkg.pr.new/vuejs/language-tools/@vue/language-server@5539

@vue/language-service

npm i https://pkg.pr.new/vuejs/language-tools/@vue/language-service@5539

vue-tsc

npm i https://pkg.pr.new/vuejs/language-tools/vue-tsc@5539

@vue/typescript-plugin

npm i https://pkg.pr.new/vuejs/language-tools/@vue/typescript-plugin@5539

commit: 416c892

@KazariEX KazariEX force-pushed the master branch 3 times, most recently from 7e5188a to 2d41b9d Compare July 23, 2025 08:36
@KazariEX
Copy link
Member

We shouldn't perform this kind of casting like boolean casting. Instead, we should preserve transparent propagation of the props interface.

Moreover, the current approach generates an extra type in every file, which increases the size of the generated .d.ts files. It should be done within the DefineComponent interface (still not recommended).

@KazariEX KazariEX closed this Jul 24, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants