Skip to content

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

Closed
appsforartists opened this issue Nov 18, 2014 · 32 comments
Closed

Implement a Webpack loader #5

appsforartists opened this issue Nov 18, 2014 · 32 comments
Assignees

Comments

@appsforartists
Copy link

We use webpack for transforming JSX to JS, dependency management, and concatenation. It would be lovely if Flow was callable as a Webpack loader:

    {
      "test":   /\.jsx?$/,
      "loader": "react-hot-loader!flow-loader!jsx-loader?harmony"
    },
@gabelevi
Copy link
Contributor

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

@gabelevi gabelevi self-assigned this Nov 18, 2014
@appsforartists
Copy link
Author

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.

@gabelevi
Copy link
Contributor

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.

@gabelevi
Copy link
Contributor

Created petehunt/jsx-loader#31 for the jsx-loader support

@StoneCypher
Copy link

that was fast

@gabelevi
Copy link
Contributor

jsx-loader was pushed 2 hours ago. Closing this out.

@nelix
Copy link

nelix commented Nov 19, 2014

a flow pre-loader might be nice, like jshint-loader

@appsforartists
Copy link
Author

That's what I in intended when I opened this.

@bebraw
Copy link

bebraw commented Apr 22, 2015

@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.).

@bebraw
Copy link

bebraw commented Apr 22, 2015

@appsforartists I figured out a workaround. You can try something like loaders: ['react-hot', 'babel', 'flowcheck', 'babel?stage=0&blacklist=flow']. See gcanti/flowcheck#19 for further discussion.

@brettstack
Copy link

Any update on a flow pre-loader?

@bebraw
Copy link

bebraw commented Sep 29, 2015

@breandr Check out babel-plugin-typecheck. I feel that's a better alternative than flowcheck right now.

@StoneCypher
Copy link

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.

@jedwards1211
Copy link
Contributor

@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.

@bebraw
Copy link

bebraw commented Jan 18, 2016

@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.

@jedwards1211
Copy link
Contributor

@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.

@bebraw
Copy link

bebraw commented Jan 19, 2016

@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.

@artyomtrityak
Copy link

any flowtype webpack integration to see flow status results in webpack output ?

@jedwards1211
Copy link
Contributor

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

@camjackson
Copy link

@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.

@camjackson
Copy link

Oh wait, I just found flow-status-webpack-plugin: npm | github

screen shot 2016-03-13 at 1 07 54 pm

@jedwards1211
Copy link
Contributor

It figures someone would have done that by now -- thanks for pointing that out!

@jedwards1211
Copy link
Contributor

@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.

@camjackson
Copy link

@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

@jedwards1211
Copy link
Contributor

@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.

@moljac024
Copy link

@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

@jedwards1211
Copy link
Contributor

jedwards1211 commented Jun 24, 2016

@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

@andreypopp
Copy link
Contributor

Another option I was thinking about is to expose webpack's cache as FUSE filesystem and let flow check files from there.

@moljac024
Copy link

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.

@brunocodutra
Copy link

Meanwhile I decided to implement a true [pre]-loader that calls flow check-contents individually for each file matched and aborts on error.

$ 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();
};

@sathishsoundharajan
Copy link

Still no loader available for flow with webpack ?

@brunocodutra
Copy link

@bboysathish did you try https://www.npmjs.com/package/flow-bin-loader?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests