Flow: Support sourcemaps

[ccapndave]

It would be great to support sourcemaps such that when running flow against code that was transpiled from another language (i.e. ES6/7 via Babel) we get the real line numbers in error messages.

[samwgoldman]

Generally, flow should run on the same code that is then processed by something like babel.

Currently, if you want to write code that uses ES6 features unsupported by flow, you need to run flow on post-transpiled code, but eventually we plan to implement all the same features in our parser/type system.

Therefore, I think this is more of a "wishlist" feature, since we want to solve this problem by making transpiler-before-check unnecessary.

[ccapndave]

Fair enough.

In the end I did what you suggested and ran flow on post-transpiled code. As the process was a little fiddly I blogged my method at http://www.keendevelopment.ch/flow-babel-gulp-es6/

Hope it helps someone!

[samwgoldman]

I'm glad you found something that works. Nice post, by the way. I think you might find that what you are calling "requirement types" is more commonly called "structural types" in the literature.

I'm curious, though, what prevented flow from analyzing your pre-transpiled source code? Lots of ES6 features are still pending, but it helps to prioritize based on what people are actually using.

[ccapndave]

Many thanks - I'll update the post with the proper terminology :)

Specifically it was const that was stopping me from using Flow (I use constants almost everywhere).

[kevinpeno]

Please consider adding this option. Something like sweet.js would never be implemented by flow (because how would you implement my macros?), but its output does include sourcemaps allowing me to reasonably debug my code.

I'm sure there are endless examples out there that fit this bill. Best of all this means that Flow wouldn't need to implement the endless list of features and could focus solely on type management.

_Don't get me wrong. I understand there is a difference between const and the "polyfill" for it and Flow might have to actually implement stuff like that to infer appropriately. Just saying there are edge cases that don't break this functionality but might need to be considered by devs using flow_

[nmn]

Seems like a non-issue now that Flow support all of ES6 anyway.

[osuushi]

Sorry to tack this onto a closed thread (happy to open a new issue if that's preferred), but it seems strange to me that this would be considered a non-issue. Babel is used these days for far more than ES6 compatibility; indeed, flow itself uses Babel for a non-ES6 purpose.

Personally, I consider it a fundamental design flaw for any tool to require itself to be the first step in a pipeline. For one thing, any two tools which have this requirement are inherently incompatible. More importantly, there are almost always legitimate reasons to want to insert earlier steps.

Concretely, I would like to be able to write macros (as Babel plugins) specifically for interacting with the type system. If flow can consume source maps, this is pretty trivial. If it can't, you're stuck doing some kind of nastiness like wrapping the flow executable so that you can translate locations from the native flow output.