Issue 1:
The new version of Sinon is throwing webpack for a loop again. This code:

function makePublicAPI(require, exports, module) {
module.exports = sinon;
sinon.spy = require("./sinon/spy");
sinon.spyCall = require("./sinon/call");
sinon.behavior = require("./sinon/behavior");
sinon.stub = require("./sinon/stub");
sinon.mock = require("./sinon/mock");
sinon.collection = require("./sinon/collection");
sinon.assert = require("./sinon/assert");
sinon.sandbox = require("./sinon/sandbox");
sinon.test = require("./sinon/test");
sinon.testCase = require("./sinon/test_case");
sinon.match = require("./sinon/match");
}

if (isAMD) {
define(makePublicAPI);
} else if (isNode) {
try {
formatio = require("formatio");
} catch (e) {}
makePublicAPI(require, exports, module); <========
}

Is causing this warning:

WARNING in ./~/sinon/lib/sinon.js
Critical dependencies:
365:22-29 require function is used in a way, in which dependencies cannot be statically extracted
@ ./~/sinon/lib/sinon.js 365:22-29

It's not obvious to me how to work around this. Any of you have any bright ideas?

(the line number indicated in the error, 365, is clearly wrong, and the line with the arrow is actually the offending code)

Issue 2:
I'm submitting a bug report

Webpack version:

1.13.1

Please tell us about your environment:

Linux

Current behavior:

Trying to get code split between multiple entry points, with each entry point split into own code and vendor bundle, then commons extracted for both own code and vendor bundles.

Entry points look like:

entry: {
login: './src/Login/index.jsx',
app: './src/index.jsx',
vendor: Object.keys(packageDotJson.dependencies).filter(function (element) {
return element !== 'font-awesome' && element !== 'jspdf';
}),
loginvendor: packageDotJson.loginDependencies
},

The following works as expected:

new webpack.optimize.CommonsChunkPlugin({
name: "vendor",
chunks: ["app"],
minChunks: Infinity
}),
new webpack.optimize.CommonsChunkPlugin({
name: "loginvendor",
chunks: ["login"],
minChunks: Infinity
}),
new webpack.optimize.CommonsChunkPlugin({
name: "vendor.commons",
chunks: ["vendor", "loginvendor"],
minChunks: 2
}),

Vendor bundles are extracted from each entry point bundle, then a common vendor bundle is extracted from the two vendor bundles.

Grepping the build results for definitions of commonly used packages like babal-polyfill and React, they are correctly found only in vendor.commons file.

Adding:

new webpack.optimize.CommonsChunkPlugin({
name: "commons",
chunks: ["app", "login"],
minChunks: 2
}),

and testing for the same packages, we have:

> grep -R "var React = {" ./dist -l
./dist/vendor.commons.080acb7415d897182eca.js
./dist/commons.080acb7415d897182eca.js

It seems the final invoking of the plugin is selecting the original app and login chunks, as they were before vendor modules were removed into vendor and loginvendor chunks.

Expected/desired behavior:

Expecting

new webpack.optimize.CommonsChunkPlugin({
name: "commons",
chunks: ["app", "login"],
minChunks: 2
}),

to select the app and login chunks with vendor modules removed and extract the common modules from them into commons chunk. Vendor modules shouldn't appear both in commons and vendor.commons chunks.

What is the motivation / use case for changing the behavior?

It seems logical to expect that instances of the plugin will be ran sequentially and that every run will have access to chunks modified by the previous run.

This specific use case if for production build. We need vendor code in separate bundles to avoid generating sourcemaps for it. Multiple entry points are needed to avoid serving a lot of unnecessary code to the user. Common modules are extracted to avoid duplication.

Browser: [ Chrome 52.0.2743.116 (64-bit) ]

Language: [ ES6/7 ]