@lpproulx the polyfill service is designed to produce scripts, not a AMD module. The fact that the polyfill service might produce an empty string (e.g.: https://cdn.polyfill.io/v2/polyfill.min.js?features=Intl.~locale.en in chrome will be empty) because there is nothing to do in that browser, and therefore IntlPolyfill will not be defined. I'm not sure what exactly are you trying to do, but my recommendation is to not require polyfills as dependencies, they are just part of the environment patching process, and should happen before any of your modules are evaluated.

@caridy I was trying to load the script after the user was logged on our application. The goal was to only load the needed locale by dynamically creating the url with the user preference.

I have been able to kinda fix(hack) by first getting the Intl alone and putting the polyfill in the IntPolyfill variable then making an other call to get the same script now with the locale. The second call is only made if the first return something, so it's not done in chrome. There is no way to only load the locale without the script?

oh, if that's the case, you can generate the url dynamically, (e.g.: https://cdn.polyfill.io/v2/polyfill.min.js?features=Intl.~locale.fr), use AMD to evaluate the code and wait for it to finish, but don't use IntlPolyfill in your code at all. when AMD module gets evaluated, the new Intl and the new locale information will be added when needed, otherwise, the browser will provide you with anything you need.

The problem is that i'm not using IntPolyfill. It's the service that is using this variable :

//# sourceMappingURL=Intl.min.js.map
IntlPolyfill.__addLocaleData({locale:"fr",date:{

the polyfill service will only return that function call if Intl is not available in the browser, and if that's the case, then it will also bring IntlPolyfill along the way since it will be a dependency of Intl.~locale.fr. I don't see how is that you get IntlPolyfill.__addLocaleData when Intl is not needed. Maybe I'm missing something here...

You can try to run the jsfiddle in safari or IE which doesn't support Intl and you'll see the error in the console.

Ok, I now understand the issue, the problem is that if AMD loader is in place, it will skip the registration process of IntlPolyfill, based on this line:
https://github.com/andyearnshaw/Intl.js/blob/master/dist/Intl.js#L4

as a temporary workaround, you can define IntlPolyfill.__addLocaleData method, and when it gets call, you get the Intl module from your amd, and call m.__addLocaleData method on it. But I will investigate how to deal with this particular issue in a way that works for everybody without a hack.

@caridy Any ETA on this? Anything I can do to help?

My situation is a bit different than what is outlined above. We are loading this polyfill on a page that uses require, but we're not using require for our app to prevent issues with our partner sites who may or may not be implementing require properly (or at all) (our app can be deployed in any number of places.)

Still thinking how to solve this. Essentially we need to make those jsonp files to work on various environment, allow the ability to intercept the data before calling __addLocaleData(), and allow them to work in environments where the global scope is not at reach.

Any update on this one?

/cc @juandopazo

The distribution file for the polyfill shouldn't be a UMD declaration. If someone wants to use it as a module, they should bundle it themselves with their application code.

@juandopazo I agree! but this will be a breaking change, we will have to bump to 1.3.x. A PR will be welcome :)

for me just require('intl') in my app.js works.