Having issues running a new CLI Webpack 4 (esnext not typescript) app with IE11. I get an error about “Out of stack space”. From what I can gather off google it has something to do with babel and polyfills. What I haven’t been able to find is a fix. Anyone have a fix for this?
Try putting this in your index.ejs and see if it works:
<script src="https://cdnjs.cloudflare.com/ajax/libs/babel-polyfill/6.26.0/polyfill.js" integrity="sha256-qyG2LBYZavhW0RXdL7CQGGv2dX4WP30uIFPguGoOLjE=" crossorigin="anonymous"></script>
I’ve also run into issues with LARGE projects where IE cannot handle Aurelia loading all the components.
My solution was to lazy load non essential plugins/resources after the initial load in the main app’s activate method. And even then I had to do a third load at one point as there seems to be some specific hard limit.
public activate(): Promise<void> {
return new FrameworkConfiguration(this.aurelia)
.plugin(PLATFORM.moduleName("xxxx", "resources"))
.plugin(PLATFORM.moduleName("aurelia-widgets", "resources"))
.plugin(PLATFORM.moduleName("aurelia-gridstack", "resources"))
.plugin(PLATFORM.moduleName("xxxxx", "resources"))
.plugin(PLATFORM.moduleName("system-apps/xxxx-app", "resources"))
.plugin(PLATFORM.moduleName("system-apps/xxxx-app", "resources"))
.plugin(PLATFORM.moduleName("system-apps/xxxx-app", "resources"))
.plugin(PLATFORM.moduleName("system-apps/xxxx-app", "resources"))
.plugin(PLATFORM.moduleName("system-apps/xxxx-app", "resources"))
.plugin(PLATFORM.moduleName("system-apps/xxxxx-app", "resources"))
.plugin(PLATFORM.moduleName("system-apps/x-app", "resources"))
.plugin(PLATFORM.moduleName("system-apps/xxxx-app", "resources"))
.plugin(PLATFORM.moduleName("system-apps/xxxx-app", "resources"))
.plugin(PLATFORM.moduleName("xxxx", "xxxxx"))
.apply().then(() => {
return new FrameworkConfiguration(this.aurelia)
.plugin(PLATFORM.moduleName("aurelia-resources", "resources")).apply();
});
We had problems since IE11 does not support Promise at all so Aurelia did not even load so tried bluebird but that slows things down very considerably. The larger the JavaScript files loaded the worse it gets. Whilst looking at some of the JavaScript component offerings (not mentioning any names) found many too slow to be useable on IE11. Would recommend using Edge which does support Promise() out of the box and adding as few things as possible…
Thanks @Kukks, that fixed the issue. I’ll need to set it up in webpack to make sure it’s loaded before anything else. My biggest concern @discourse is the fact that I setup a brand new webpack 4 project from the CLI (0.33.1, latest version from npm) and just simply ran it without adding a single line of code. This means anyone who wants to try out aurelia for the first time or even to update their apps to webpack 4, will out-of-the-box have an issue with IE. I have no issues making things work when it’s something I’ve added but I feel this should work for IE too (even though I HATE working with IE) since most enterprise (such as ours) mainly uses IE.
Would recommend using Edge
Ha…I wish! Unfortunately in the enterprise world we typically do not have that option. We’re even fortunate that we can force =>IE11. If I were king (as a friend of mine always says) I’d just build out our apps in electron and be done with it since it would then run chrome under the hood and NO STINK’n IE 
My main concern is that I’m always evangelizing aurelia with other groups within our monolithic company and it does not look good when they fire up a brand new CLI webpack project to only find out it is not ready for IE11 which is still a very widely used browser.
Heh, back in the beginning, the official answer was that non evergreen browsers weren’t and wouldn’t be supported. 
I did not realize that. If that is true that makes aurelia a hard sell for the majority of the business world and specially enterprise since most of them cannot force evergreen due to real reasons. As much as I hate working with IE, our business depends on it for the typical reasons. We also do support chrome so all our development is typically done in chrome and then we test in IE. I don’t know, maybe this issue is just with using webpack, I honestly haven’t tried a CLI typescript or dotnetcore cli template app yet and maybe a non-issue with those backend technologies. I’m happy now though as I have it working well in our apps with webpack 4 (just included babel-polyfill in my webpack.config.js entry > vendor) now and I can continue development.
I had the same problem with esnext and found out it was the babel polyfill being incompatible with the aurelia polyfills (means I have no async await now). I have a huge esnext cli project that works fine on IE11. (edit - I use webpack 3)
(edit again… remove import ‘babel-polyfill’ and disable long stack traces for IE11)
import * as Bluebird from 'bluebird';
/**
* Disable long stack traces for IE11
*/
Bluebird.config(
{
warnings: {
wForgottenReturn: false
},
longStackTraces: false
}
);
IIRC, this was discussed somewhere and the solution is to turn off Aurelia polyfills via aurelia webpack plugin, and provide the plugins yourself. The main conflict happened in Map / set polyfill
new AureliaPlugin({
polyfills: { ... }
})
You can read more at https://github.com/aurelia/webpack-plugin/wiki/Polyfills
1 Like
can you provide a quote on that? It was always IE9+ with polifils
Somewhere in the initial docs under a page named “Browser Support” if I remember correctly. I think it also mentioned that we could add in corejs polyfills and bluebird to support IE if wanted.
What fixed it for me in the end was adding the below to my webpack.config
entry: {
app: ['aurelia-bootstrapper'],
vendor: ['babel-polyfill','bluebird', 'jquery']
}
2 Likes
When I put together my minimal boilerplate, I found the following plugins worked to get IE 11, 10, and 9 all working:
plugins: [
// required polyfills for non-evergreen browsers
new webpack.ProvidePlugin({
Map: 'core-js/es6/map',
WeakMap: 'core-js/es6/weak-map',
Promise: 'core-js/es6/promise',
regeneratorRuntime: 'regenerator-runtime' // to support await/async syntax
})]
and:
import 'mutationobserver-shim/MutationObserver'; // MutationObserver polyfill for IE10
import 'raf/polyfill'; // requestAnimationFrame polyfill for IE9
Hope this helps!
4 Likes
I recently encountered this error. It seems it can be fixed, at least now, by just removing the import '@babel/polyfill' (may vary slightly) from main.js and adding it to the webpack.config.js entry, before aurelia-bootstrapper.
If the fix truly is this simple, I’m not sure why this isn’t done by default? Are there potential side-effects that I’m missing?
1 Like