Loading popcode.org in IE results in hanging loader

The page errors out with 'Promise' is undefined before we can load <IEBrowserError>. Going to address with a polyfill.

@inlinestyle surprising/scary that our polyfill game is insufficient to handle this now! BTW is there some cute thing we can do to put the polyfill in via webpack/babel instead of having to explicitly put it in the code?

@outoftime I've been looking into this and I'm a bit flummoxed. This is what we're dealing with: https://github.com/webpack/webpack/issues/2739.

To summarize, webpack's code splitting is incompatible with the recommended polyfill approaches (and I've verified this by trying all of them that I could find). The only way I know of to get around this is to bypass webpack and manually insert a polyfill into the page's js.

Incidentally, it looks like System.import(...) is now deprecated in favor of import(...) for newer versions of webpack (also they just hit 3.0, may want to consider upgrading).

To summarize, webpack's code splitting is incompatible with the recommended polyfill approaches (and I've verified this by trying all of them that I could find). The only way I know of to get around this is to bypass webpack and manually insert a polyfill into the page's js.

…Yikes!

So just to confirm, the problem is that Webpack’s runtime code uses Promise before any statement in the application code could polyfill it?

Assuming you’ve tried it, but the multiple entries approach doesn’t work here?

Would the fix you’re proposing here to be something to the effect of putting the polyfill in a separate <script> tag before the application bundle?

Incidentally, it looks like System.import(...) is now deprecated in favor of import(...)

Yeah I saw that a little while ago, at the time it didn’t seem like there was broad tooling support for import() (eslint in particular iirc) but I’m sure they’ve caught up at this point

also they just hit 3.0, may want to consider upgrading

Good catch, will check it out!

@outoftime Yes, yes (it may be worth moving babel-polyfill from src/init to the entry config just because it's the general recommendation, but it doesn't change the load order to the extent that we'd need), and yes (or we could literally concatenate the polyfill to the bundle, though I believe this would have to be done outside of webpack).

Moving babel-polyfill to a separate entry and <script> is trivial enough, I'll do it if you think it's worth it (for the IE sadface message, and the possibility of eventual IE support).