[IDEA] Check browser-legacy bundle for not supported code/syntax

[klabauter]

Hi guys,

So I just had the following problem, which completely killed my app for IE11:

I have a Meteor-Files Collection defined in a file, which is imported on both client and server.
Inside a if(Meteor.isServer) { } I had a require() for a server-side package: detect-character-encoding

Problem was, that I did not know, that although the require() as inside the if, the package was still also packaged on the client, because the whole file was imported on the client as I already said.

This package is using an arrow function in its main file: https://github.com/sonicdoe/detect-character-encoding/blob/master/index.js

–> IE11 was broken, because this arrow function was not transpiled at all!

–> I suggest the following:
Implement some check for the browser-legacy-bundle.js file for not supported syntax like arrow functions, spread operators and all that. If for some reason syntax/code like that is found, I would like a ERROR message during meteor build!

Is this possible? This was a huge problem, because I thought I did everything right, just did some updates on my server side code, published my new update without testing on IE11 and 24hrs later I find out because of a user complaint, that since this update IE11 was completely dead. This is obviously a huge issue!!

Thanks guys, cheers
Patrick

[alawi]

Here is my personal take on this, and I struggled with those kind of defects myself.

I think there is no easy fix for this. Any extra checks will be a tradeoff with the build time, scanning all the files and running checks will slow down the build time which is also important.

The fact that the JS ecosystem is transitioning between two syntax and IE11 is really an outdated browser that even MS is encouraging folks to stop using it. I don’t think frameworks should keep catering for that browser, instead clients need to be pushed to update. If that is not possible, then I think developers should have test cases for E11 if they have client using it. But I really don’t think Meteor should keep adding custom logic to cater for special cases like this on the expense of more complexity and slower build time.

Also I recommend this blog post about IE11, hopefully less and less people with use IE11 going forward.

[klabauter]

I agree like 90% but not 100%.

The reality is, that in a corporate/B2B environment like my app, IE11 is unfortunately a very common sight.
Big corporates just update their IT very infrequently.

Idea was to only do these checks at meteor build … it would be just fine to maybe just run these checks if a certain flag is set.
Can anyone suggest a nice test for IE to make sure that all the client code can work properly?

[alawi]

I understand and I’m on the same boat and yeah unfortunately those large IT companies are probably the reason for the 7% global usage of IE. The issue with them is that they’ve some legacy apps that only work on < IE11 or they just have lazy IT department frankly, I worked as it officer in large companies and I understand the resistance from their end.

But Meteor (and other frameworks) are caught in the middle, and Meteor already went further by building two builds and also allow using Meteor to compile modern packages to work on legacy which I think is good enough. The rest should be on the dev side unfortunately including automating IE testing.

My point is this, Meteor should not cater for IE and focus energy on more forward looking issues. And frankly it’s good to have some dev pain while supporting IE, so they push clients to move forward as well.

[alawi]

I’m actually not sure if there is away to automate IE testing, does Selenium work with IE?

[captainn]

I believe 1.8.2 (currently at beta.16) will transpile npm packages now. Have you tried that yet?

[alawi]

The automatic transpilation was reverted because it slowed down the built and startup time significantly. However, starting from Meteor 1.7 it was possible to transpile modern packages to legacy using symbolic links and in 1.8.2 this has been made more explicit using the nodeModules key in the package.json, see this PR.

[captainn]

That’s pretty cool - do you know if that PR will use the module field in the package.json, or is it only recompiling the “main” entry? Update: It looks like it uses the module field. I can get it to use the “somewhat modern” @material-ui/core files by renaming the es folder to esm which is what the package.json references. Then I set up the compiler to only compile for “legacy” builds, and I get some modern bundle advantages! Pretty spiffy! Now I just need a way to do that without having to rename directories in the node_modules hierarchy…