3 ms·
I don't see how you'd go about doing this. Babel doesn't have a type checker, and for type level features you'd need support from typescript. So you need a typ
by lf-non 5y ago
I don't see how you'd go about doing this. Babel doesn't have a type checker, and for type level features you'd need support from typescript.
So you need a typescript plugin - however the typescript compiler api (which btw is not officially supported) is not flexible enough to support new type syntax (for things like m/s) so you'd a fork.
- eurasiantiger 5y agobabel-plugin-typecheck, babel-plugin-tcomb and babel-plugin-jsdoc-type-checker (among others) are able to do similar things, so there must be a way. And I don’t see why not, since babel is ”just” an AST parser/transformer.
- lf-non 5y agoThose plugins primarily help with with runtime type validations - the static type checking is delegated to Flow/TS. The benefits around F# units of measure that the parent talks about are primarily focused on static type checking. If you are fine with the overhead of runtime boxing, it is relatively straightforward to have different container classes for different units and have bridge apis to convert/operate between them. A babel plugin could potentially help with operator overloading here, but this is quite far removed from F# units of measure at this point.
- eurasiantiger 5y agoIs writing a static unit type checker as a plugin a daunting task, then? I’ve never thought of it in detail, but it would seem that unit type checking rules for basic operations like add/subtract and multiply/divide would be straightforward, and everything else could be derived from there. The laborious task is just formulae.