Repository navigation
[Bug Report][4.1.2] Typescript issues with mode and modes in v-color-picker #22985
Description
Environment
Vuetify Version: 4.1.2
Vue Version: 3.5.39
OS: Linux undefined (current)
Steps to reproduce
- Write a computed that returns a string array with valid modes in it and hand it into the modes property
- Observe the typing issue
Expected Behavior
When something has such strict typings that just using a computed to calculate and return a valid value breaks them I would expect to be able to be provided the typing so I can use it accordingly and avoid the typescript errors instead of having to write them myselve. I would expect to be able to import a ColorPickerMode type that I can just import and use for typings.
Not having a typing this strict would also work for me, though it is the worse option
Actual Behavior
If I want to correctly type the computed I have to either look up the type myself (code or documentation) and write it, or extract the type from an imported component instance. The first is causing issues when the types are modified (by adding or removing a mode) and the other requires importing the component and still adding the type myself, which is something I would expect a library to do if they use strong typings, and not shift it to their users.
Reproduction Link
https://play.vuetifyjs.com/#...
Other comments
This issue with the types not existing and instead being hardcoded is happening everywhere (density for example) but most typings are broad enough that they accept string. There are ways to get the types, some being extract the typings from an imported component instance or writing them out by hand or copying from the documentation, but in most cases, not having the typings is not causing issues.
Activity
J-Sek commentedon Jul 2, 2026
You can drill with TS
VColorPicker['$props'][...](demo). It is a common workaround.Daenara commentedon Jul 3, 2026
I am aware of that workaround, it is what I meant by I can extract it from an imported class. it still means that the user has to import the class, and then either inline the
VColorPicker['$props'][...]part everywhere it is needed, which might impact readability, especially for ppl less familiar with vue and vuetify and just learning, or creating a named type from it to use that. This will either clog up the code and create repeated type declarations when the same type is needed in multiple components, or end up with the user having a custom type declaration file just to write all the vuetify types into.Don't get me wrong, that works, but I feel that it shouldn't be up to the user of a library to manage type declarations when using typescript but on the library itself. This is obviously a very low priority issue, I don't even expect it to be fixed in vuetify 4, but something that needed to be raised so it can be considered for future iterations (though I am pretty sure the very helpful ai that runs on the discord could make a pr for a stopgap solution by just reading
VColorPicker['$props'][...]and exporting it as named types in a type declaration file). The only reasons I raised this as a bug instead of a feature request are that I had a concrete example that I wanted to show off with a playground link and feature requests don't have a field for a reproduction link and no way to tag a specific component.All in all, this is a slight annoyance, I solved it by just typing the mode computed with computed<'hex' | 'hexa'>() since we only ever deal with those two and even not typing it will work just fine since it is just typescript.
fabianbernhart commentedon Jul 7, 2026
@Daenara i found out there is a much cleaner approach without prop drilling :)
And when you like to have more fun with types like extracting or excluding:
EDIT: