Re:Future of TypeScript on ESLint
by AgentME on Friday January 18, 2019 @05:28PM
(#18943706)
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.
[ Parent
| on HN ]
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.