Typescript conversion? #262

Ehhhhh to be honest I don't know. @LitoMore what do you think?

BTW I did take an exploratory stab at it (see draft PR), but it will likely introduce some breaking changes and a move a away from the dynamic creation of the conversion methods (this depending on color-convert). I'm going to park the work for now, so I don't spend more energy than necessary.

Ah, I already have the TypeScript in mind. It is much easier to maintain and update the type definitions with TypeScript. (That's why I sent you @Qix- a friend request on Discord today. I was just about to DM you about rewriting in TypeScript.)

I can rewrite the code of color (after the ESM change), color-convert, and color-string to TypeScript without any API breaking change.

I will draft PRs for them these days.

Yeah really the big thing is color-convert's automatic converter building. As long as that happens then it makes no difference to me if it's typescript or ESM+types.

Yeah really the big thing is color-convert's automatic converter building. As long as that happens then it makes no difference to me if it's typescript or ESM+types.

Yes. I've read that issue. We could release a patch update to fix the index.d.ts at the moment.

Considering automatic converter building, the TypeScript rewrites might be more appropriate when refactoring for the tree-shaking supports.

I think that's probably ideal given that Typescript can infer return values on the composed types: