Open edahlseng opened 6 years ago
Thanks, @edahlseng! And thx for getting my attention back at this π
A quick Google query revealed some rather exciting developments that happened in the year since I wrote that.
I think we are now able to build something quite elegant and production-useable!
Instead of trying to somehow make the custom Babel transforms work with the Flow type checker, we can now build it on top of TypeScript, solving a bunch of issues π€©
ts-loader
What do you say? π
And if we have to build a small CLI tool anyway (since the TS compiler can be customized, itβs CLI cannot though), we could make it much nicer to use as well.
No tsconfig.json
, unless you really want to customize low-level options. We ship some sensible opionated defaults that can be customized via a package.json
property / CLI options or so.
Interesting! I didn't know that TypeScript had introduced custom plugins.
Playing devil's advocate for a moment β What are the downsides of going with this TypeScript approach?
I've only ever used Flow myself, and chose it for the greater type soundness that it provides (given that TypeScript open acknowledges that soundness is less of a priority than tooling, for example). Given that background I'm looking to understand more of the strengths and weakness that TypeScript has.
Well, they have a very basic plugin system under the hood, but there is no option for tsc
to use them (the webpack ts-loader
on the other hand supports it already), so it's not really hidden, but not immediately accessible to most users.
From a philosophical standpoint I agree, the emphasis on soundness is a bonus point for Flow. But from a pragmatic standpoint, the overall TypeScript ecosystem and tooling seems more mature is way more wide-spread, I'd say.
Flow did a great thing integrating with the Babel stack, making it very powerful and extendable. On the other hand they wrote the Flow type checker in OCAML, effectively making it completely uncustomizable to their users π
So I bet my stake on TypeScript π Problem is rather that I don't have time to work on that...
Ah, interesting... Thanks for explaining that! Doing some more research on TypeScript now I also see that the've closed a lot of the holes that existed when I looked at it last β excited to try out the latest!
I'd love for this to become a production-usable project! Work keeps me very busy during the week so my contribution levels can be quite sporadic (limited to free time in the evenings and on weekends, when it exists), but I'd love to help out where I can. Let me know what the best way to start is!
Sounds great! The biggest obstacle here is that we will need to provide updated syntax highlighting for IDEs as well and such stuff, making it a lot of effort.
I am doing baby steps right now:
I started writing an alternative TypeScript compiler CLI that fixes a few of tsc
's idiosyncrasies, comes with modern best-practice default options and supports transformations (!).
Letβs write a simpler transformation first (I thought about a "reflect" transform that allows you to access type information at runtime, i.e. for validating user input). If that goes well, gear
could be the next step :)
Maybe you are interested in trying that compiler CLI or write a simple transformation?
Have a look at https://github.com/andywer/type-reflect π
@andywer interesting, I just ran into a use case for a tool like type-reflect this past weekend! I'll give ts and type-reflect a try this week!
It seems odd to me that tsc does not support some of the features that you've added in ts. Is there any interest to try and get those upstreamed?
I would try to upstream it, but 1) it's not mature enough as of now and 2) the lack of that feature has been raised a few times already, but the TypeScript maintainers have repeatedly turned it down with the reason that they are not interested in that...
This looks like a super interesting project! I notice that it hasn't been touched in many months, though. Does anyone still use this?