Add support for Webpack 2 renamed modules key

[pascalduez]

Hi,

just wanted to start the ball rolling, there most likely will be more work needed to fully support Webpack 2, but that very simple addition is already doing it for me on a project with custom import paths.

Rough changelog: https://gist.github.com/sokra/27b24881210b56bbaff7#resolving-options

If you feel that's okay for a start, I'll update the tests ?

Refs #265

[benmosher]

I like the simplicity. I don't have any Webpack 2 projects to check against, so I'll take your word for it. 😎

New tests would be much appreciated. Probably a clone of the existing moduleDirectories tests would be a good start, assuming the semantics match.

[benmosher]

Heads up: this will probably not be mergeable after I merge #345.

I think it will make more sense to make a webpack-2 resolver, see my notes on #345.

[michael-wolfenden]

@benmosher

In webpack2, resolve.root has been merged into the modules option, however the commit doesn't handle this.

webpack

resolve: {
    root: PATHS.appDir
}

webpack2

resolve: {
    modules: [
        'node_modules',
        PATHS.appDir,
    ],
},

I had to add the following code to make this work, the assumption being that root resolves are absolute paths

// Webpack >= 2
var rootPaths = get(webpackConfig, ['resolve', 'modules'], []).filter(path.isAbsolute);
paths = paths.concat(rootPaths)

[gausie]

Now that #345 is merged, how are you feeling about this @benmosher?

[benmosher]

I think I'd probably opt for a webpack2 resolver, mostly because there is a factory (in enhanced-resolve v2+) to build resolve from config that would be nice to leverage for ongoing correctness.

I can maintain it here (another PR, anyone?), or someone in the community can maintain it independently. Either way works for me.

I don't think I would keep this duck-typed version. I'm not sure how it would integrate with the current webpack resolver.

[pascalduez]

Let's close this and do it the proper way :)