`ThemeContext.colors` JSDoc says "current theme" but returns all themes

[hadarziv-army]

Hey 👋🏻

The docs and JSDoc for ThemeContext.colors describe it as:

A computed reference to the resolved colors of the current theme.

However, the runtime implementation iterates over all registered themes and returns Record<string, Colors> where the outer key is the theme, not just the current theme's colors.

By the way, I always wondered, why not have interface augmentation so we would have type-safe accessing of theme colors? Right now, Colors is Record<string, string>, so there's no autocomplete or typo protection:

const theme = useTheme()

theme.colors.value['light'].primary   // works but no autocompletion
theme.colors.value['light'].primray   // silent typo — no error

Something like an augmentable ThemeColorOverrides interface would make this type-safe without breaking existing behavior.

Thanks in advance🙏🏻

[johnleider]

JSDoc fix: The colors JSDoc said "current theme" but it returns all registered themes — fixed in the next push.

On type-safe colors: I've explored several approaches:

1. Module augmentation (ColorOverrides interface) — works globally with the existing useTheme(), but requires a declare module file
2. defineTheme helper — infers color keys from the themes object, returns a typed trinity (Pinia-style), but adds a new export
3. Generic on useTheme<C>() — add a color type parameter to ThemeContext and expose it through useTheme, no new exports
4. Generic at plugin creation — createThemePlugin<C>() validates input types, but can't propagate to the separately-exported useTheme due to TypeScript's DI erasure

The core constraint: useTheme is typed at module level by createPluginContext. TypeScript can't retroactively narrow it from a runtime call site. Only module augmentation or creating your own typed useTheme (approaches 1-3) can solve this.

Still deciding on the right DX trade-off. Input welcome.

[hadarziv-army]

Thank you 🙏🏻

My preference is 1 or 2 over the others. 3 forces you to repeat yourself every time you use the hook, and 4 doesn't even fully work because TypeScript loses the type information at the plugin boundary - neither feels worth it.