Those docs are pretty funny; they start out with the explicit vendor example, where they are manually specifying the modules to put in vendor (in the example, it's just
moment). Then they say, oh, you can do this automatically and they show the code for that. Then they say, but wait that's stupid because you have a runtime manifest that changes every time and will negate any caching benefit. So, then they go back to the explicit vendor bundle again. So it seems, according to the docs, that you can't really actually do the implicit vendor bundle, or at least it wouldn't make sense to.
By the way, Alex, we should look into this runtime manifest bundle thing, I don't think we've actually checked to make sure our vendor bundle's hash is the same if we haven't changed dependencies.
Maybe I can skip listing the entry point of babel-polyfill and instead put this in an import?
That would work too, but you'd have to do it in the entry point of every bundle, so I would just opt for the explicit vendor bundle approach and put it in there. I'm not sure how to accomplish this with the implicit/auto-computed approach.
And then webpack v2 will magically put babel-polyfill in the vendor-bundle?
I can't say for sure, but I would think if you explicitly tell Webpack that you want babel-polyfill in your app bundle's entry points, then I don't think it will take it out and put it into vendor. I could be wrong though.
Would the same apply for 'es5-shim'? Is this still needed?
I can't remember the reason for the es5-shim. I'm not sure if it's for browser compatibility or was for fixing execjs problems back when we were still using that for server rendering. We should definitely take another look at this.