Flow: @providesModule for public use?

Created on 18 Oct 2016 · 9Comments · Source: facebook/flow

Hello,

The Facebook F8 App makes quite heavy use of @providesModule with Flow. Now it's possible to use this ourselves if we include the module/files in the .flowconfig and have access to "global" modules we define with @providesModule without figuring out the relative paths.

This works great, however I'm struggling to find much about it in the documentation. Are we supposed to use this in our own environment or not? If not, why not?

It makes life so much simpler, but I can't work out whether I should be doing it.

Source

Ehesp

Most helpful comment

To have path aliasing, you can use webpack's resolve.alias. If you're using react-native and can't configure webpack, then babel's babel-plugin-module-resolver should work. If that, you'll also need to create an rn-cli.config.js file with this content:

'use strict'

var path = require('path')

var config = {
  getProjectRoots() {
    return getRoots()
  },

  getAssetRoots() {
    return getRoots()
  },
}

function getRoots() {
  return [
    __dirname
  ]
}

module.exports = config

AriaMinaei on 25 Jan 2017

👍2

All 9 comments

@providesModule is a facebookism. I do not recommend that you use it, since all of your infra has to support it. But you can find out more about it at https://github.com/facebookarchive/node-haste and https://github.com/facebook/jest/tree/master/packages/jest-haste-map.

zertosh on 19 Oct 2016

Agree with @zertosh. Haste is something Flow supports, but people outside of FB probably shouldn't be using it (unless you are @ide).

samwgoldman on 20 Oct 2016

Thanks guys.

@samwgoldman is there anything similar which is less internal which can potentially produce this sort of functionality?

Ehesp on 20 Oct 2016

You're welcome to use haste, but it's not a Flow thing, which is why we don't have documentation for it. Do either of the links Andres shared help?

samwgoldman on 20 Oct 2016

Yeah they do thanks, just trying to get my head around it.

The confusion really comes from the open source example of "your" F8 App which uses this all over the place. There was an issue there (https://github.com/fbsamples/f8app/issues/72) about this, hence me bringing this up here as I thought it was a flow thing

Ehesp on 20 Oct 2016

@samwgoldman Just FYI we do use Haste in a couple of places with the understanding that it's on us to make it work for our use cases and that the code is the documentation.

Haste is pretty useful and I think the right way to do modules within packages (interpackage imports don't change at all in the spec I have in mind) so I'd like to see it proliferate but no one's working on making that happen at the moment.

ide on 20 Oct 2016

👍1

For the ones interested in using Haste, I've written a simple webpack resolver that can use it: https://github.com/flegall/haste-map-webpack-resolver

flegall on 23 Jan 2017

'use strict'

var path = require('path')

var config = {
  getProjectRoots() {
    return getRoots()
  },

  getAssetRoots() {
    return getRoots()
  },
}

function getRoots() {
  return [
    __dirname
  ]
}

module.exports = config

AriaMinaei on 25 Jan 2017

👍2

@samwgoldman honesly I hope Facebook stops using it too, any time I (unintentionally wind up with multiple versions of a dep that uses @providesModule installed, I just get annoying useless errors: #6475