This is a good question! Looks pretty easy to fix...jsx-loader just needs support a stripTypes flag in addition to the harmony tag. I'll send a PR to https://github.com/petehunt/jsx-loader
That's part of it, but the other part would be having Flow run when I make changes to my code. If I were to adopt Flow, I'd want it to integrate into my existing workflow, which is centered around Webpack.
The main Flow workflow has Flow running as a daemon in the background. It watches for code changes and notices errors, which it reports to you when you call flow (aka flow status).
If you wanted Flow as a prepublish hook or a test-ish thing, there is flow check which, instead of running as a daemon, runs in the foreground and does a full check from scratch.
Created https://github.com/petehunt/jsx-loader/pull/31 for the jsx-loader support
that was fast
jsx-loader was pushed 2 hours ago. Closing this out.
a flow pre-loader might be nice, like jshint-loader
That's what I in intended when I opened this.
@appsforartists Did you manage to find a good solution for this? flowcheck-loader works up to a point but fails with some advanced features (stage 1 decorators etc.).
@appsforartists I figured out a workaround. You can try something like loaders: ['react-hot', 'babel', 'flowcheck', 'babel?stage=0&blacklist=flow']. See https://github.com/gcanti/flowcheck/issues/19 for further discussion.
Any update on a flow pre-loader?
@breandr Check out babel-plugin-typecheck. I feel that's a better alternative than flowcheck right now.
I just dump babel results to disk before my packager gets started, in a build directory. There's really no need for these preloaders and adapters.
@bebraw Plus I'm guessing that flowcheck would slow down my app at least as much as React PropType checks (which come out at the top of my profiling results and make some mouse drag interactions laggy due to the complexity of my app). So I'd rather just stick with compile-time checks right now.
@jedwards1211 Flow is surprisingly fast in daemon mode actually. But yeah, even something like babel-plugin-typecheck is quite nice even if it's not exactly the same.
@bebraw yes Flow is fast, but it has nothing to do with flowcheck does it? As far as I understand flowcheck just runs JS code injected into your app to validate at runtime, rather than interacting with a Flow daemon in any way. It's the runtime validation I'd expect to be slow, not the compile-time checks that Flow does.
@jedwards1211 Correct. The runtime checks are pretty much equal to what you get with propTypes as far as I understand. It just generates some runtime asserts there. So it's nowhere near the same, but far better than nothing.
any flowtype webpack integration to see flow status results in webpack output ?
It's at least possible to create a webpack plugin that execs flow status every time something is recompiled...I'll probably do that at some point if no one else does
@jedwards1211 That's the sort of thing I came here looking for. At the moment I'm using eslint-loader for webpack to lint my code every time I change something. It would be awesome to integrate flowtype into that process, and see the output of flow status whenever webpack detects a change.
It figures someone would have done that by now -- thanks for pointing that out!
@camjackson heh...I tried it but I don't always see the flow status output, and there is no github or issues link in that npm package, which is the only thing its author has published to npm. The code is simple enough, the problem is that it only outputs status if it got to run flow start itself, so I'm just going to manually fork it and make it run flow status regardless.
@jedwards1211 Yeah it's annoying when npm doesn't link to github. I managed to find it though if you want to open an issue: https://github.com/diegodurli/flow-status-webpack-plugin
@camjackson I did and made a fork; warning!! I would recommend using my fork until my PR gets merged, mainly because the FlowStatusPlugin constructor in the public package has the surprising side effect of restarting the flow server.
@jedwards1211 As far as I can tell that plugin won't fail the webpack build if there are flow errors? Is there a plugin that can do that? I thought that would be the whole point of a webpack plugin for flow :D
@moljac024 right, it doesn't fail the build, which would be helpful.
As an aside, these days instead of using that plugin I just use a separate watch script (though I haven't figured out how to get it to preserve formatting and font weight):
#!/bin/bash
which wr || npm i -g wr
flow status
wr --exec "clear && printf '\e[3J'; flow status" src test
Another option I was thinking about is to expose webpack's cache as FUSE filesystem and let flow check files from there.
I have implemented a basic version of the flow webpack plugin, that fails the build on errors. You can find it at my fork, which isn't merged upstream yet.
Meanwhile I decided to implement a true [pre]-loader that calls flow check-contents individually for each file matched and aborts on error.
```.sh
$ npm install --save-dev flow-bin flow-bin-loader
```.js
module.exports = {
// ...
module: {
preLoaders: [
// ...
{
test: /\.js$/,
loader: 'flow-bin',
exclude: /node_modules/,
},
// ...
]
},
// ...
}
The implementation is straightforward enough to fit here:
```.js
const spawn = require('child_process').spawn;
module.exports = function(source, map) {
const cb = this.async();
const flow = spawn(require('flow-bin'), ['check-contents']);
let stdout = '';
flow.stdout.on('data', (data) => {
stdout += data;
});
flow.on('close', (code) => {
if(code)
console.log(stdout.replace(/^-(:[0-9]+.*)/, ${this.resourcePath}$1));
cb(code ? code : null, source, map);
});
flow.stdin.write(source)
flow.stdin.end();
};
```
Still no loader available for flow with webpack ?
@bboysathish did you try https://www.npmjs.com/package/flow-bin-loader?
Most helpful comment
I have implemented a basic version of the flow webpack plugin, that fails the build on errors. You can find it at my fork, which isn't merged upstream yet.