4 ms·
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 alw
by AgentME 8y ago
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.
- ng12 8y agoDon't you want your build to fail if the type checker fails? I think it's pretty important for a large project.
- williamdclt 8y agoNot 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")
- nrb 8y agoI 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.
- munchor 8y agoFlow 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.
- williamdclt 8y agoOf 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
- AgentME 8y agoI 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.
- root_axis 8y agoOnly in CI, not during development. IDE warnings are enough.