Typescript conversion?
Given issue #258 would there be any interest in simply converting this to be Typescript based?
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: