Add types for color space coord accessors.

[jgerigmeyer]

Fixes #381.

[netlify]

✅ Deploy Preview for colorjs ready!

Name	Link
🔨 Latest commit	80233dc
🔍 Latest deploy log	https://app.netlify.com/sites/colorjs/deploys/65baaf467e5dd40008be0b25
😎 Deploy Preview	https://deploy-preview-389--colorjs.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[jgerigmeyer]

@LeaVerou @MysteryBlokHed What do you think of this approach for fixing #381? It adds a build step (run during npm run lint and npm run build) that generates coord accessor types for all existing spaces. I've also checked that generated file into the repo, and CI will fail if a space has been added or changed without running the script.

Note that users can still add their own spaces and augment the types by adding an e.g. colorjs.d.ts file with:

import 'colorjs.io';

declare module 'colorjs.io' {
  export default interface Color {
    my-coord: number;
  }
}

[LeaVerou]

Oof, this is tough. It’s not just about authors adding color spaces, but also about using a subset of Color.js with fewer color spaces. Is this the only solution? What if we simply forgo type checking for that part of the PI and write the definition so that it assumes that any unrecognized property access is a color space / coord accessor (respectively)?

[jgerigmeyer]

Oof, this is tough. It’s not just about authors adding color spaces, but also about using a subset of Color.js with fewer color spaces.

@LeaVerou I'm not sure how this relates to users using a subset with fewer color spaces. That is, there isn't a good way for TypeScript to know which color spaces a user has registered, so this allows coord accessors for all the known color spaces, but errors if a user tries to access an unknown coord. Similarly, we allow e.g. myColor.hsl even if the user hasn't registered the HSL color space. Am I misunderstanding what you're saying?

Is this the only solution? What if we simply forgo type checking for that part of the PI and write the definition so that it assumes that any unrecognized property access is a color space / coord accessor (respectively)?

That's what we initially discussed in #381, but TypeScript doesn't allow us to type specific methods/properties on Color and also have a fallback index signature. We're also hardcoding the space type definitions: https://github.com/color-js/color.js/blob/main/types/src/color.d.ts#L142-L173

Actually, I think I'd propose we automate the space types similar to these coord accessors -- I can push that change in a few minutes.

[LeaVerou]

Oof, this is tough. It’s not just about authors adding color spaces, but also about using a subset of Color.js with fewer color spaces.

@LeaVerou I'm not sure how this relates to users using a subset with fewer color spaces. That is, there isn't a good way for TypeScript to know which color spaces a user has registered, so this allows coord accessors for all the known color spaces, but errors if a user tries to access an unknown coord. Similarly, we allow e.g. myColor.hsl even if the user hasn't registered the HSL color space. Am I misunderstanding what you're saying?

In the sense that TS won't complain if the user is trying to use a color space they have not registered, but I guess that's ok?

Is this the only solution? What if we simply forgo type checking for that part of the PI and write the definition so that it assumes that any unrecognized property access is a color space / coord accessor (respectively)?

That's what we initially discussed in #381, but TypeScript doesn't allow us to type specific methods/properties on Color and also have a fallback index signature. We're also hardcoding the space type definitions: main/types/src/color.d.ts#L142-L173

Is this a bug in TS, or an intentional design decision? Regardless of what we do, I still think it would be useful to bring up this use case with the TS team and see if they want to address it.

As far as this PR is concerned, I guess anything is better than the current situation, so I'm inclined to say let's merge (if @MysteryBlokHed is also on board).

[MysteryBlokHed]

I think the problem of allowing unregistered space coordinates to be changed is alright, since it shouldn't actually cause any runtime errors—it just won't actually affect anything.

Since TypeScript unfortunately doesn't allow us to just add a default type for undefined properties, this seems to me like the best solution.