-
Notifications
You must be signed in to change notification settings - Fork 1.9k
Implement a Webpack loader #5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
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 If you wanted Flow as a prepublish hook or a test-ish thing, there is |
Created petehunt/jsx-loader#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 |
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 |
any flowtype webpack integration to see flow status results in webpack output ? |
It's at least possible to create a webpack plugin that execs |
@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 |
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 |
@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 |
@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. #!/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 $ npm install --save-dev flow-bin flow-bin-loader module.exports = {
// ...
module: {
preLoaders: [
// ...
{
test: /\.js$/,
loader: 'flow-bin',
exclude: /node_modules/,
},
// ...
]
},
// ...
} The implementation is straightforward enough to fit here: 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? |
We use webpack for transforming JSX to JS, dependency management, and concatenation. It would be lovely if Flow was callable as a Webpack loader:
The text was updated successfully, but these errors were encountered: