Open andrewaylett opened 4 years ago
It sounds like a good idea. But CSSType should all be about TypeScript types and be independent from third-party libraries. But you're always able to fork and release it yourself as a separate package if that's an alternative for you?
I definitely considered that -- the idea of adding dependencies to a widely-used package that doesn't currently have any dependencies does not fill me with joy.
However, in trying to test my implementation it very quickly became apparent that the compile-time types used by (say) React need to have the same version as the run-time types used by application code -- a mismatch in versions leads fairly straightforwardly to compilation errors as the typescript compiler objects to keys being available in one version but not the other.
How would you feel about including the source definitions as well as the generated type files in the package? That way, run-time code can pull in definitions known to match the types being used.
https://github.com/gcanti/io-ts provides mechanisms to create type objects representing Typescript run-time types. When I started using io-ts in my Typescript React project, I very quickly ran up against the issue that Typescript can type-check style objects in props at compile-time, but it's not trivial to declare type objects for use with prop-types.
As a developer, I would like to be able to use io-ts type objects that are compatible with the Typescript types provided by csstype.
I have a branch that implements this; opening an issue before a PR with the intent of separating whether this is useful from how it should be implemented.