-
Notifications
You must be signed in to change notification settings - Fork 12k
Suggestion: consistent config or use browserslist for build config #10337
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
Comments
I don't quite follow the logic that
So it isn't really a matter of using es5 for IE, nor of being inconsistent. The suggestion of using browserlist to determine polyfills is already put forward in #6577 though. It's a cool idea to use it to choose a es2016 target as well. I'll mark this one as a duplicate and add that suggestion there. |
The only thing missing in ES2015 support in modern browsers is proper tail calls, and as far as I know, it doesn't prevent from serving Still, the 2 other aspects (polyfills and auto-prefixer) are inconsistent: first is configured for evergreen by default and requires action for IE support, second is configured for IE by default. |
For
|
I think you're right, regardless of the ES2015 question, the polyfills-browserlist question is still valid on its own. APF recommends that ES2015 code is distributed, but that's a library packaging concern. I'm not sure it's applicable for apps. Just because evergreen browsers support ES2015 doesn't mean you want your app to be bundled to ES2015, or that you only want to support evergreen browsers. The APF recommendation just says that libraries should have that option. |
Thanks for reopening the issue. About ES2015, if it's recommended to distribute librairies in ES2015, it's a fortiori recommended for apps too. Otherwise, if all apps always retarget to ES5, then having the library distributed in ES2015 was not necessary in the first place. Of course, which configuration should be enabled by default (evergreen or old browsers) would be a huge debate, with a lot of pros and cons on each side. But a major point is: I think there is an important and good reason polyfills are configured for evergreen only by default: it's because activating all the polyfills has a huge size/performance impact. It is certainly why that choice was done in the first place. And, correct me if I'm wrong, but I don't think you'll change your mind about this (and it's good for me). Then, as users who wants IE support have to take action for polyfills, it would be better if the other aspects (ES target and auto-prefixer) were consistent and configured for evergreen by default too. That way, only people needing IE support would have to take action, instead of currently everyone has to take action to match their needs (of course, you can build for evergreen without taking action with the current options, but then you're not in an optimized configuration, which is one of the main goals of the CLI). |
At this point in the release cycle, defaulting to ES2015 would need to be a change that could be considered for 7.0. And there are definite merits to making that change. As to the polyfills/browserslist sync, there is now a PR for this: angular/devkit#774 |
This issue has been automatically locked due to inactivity. Read more about our automatic conversation locking policy. This action has been performed automatically by a bot. |
Currently the default build config is inconsistent:
es5
(so for IE),browserslist
file in v6.The default configuration should at least be consistent for those 3 aspects of compatibility.
I know that the TS target was stuck on
es5
because of one special case (about tests I guess), I don't know if it's still a problem (@filipesilva ?).But the CLI could do even better: now that there is an explicit default
browserslist
file, maybe it could use it to adapt the configuration of TS and polyfills automatically.The text was updated successfully, but these errors were encountered: