Add type for keywords

[lloydk]

No description provided.

[netlify]

❌ Deploy Preview for colorjs failed. Why did it fail? →

Name	Link
🔨 Latest commit	b522566
🔍 Latest deploy log	https://app.netlify.com/sites/colorjs/deploys/666784a4b2f51000088cea57

[MysteryBlokHed]

LGTM—I tried messing with @satisfies locally to see if there was a way to keep the color names as part of the type, but it doesn't seem to work

[MysteryBlokHed]

LGTM—I tried messing with @satisfies locally to see if there was a way to keep the color names as part of the type, but it doesn't seem to work

Another option could be to do something like storing the values in a (non-exported) variable, and then doing this?

const colors = { /* ... */ };

/** @typedef {keyof typeof colors} NamedColor */

export default /** @type {Record<NamedColor, [number, number, number]>} */ (colors);
               // ^ JSDoc type assertion

Depends on whether it seems important to preserve the color names in the type. Thoughts?

[lloydk]

LGTM—I tried messing with @satisfies locally to see if there was a way to keep the color names as part of the type, but it doesn't seem to work

Another option could be to do something like storing the values in a (non-exported) variable, and then doing this?

const colors = { /* ... */ };

/** @typedef {keyof typeof colors} NamedColor */

export default /** @type {Record<NamedColor, [number, number, number]>} */ (colors);
               // ^ JSDoc type assertion

Depends on whether it seems important to preserve the color names in the type. Thoughts?

You wouldn't gain any additional type safety because anywhere you'd use the NamedColor type you'd also accept any string (e.g. "oklch(40% .4 180)") but I'm not opposed to it.

[LeaVerou]

IMHO I think it's fine if typing isn't so thorough as to only allow specific strings — and would likely fail in edge cases if we did that.

[MysteryBlokHed]

Alright, this seems good then!