Ember.js: Version 3.10.1 regression: use of const in strict mode, causing critical errors in e.g. Safari 9

[samcic]

In ember.min.js version 3.10.1 there are various usages of the const keyword in use strict mode:

• @ember/-internals/glimmer, example: const e=L(["template-compiler:main"]
• @ember/application/lib/application, example: const e=function(e,t){t...
• @ember/engine/index, example: const e=v(["-bucket-cache:main"])
• @ember/engine/instance, example: const e=u(["template-compiler:main"])

These cause syntax errors in Safari 9 (e.g. on iPhone 6S) and the Ember app fails to start. The error is:

SyntaxError: Use of const in strict mode

Ember 3.9.1 (the previous version) didn't have this problem.

Repro:

npm install -g [email protected]
ember new test-app
yarn install
(edit config/targets.js to include Safari >= 9)
ember build -prod
(inspect dist/vendor.js and see the above-mentioned const occurrences)

Is this a bug, or am I missing something with respect to the build process?

[rwjblue]

Hmm, this is indeed surprising. If you add IE11 to the config/targets.js do you still see the consts? I'm guessing that our detection of whether or not we should use the "legacy" build or not is deciding not to use legacy when it should.

My best _guess_ is that this as to do with https://github.com/emberjs/ember.js/pull/17859, as that is one of the only changes in the build pipeline (specifically WRT selecting legacy or modern builds).

[samcic]

Yes, the consts are still there if IE11 is included in the targets. Is there a way to force the legacy build mode?

[samcic]

One thing I have noticed in the build process is the message:

Browserslist: caniuse-lite is outdated. Please run next command yarn upgrade caniuse-lite browserslist

I'm guessing that this is a dependency of one of the ember-related packages and it's something that we're not responsible for updating ourselves. I wanted to mention it regardless though.

[austinezell]

I am currently experiencing this issue as well. The only additional thing I notice that might be worth pointing out is that the application specific code is still being correctly transpiled to legacy; in the above repro steps, the test-app.js file generated successfully strips out all let/const or other non supported features based on what is in the targets.js. It is only the vendor.js file that appears to fail.

[pzuraq]

@austinezell this is because we actually do not compile any of Ember's code using your targets. At the moment Ember ships with two builds, the legacy build with everything transpiled, and the modern build targeted at the most recent browsers. We use feature detection based on your presets to pick which one to use, but this is the second time that something has broken because of it.

I think at this point we really need to work toward compiling Ember just-in-time using the host application's build targets. It may end up being a bit of a hacky solution, but it'll prevent these kinds of issues from cropping up.

[austinezell]

I just tried to npm link this package and force my app to pull in the "legacy" version of ember. I ended up just verifying that my application is in fact already pulling in the legacy version.

The issue is that the legacy currently has 15 instances of const. Cloning this repo and running npm build then checking the dist/legacy/ folder verifies this. It does seem that @rwjblue's assumption is correct and that this was caused by #17859 . Re-adding the line ['@babel/transform-template-literals', { loose: true }], into the to-es5.js module and re-running npm build successfully removed all instances of const from the legacy build.

[pzuraq]

Ah, interesting, I thought he meant it was the same type of issue, not that exact fix. This complicates things further, because we had to remove that check as it was causing users who _aren't_ supporting legacy browsers to fail. I think we really need to move things to build dynamically, I'll try to get on this soon.

[BnitoBzh]

Is there anything new about this problem?

[lifeart]

one more related issue: https://github.com/emberjs/ember.js/issues/17809#issuecomment-509599388

[BnitoBzh]

There is nobody to fix this issue ? or revert/update this merged PR #17859 ?

[pzuraq]

I’m currently working on the fix for this. It is _not_ easy, it means some pretty major changes to Ember’s build and testing setup, so that it dynamically compiles based on the consuming application’s Babel settings and targets.

[pzuraq]

This will be fixed by #18208, assuming we can get it landed. I'm not sure how possible it'll be to backport, I've labeled it as LTS but I'm very doubtful we'd be able to get it back to v3.4. I think v3.8 would be possible.

[samcic]

Updating to 3.13 fixed this problem so I suggest we close this. The discussions around backporting to earlier versions seems to be a separate topic.

[rwjblue]

Sounds good, thank you @samcic. For those interested in getting these fixes back into 3.12.x: https://github.com/emberjs/ember.js/pull/18208#issuecomment-548786253

[pzuraq]

So, I made https://github.com/pzuraq/ember-class-constructor-fix which _should_ fix most of the general issues in older builds. It's a more general fix too, which means it'll work prior to 3.12 as well.

This bug is pretty strange though, it's not like any of the other issues we've seen. Despite the fact that IE11 is clearly in targets, the legacy build is not being used. This runs counter to the behavior we've seen for all of these versions of Ember. Is it possible to get a reproduction so we can try to figure out what's going on? It's possible something else is messing with targets, or a non-Ember library is not getting transpiled and that's causing the issue.

[samcic]

@pzuraq Not sure if you're waiting for a response from me on this one, but I included the basic repro steps at the start of this issue. It's no longer an issue in 3.13. Let me know if you need any further info from my side on this!

[pzuraq]

Ah, sorry I didn't see that, my bad 😅

So, digging in, it actually looks like the legacy build _was_ being used for these settings and these versions. The issue was that const actually was used in the legacy build, presumably because it is partially supported in IE11 and older versions of Safari. This is definitely unfortunate, but is a result of the fact that we weren't using the real targets here like we are now.

[kanongil]

The underlying issue here is that the "legacy" build is incorrectly using const. See #18575.