If that can help I provided an answer on SO that worked for me:
http://stackoverflow.com/questions/27870974/what-is-the-correct-way-to-load-polyfills-and-shims-with-browserify/28964831

See also: browserify/browserify#1155

I will not recommend using browserify/webpack for polyfills because that means loading all that extra baggage for modern browsers, so you're essentially penalizing users running the latest version of chrome for example. Even though those polyfills will not be applied because they don't need to, they will be loaded and patched.

So this seems a bit contradictory to what yepnope authors think :)

I don't care so much about bundle, as I split my bundle in appLibs.js + app.js, appLibs.js takes some time to load only the first time and is cached after that. And connection throughput is pretty good, even on mobile. Issuing a new request on mobile just to load yepnope can actually take more time than having some useless polyfills into a single bundle file.

from the historical POV: yepnope was creating by alex way before polyfills became popular :)

from the perf POV: it is not only about loading cacheable content (appLibs.js) it is about the cost of parsing and executing that code unnecessarily, and penalizing users of newer/evergreen browsers.

from the eng POV: using yepnope means that your app logic will have to wait for a callback (yepnope callback) to initialize your code, which isn't ideal, while using something like the polyfill service, you can have something like this:

<script>
console.log(new Intl.NumberFormat('en').format(Date.now()));
</script>

and you know that will work, there is no wrapping, it just works, and more than that, it works in the best possible way!

@caridy I understand your point about parsing and loading in memory unnecessary JS.

I don't understand what you mean by "the polyfill service"?

@slorber https://cdn.polyfill.io/v1/docs/, that's one example of a polyfill service. Probably the most successful one. I don't think they support Intl yet, but we can ask them.

never heard of this before but I really like this! thanks
polyfillpolyfill/polyfill-service#108

Yeah running into the same thing for webpack, where the webpack build even minified adds like 600kb. I know there are things like the ContextReplacementPlugin that people used to solve a similar issue for moment, but I'm looking for any guidance. http://stackoverflow.com/questions/25384360/how-to-prevent-moment-js-from-loading-locales-with-webpack

Edit: In my case it looks like the solution was just require('intl/Intl'). I don't need any country-specific stuff as I'm just using the basic messaging stuff..with react-intl

Proper webpack answer:

// lib/compat.js
module.exports = function(callback) {
    // shim for Intl needs to be loaded dynamically
    // so we callback when we're done to represent
    // some kind of "compatReady" event
    if (!window.Intl) {
        require(['intl/Intl'], function(Intl) {
            window.Intl = Intl;
            callback();
        });
    } else {
        setTimeout(callback, 0); // force async
    }
};

// app.js
var compatReady = require('lib/compat');
compatReady(startApp);

Edit: Also posted to stackoverflow http://stackoverflow.com/questions/29804786/intl-js-polyfill-shim-with-webpack/29804787

Intl support is in QA for the polyfill service: http://qa.polyfill.io/v1/polyfill.js?features=Intl.~locale.es, I will close this issue as soon as it lands in production, after updating the docs on how to load the polyfill.

Some progress on this: #121

Webpack and Browserify are now documented in the README.md.