-
-
Notifications
You must be signed in to change notification settings - Fork 4.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Version 3.10.1 regression: use of const in strict mode, causing critical errors in e.g. Safari 9 #18084
Comments
Hmm, this is indeed surprising. If you add IE11 to the My best guess is that this as to do with #17859, as that is one of the only changes in the build pipeline (specifically WRT selecting legacy or modern builds). |
Yes, the |
One thing I have noticed in the build process is the message:
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. |
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 |
@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. |
I just tried to The issue is that the legacy currently has 15 instances of |
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. |
Is there anything new about this problem? |
one more related issue: #17809 (comment) |
There is nobody to fix this issue ? or revert/update this merged PR #17859 ? |
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. |
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. |
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. |
Sounds good, thank you @samcic. For those interested in getting these fixes back into 3.12.x: #18208 (comment) |
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 |
@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! |
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 |
The underlying issue here is that the "legacy" build is incorrectly using |
In
ember.min.js
version 3.10.1 there are various usages of theconst
keyword inuse 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 ember-cli@3.10.1
ember new test-app
yarn install
(edit
config/targets.js
to includeSafari >= 9
)ember build -prod
(inspect
dist/vendor.js
and see the above-mentionedconst
occurrences)Is this a bug, or am I missing something with respect to the build process?
The text was updated successfully, but these errors were encountered: