Hi guys!
So unfortunately many customers using my app are still on IE9 (you know the drill - big companies not allowing updates and all that). I thought meteor is including the needed polyfills so my app runs properly on IE9 but apparently not - or I am doing something wrong.
One of my packages (Aldeed Simple Schema to be exact) seems to use a const instead of a var in some clientside code - IE9 therefore throws a syntax error because it can’t handle const. Another problem is the “popular” console.log is not defined error. If I have any console.log()s in my code, IE9 behaves very weird until I open the developer tools at least once - then it all works as console.log is defined by then.
About the console.log stuff: I tried npm installing this console-polyfill but I don’t know how to force meteor to load it on the client before any other scripts are loaded?!
EDIT: The problem originates from here. This file is included on the client as well and, as said, usage of const results in a syntax error.
I really need to get this to work. Please help me with this stupid legacy browser! 
thanks in advance,
best P
Do you have the internal es5-shim package added to your app? It’s included by default with new apps, but maybe it’s missing in your app. Check your APP_ROOT/.meteor/packages file to be sure.
this was the debugging tip that lead me right to the problem. Const should never make it to emitted client code, so if that is actually throwing a syntax error, then you are missing the ecmascript package.
You should add ecmascript (I recommend leaving it unpinned rather than providing a strict version) to your api.use directive for both package.onUse and package.onTest.
A little more context about why this is not readily visible at first glance. Often times you’ll get punished for using ES6 without the ecmascript package because uglify doesn’t like much of ES6 syntax (especially hates arrow functions) so when you build (or publish your package) uglify will freak the hell out! However, when the package uses only block scope features of ES6 (const and let) then uglify is fine with that. Also, all modern browsers support it. Not just chrome or just firefox, even IE 11 supports it. Therefore the only time you actually need it for block scoping is on IE<11. Node has supported it forever as well, so if you aren’t using ecmascript and aren’t using any other ES6 features, it’d be hard to get burned. However, IE9 will burn on that.
Yes I do have the es5-shim package and also the ecmascript. You were both on the right track - especially lassombra! Please read my posts here and here.
In short: the ecmascript package is essential any (many?) package authors are missing it. in this case it broke my app. 
It wasn’t until this reply that I realised you weren’t the maintainer of the package. Yes, this is an issue with that package in that it needs to itself include ecmascript. The package author wouldn’t have noticed this error in this case if they didn’t test against IE9/10 they would never have noticed the bug themselves. Any author who uses es6 features needs to include ecmascript in their package use. It doesn’t matter if you have it, as their code wasn’t compiled through babel without that, and it’s too late by the time you include it in your project.
1 Like
Ah I see now I get your point. The ecmascript package has to “present”/included at compilation time of the package using ES6 features. Having it in the meteor core is “too late”.