Is there a way to silence syntax errors in IE11 in a modern JS code?

Question

We're developing a modern JS library which uses the ES6 syntax heavily and doesn't support IE11.

However we have a small number of users who want to use our library on IE11-compatible sites and we don't want to break their sites on IE11.

Question: is there some way to prevent our library from "exploding" on IE11? (All of the library functions can do nothing and return undefined if IE11 is detected)

For example, we were trying the following approach based on browser detection:

function libFunction() {
  if(isIe11()) {
    return;
  }
  // otherwise do some real stuff with ES6-heavy code
}

However the approach above doesn't work because IE11 throws syntax error even in the code that never gets executed, se we end up with errors like:

SCRIPT1002: Syntax error
File: main.db33ab01aedf59e2f70a.hot-update.js, Line: 47, Column: 1

Other approaches that we consider:

• make our server return a fake implementation of our library if IE11 User-Agent is detected in the request headers. This will partially solve our problems, but won't help the users, who integrate our library into their bundle via NPM/webpack instead of getting it from our servers at runtime.
• transiple our ES6 code to IE11-friendly code and polyfill all the APIs - we don't do that because we don't want the modern browser users to pay the price of the bloated ES5 code and polyfills.
• override global error handler to silence the errors - this won't work, because the errors we get are syntax error, that are not handled by the error handler.

Is there any other possible solution?

Graven

If you rearrange the code so that you first check for IE, and then call a function containing the code to run if it's not IE (lets call it, doSomeWork), then IE won't parse the code inside the "doSomeWork" function. if(notIE) doSomeWork(). (I haven't tested this in IE, so I won't post it as a definitive answer. However it should work in theory) – Election

@Election — I'd exact that to fail with a syntax error when the JS is parsed before it gets to the conditional check. – Micrometeorology

you make an add on package that is filled with the bloated polyfills and those ie11 users download the ie-compat package – Angadresma

IE must die - just tell visitors to use a real browser ;-) – Mesmerism

@Micrometeorology true. You could pull a nasty and put the entire function in an eval. jsfiddle.net/x0osd8h9 – Election

@Angadresma — Polyfills don't patch in syntax features like arrow functions. – Micrometeorology

@Micrometeorology yes... the ie-compat package would be transpiled as well. it's the ie friendly version – Angadresma

The polyfills can be added only for browsers that require them. But yes, if you want it to work in IE 11, you do have to transpile ES6 to ES5. Since you don't seem to care if your app is not going to work anyway in IE11, you could just add a warning to the user that their browser is deprecated. – Miseno

I like Olian's suggestion, instead of a script tag, download the code and run it in an eval wrapped in a try catch – Miseno

@JuanMendes — That was Olian04 – Micrometeorology

Offer the library in both ES6 and ES5 (more bloated). Then let the library users decide which one they pick. If they want to optimize for speed, they could even use both. When a request hits the server, serve the library based on the user agent. – Torey

What I do is, 1. Run a feature detect on the client side, 2. Send the features to the server. 3. Server returns a dedicated transpiled / polyfilled bundle that works with these features. This way modern browsers don't pay the price, and older browsers still work. It means I can even use ES2020 features and not worry about it. – Granivorous

3limin4t0r and Keith some great ideas here! However our library is also distributed via NPM and if we make it dynamically load the proper version of the code based on the detected browser, then 90% of the code will be loaded from the extra request instead of just being a part of the customer's webpack bundle. This means we're losing the main advantage of using the library via NPM :/ . – Graven

smashingmagazine.com/2018/10/… – Twosided

If the library is ES6 and can't be used in IE, what's the meaning to use it in IE? I think it doesn't make sense to only silence the syntax errors. If the users want to use the library in IE 11, they must use an ES5 version. You can provide an ES5 version of the library or let users to use babel or polyfill to transpile the library by themselvs. That's the radical solution to get rid of the syntax error in IE. – Pepi