Re:Future of TypeScript on ESLint
by ng12 on Friday January 18, 2019 @05:10PM
(#18943584)
Typescript's tooling is much better -- it's just a JS transpiler (and now you can use babel to do your transpiling if you prefer). Flow's daemon-style approach was a constant source of pain for me.
[ Parent
| on HN ]
Flow operates very similarly: the recommended setup is to use it with Babel. Babel just strips out the type annotations from your code to make it into legal javascript. The Flow daemon executable was just to provide type checking. Before TypeScript also got similar Babel support, I considered it a strong point in Flow's favor that it was so easy to drop in if you already had a Babel setup going.
> The Flow daemon executable was just to provide type checking.
This is problematic. Now your webpack build is shelling out asynchronously to a second process. It makes it very hard to integrate type checking to a build system.
I've never connected Flow to webpack or my compile process like that. When I've used Flow or TypeScript with Babel, the build process and type checking were always two separate things. I treated type checking like unit tests: something I'd frequently re-check while working on code, but not something connected to the path of getting code running somewhere.
Don't you want your build to fail if the type checker fails? I think it's pretty important for a large project.
Re:Future of TypeScript on ESLint
by williamdclt on Friday January 18, 2019 @05:44PM
(#18943830)
Not necessarily locally. On CI/staging/prod yeah definitely, but when I'm hacking around I'm fine with having type errors ("yeah yeah I know this is nullable, I don't care right now I just want to investigate this bug")
I absolutely want it locally, preferably inside my IDE where it's providing type hints, allowing navigation to type declarations, and alerting me immediately to typing issues live as I'm coding.
Re:Future of TypeScript on ESLint
by williamdclt on Saturday January 19, 2019 @05:28AM
(#18946321)
Of course I want the type checking locally, what we mean is that we don't want it to prevent webpack to build if the typecheck fails
Flow gives you all of that. The fact that the type checker is separated from the emitter does not mean you can't get any of that.
I don't really feel strongly about it, though sometimes Flow takes 10+ seconds to re-check a large project I work on after changes, and I wouldn't want building to have to wait on that. (I've never worked on a similarly-sized project in TypeScript, but I expect it's about the same situation.) I usually use a CI system (CircleCI) which sends me an email if any of my commits don't pass type checking or unit tests, and it flags any PRs on Github that fail too.