Ember app suddenly no longer working in IE 11

Questions
1

Posting this here in the hopes that someone else has recently encountered this same issue. At some point since 5/4/2021, our builds have stopped working in IE 11.

Specifically, we are seeing errors related to the define method (define is not defined) and arrow functions (syntax error). Since I see the define method in compiled versions of previous builds that do work in IE 11, I am assuming that the babel-polyfill is supporting not only that but arrow functions (and who knows what else).

Even if I am to go back and build the same code base from 5/4/2021, it will no longer work in IE 11, so my belief is that this is a dependency issue (and not one related to changes in the codebase).

I am looking at package-lock files from working vs. not-working builds and the babel versions all seem to be the same.

Has anyone else encountered this issue, or does anyone have any suggestions for debugging the root cause?

Ember 3.1.4

ember-cli-build.js

    'ember-cli-babel': {
        includePolyfill: true,
    },
2

As a first check, what does your config/targets.js look like?

3

Old school:

'use strict';

const browsers = [
    'ie 11',
    'last 1 Chrome versions',
    'last 1 Firefox versions',
    'last 1 Safari versions',
];

module.exports = {
    browsers,
};
4

Hmmm it’s odd that you can’t build a working version even with a lock file. That’s one of the big benefits of lockfiles is that you don’t have dependency shift. So you can’t build a version that works in IE even if you go back farther than 5/4/21? If you knew that you have the last version that builds fine for IE11 I’d usually start by looking at any package changes that were made after that commit.

Can you reproduce building on other machines? And testing on other machines? The inputs here are…(?):

  • app source code
  • dependencies consumed in the build (should be locked in lockfile)
  • dependences to run the build (should be locked in lockfile)
  • the machine you are building on and the node environment it is running in
  • the machine/browser running the code

So in theory one of those things changed. Ruling out changes to the lockfile seems like the logical first step, and possibly the easiest, though building on a different machine/node version may be a good step too.

5

Sadly no. Even if I rebuild the 5/4 version now, it no longer works in IE 11 (though the 5/4 version that is currently deployed to production works fine).

The issue was original discovered in a version that was built in Gitlab and I am testing this in my own development environment; so it is reproducible in at least two build and two test environments. (Both also running different versions of node/npm.)

6

Okay, I’ve made an interesting discovery this morning. Specifically, that my app is now consuming Bootstrap 5, which ends up compiled into vendor.js with a whole lot of arrow functions, which is what’s causing the Syntax Error in vendor.js. (I believe the subsequent define is undefined error is a bit of a red herring caused by the preceding syntax error.)

As it turns out Bootstrap 5 is being pulled in by summernote that is referenced in bower.json and therefore not subject to being locked down by the package-lock.json file.

I still don’t quite understand why the Bootstrap JS isn’t being transpiled for IE, but my understanding is that Bootstrap 5 does not support IE 11 anyway.

7

Ah wow I hadn’t even thought of a bower file, that would do it. Would definitely recommend migrating your bower dependencies over to npm if you have the bandwidth. Took a solid amount of work for us but it was well worth it for a number of reasons.

1 Like
8

For anyone who ends up here, we ended up migrating summernote from Bower to NPM (and upgrading in the process). Additionally, we upgraded ember-cli-summernote (caveat: we overrode the template to ensure the summernote HTML class would be rendered (as the addon did not work after the upgrade).

By doing this we prevented Bootstrap 5 JS from being compiled into the vendor.js file (and thus breaking IE 11).

Thanks to @dknutsen for chiming in on this. :raised_hands:

1 Like