Flow: JSPM compatibility

[davis]

Hi,

I use jspm/systemjs to develop/bundle my apps, and I was wondering if flow has custom module resolving ability so that I don't get this when running flow:

composite-view.js:5:26,35: backbone
Required module not found

composite-view.js:6:29,40: marionette
Required module not found

composite-view.js:7:19,34: backbone.radio
Required module not found

composite-view.js:8:15,22: jquery
Required module not found

composite-view.js:9:15,22: lodash
Required module not found

composite-view.js:12:22,38: ./template.hbs!
Required module not found

Found 6 errors

Thanks!

[samwgoldman]

@davis The module resolution code is pluggable, but only two have actually been implemented: haste (a FB thing) and node (npm/commonjs).

Can you provide some examples of how JSPM works? What's the module resolution strategy?

[davis]

@guybedford would probably speak better to this... :D

[jeffmo]

I think this would require Flow somehow running peoples' custom loaders in order to resolve module locations, right? If so this seems technically doable, but we haven't really explored it because I doubt this would scale very well for large projects. That's not to say it wouldn't be useful for smaller projects though...

I don't know if the core team will have the bandwidth to investigate this and work on it any time soon, but I would be happy to help work through a PR with someone if they wanted to take a crack at it to see how feasible it could be... As @samwgoldman mentioned we do have a system that supports toggling of resolution algorithms within Flow, so perhaps someone could build a subsystem that just calls out to a specified command that resolves module path queries?

[jeffmo]

BTW, see also: #686

[guybedford]

The module resolution in jspm is entirely based on the SystemJS loader configuration and rules, which is basically a configuration object driving the path normalization algorithm.

Perhaps a systemjs resolver could be integrated here, or alternatively as @jeffmo suggests, a custom resolve / fetch pipeline enabled so that it could be done via a third-party integration. Perhaps an internal resolver might be the shortest path though if there was someone suitably interested in working on this?

First-class flow support in jspm would be amazing, but I understand it's not an easy thing to prioritise. Do feel free to close this issue until such time as someone with the bandwidth to take it on is interested in picking it up again.

[jeffmo]

which is basically a configuration object driving the path normalization algorithm

Interesting, is that object typically built in a way that could be statically read? If so, having a built-in "systemjs" module system that just reads that and handles things accordingly is also totally an option

[guybedford]

@jeffmo yes the SystemJS config object can be statically read in all user workflows today, although there is one (currently little-used but soon to be more so) feature in SystemJS that dynamically loads configurations as they are needed which would change that, although the algorithm is still completely well-defined based on this configuration object. The hard part would be tracking patch changes to the resolution algorithm with SystemJS itself, so it may well make sense to only consider this when the project is completely stable.

[joncampbelldev]

+1 for this feature.

Are there any workarounds/hacks/bodges to get flow working with JSPM dependencies? Currently I can only use the type annotations inside modules with no dependencies, so I have nicely typed utils modules and nothing at all in higher level code :(

[bartzy]

+1 as well from me. I can't use Flow at the moment because I have imports like import View from 'MyModule/View' where MyModule is a path configuration in config.js in JSPM.

Any updates on this issue?

Thanks!

[NervosaX]

I know this is almost a good year old now, but I would like to just note a possible workaround until the day jspm might have first class support. You can use name_mapper to map between your package name and the jspm path:

I have the package sp-env-vars, with an index.js file. In .flowconfig I can add this as an option:

module.name_mapper='^sp-env-vars\/\(.*\)$' -> '<PROJECT_ROOT>/jspm_packages/npm/[email protected]/\1'
module.name_mapper='^sp-env-vars$' -> '<PROJECT_ROOT>/jspm_packages/npm/[email protected]/index.js'

Now import EnvVars from "sp-env-vars"; or import EnvVars from "sp-env-vars/index.js"; will resolve correctly.

Obviously writing these out could get tedious, so one could use SystemJS to read its config and generate these mappers for every jspm package (or the ones you care about at least), including their default paths.

Including a comment in your flow config like # Auto generated, do not edit could allow it to automatically insert into the file.

This is by no means perfect, but seems like a possible solution in the meantime.

[NervosaX]

Alright, I've done one better and wrote the above idea out. Seems to work well. :)

https://gist.github.com/NervosaX/eadc44f0f7159c43fdb2da35a2d56002

[alexisvincent]

I'm potentially planning on tackling this through systemjs-tools. Will let folks know when I do. But I'll be going the route of resolving files through the actual loader instance.

[JeffBaumgardt]

I'm also interested in this because flow catches on all require blocks. I tried the above gist and with some tweaking it did it's output but still flow coughed on jquery which was in the list. I would love to see a loader or something that could resolve the dependencies via the config file paths.

[NervosaX]

Hrm, that's odd @JeffBaumgardt. I've been using the script above for a little while now, and I haven't had anything fail.. unless jspm modifies a version and I forget to update the list. That's one massive downside to this process.

[JeffBaumgardt]

Yeah I don't understand it very well but I ran the script which output what
looked to be correct based on the gist you had. But running flow still
caught everything like jquery.

We probably have to wait until there is a resolver that flow go reference
through so that the jspm.config can be properly referenced for paths. I
have a lot of dependencies that sit in various places off of root.

On Wed, Feb 1, 2017 at 2:29 PM, Adam Hoddinott [e-mail]
wrote:

Hrm, that's odd @JeffBaumgardt https://github.com/JeffBaumgardt. I've
been using the script above for a little while now, and I haven't had
anything fail.. unless jspm modifies a version and I forget to update the
list. That's one massive downside to this process.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/facebook/flow/issues/754#issuecomment-276788105, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAvdN2vz6KNhRMIlAXLlj066N3wDCb2aks5rYPktgaJpZM4Fzq_M
.