Support for webpack resolution of modules.

[meirish]

When I tried to get Flow working in our project last week, I was saddened that it wouldn't work because of the custom resolution we're using via webpack's modulesDirectories.

You can read more about our folder structure here: https://gist.github.com/ryanflorence/daafb1e3cb8ad740b346#shared-module-resolution

And webpack's modulesDirectories here: http://webpack.github.io/docs/resolving.html#resolving-a-module-path

Is there any chance that Flow will support this?

[lencioni]

I am also interested in this. I asked a similar question in IRC in Feb: https://botbot.me/freenode/flowtype/2015-02-10/?msg=31705409&page=2

At the time, @gabelevi mentioned that @jeffmo and @mroch were already talking about how to build it.

This seems somewhat related to #101.

[jeffmo]

I have a feature that I'm working on (that should be ready fairly soon) that will allow you to specify a config entry that lets you write a search/replace regexp pattern that gets applied to all module names before flow attempts to resolve them.

It's mostly geared towards supporting things like module aliases, but depending on how complex your lookup algorithm is compared to the built-in one this might achieve what you want?

An example of the feature I'm describing would be that you could write a config entry like:

module.name_mapper="(.*)", "/some/path/to/where/my/modules/are/\1"

This would match all module names and rewrite them to an absolute path somewhere that contains all of your modules. You'll be able to specify multiple of these entries in order to write up different rewrites for different patterns.

Would this do what you need by chance?

[lencioni]

What is the behavior if a module name is matched by multiple entries?

[jeffmo]

There are a couple of options for how it could work, but at the moment it seems to me that the least surprising would be that the first one that matches (in order of specification) wins. Thoughts?

[lencioni]

My preference would be that the first one that matches that can actually resolve the file wins. That would allow you to have global defaults with reasonable fallbacks. It would also more closely match the strategy that webpack uses which could help for familiarity and adoption.

[meirish]

Sorry I'm late in replying, but this sounds like this would work swimmingly! +1 to first match that resolves a file wins.

[jeffmo]

Ok, I'll take a wack at first-to-match-and-stat. I'm slightly unsure about stating the fs so often (read: perf for big projects), but I might be able to make it work.

Thanks for the feedback, this was helpful!

[jeffmo]

I just landed this config option yesterday and summarized how it works over toward the end of the following issue. Thanks for the report!

#345

[AdamBrodzinski]

@jeffmo would this solve my use case for the webpack resolve path? If I use ../../components/Foo flow works but if I use components/Foo I get the following error:

src/pages/DashLayout.js:4
  4: import Header from 'components/Header';
                        ^^^^^^^^^^^^^^^^^^^ components/Header. Required module not found

[kompot]

@AdamBrodzinski Yes, it will help, take a look here.
cdebotton/react-universal@e57aadb

[AdamBrodzinski]

@kompot Thanks you're the best! working great now 😄

[dlindenkreuz]

For everyone looking at this issue in 2016, module.system.node.resolve_dirname was added in 0.18.1.

I solved this by adding these lines to my .flowconfig options (spares you the dreadfully long regex):

module.system.node.resolve_dirname=node_modules
module.system.node.resolve_dirname=src

The relevant part of my webpack config is:

resolve: {
  modules: ["src", "node_modules"]
}

[ghost]

@dlindenkreuz what did you do exactly? Problem remains for me.

E.g. for src/foo/bar.js, import stuff from 'foo/bar' doesnt work. Flow tells me
Required module not found.

[dlindenkreuz]

@MoeSattler The important part is that resolve_dirname in .flowconfig and the resolve paths for modules in the webpack config are the same.

Are you on a recent flow version (>= 0.18.1)? Sometimes, the locally installed flow version in node_modules/.bin/flow is different from the globally installed in /usr/bin/flow.

[renarsvilnis]

@MoeSattler Did you manage to set it up?
I have the same issue as you are having right now.

[turadg]

Note that this solutions no longer works in Flow 0.57.

In Flow 0.57 they introduced an optimization to,

only check the files in node_modules/ which are direct or transitive dependencies of the non-node_modules code.

Because the trick above made Flow think your app modules were another source of node_modules,
now the app source would not be focused either. You could see this in Flow logs by almost all app files being omitted from the "focused" count.

A working alternative is to explicitly define module.name_mapper directives for each child of your root directory, to tell Flow how to resolve those files. (Thanks to cdebotton/react-universal@e57aadb#commitcomment-19062820 for the idea.)

This script generates the directives you need in [options] of your .flowconfig:
https://gist.github.com/turadg/4c11ef9ac1af7b41276d0acc4d4bf8c8

[kentcdodds]

Hmmm... the solution above seemed to work fine for me in flow@0.66.0

[JohnDDuncanIII]

@kentcdodds I can't get this to work in flow 0.72.0

in .flowconfig:

[options]
module.system.node.resolve_dirname=node_modules

in webpack config:

resolve: {
  modules: ["node_modules"]
}

I'm trying to do something like import moment from 'moment' but I'm given Cannot resolve module moment. Do you know if this solution is supposed to work in this version of flow, or is there a new workaround?

[TrySound]

@JohnDDuncanIII Do you use monorepo?