Issue 1:
Do you want to request a feature or report a bug?

bug

What is the current behavior?

const context = require.context("./src/", true, /\.spec\.js$/);

context.keys().forEach(function(key) {
if (require.resolveWeak(key.replace(".spec.", "."))) {
context(key);
}
});

Result: ERROR: Cannot find module "."

If the current behavior is a bug, please provide the steps to reproduce.

Put e.g. some-component.js file with some-component.spec.js to src dir.

Use the code above in the main module.

Compile

What is the expected behavior?

require.resolveWeak should return a falsy value in case of not existed module.

If this is a feature request, what is motivation or use case for changing the behavior?

Please mention other relevant information such as the browser version, Node.js version, webpack version and Operating System.

Webpack 2.4.1, Mac OS 10.12.4, Node 6.10.1

Issue 2:
Do you want to request a feature or report a bug?

Request a feature.

What is the current behavior?

If the current behavior is a bug, please provide the steps to reproduce.

What is the expected behavior?

If this is a feature request, what is motivation or use case for changing the behavior?

The current include and exclude loader options allow developers to include/exclude particular files, but in many cases its far more useful to include/exclude entire branches in the dependency tree.

This will become more and more important (specifically in the case of babel-loader) as more and more browsers begin to natively support ES2015+ features. Right now it's common for module authors to publish the compiled versions of their code, but I don't think that should be considered a best practice going forward.

Consider this scenario: if one or more of my module dependencies publish their source files as ES2015, it's much more complicated than it should be to include them in the transpilation step while also excluding all other modules because it requires intimate knowledge of that module's dependency tree.

You can whitelist (via include) certain modules, but this won't always work because you need to know the full module path, which is problematic since npm sometimes installs a module directly under node_modules and other times it installs a module in a nested node_modules folder.

To solve this issue, I think it'd be nice to add something like an excludeTree option. This option would accept an array of npm module names and exclude any files in that module's source as well as any files in the source of any of its dependencies (via package.json).

{
excludeTree: ['react', 'core-js'],
}

excludeTree is useful for cases where most of your dependencies need to be transpiled. Today, however, the norm is that most of your dependencies are published as ES5, so in these cases what you generally want to do is something like the following (which assumes a matchesExcludeTree() function exists):

{
exclude: (absPath) => {
// Exclude all node modules *unless* they're in the following list
// of packages (and their dependencies).
return absPath.includes('node_modules') &&
!matchesExcludeTree(absPath, ['autotrack']);
}
}

Perhaps in this case it makes sense to have exclude/excludeTree work in conjunction with include/includeTree. That way the above imperative logic could be rewritten declaratively like this:

{
exclude: /node_modules/,
includeTree: 'autotrack'
}

For some additional context as to why this is a problem, see this issue:

googleanalytics/autotrack#137

Please mention other relevant information such as the browser version, Node.js version, webpack version and Operating System.