[AgentME]

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]

Don't you want your build to fail if the type checker fails? I think it's pretty important for a large project.

[williamdclt]

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")

[nrb]

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.

[williamdclt]

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

[munchor]

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.

[AgentME]

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.

[root_axis]

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