Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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.


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.


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.


Only in CI, not during development. IDE warnings are enough.




Consider applying for YC's Summer 2026 batch! Applications are open till May 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: