You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Right now we use eg. string.startsWith in our code. This requires that users include an ES6 polyfill library like es6-shim when running Angular.
We should avoid adding more of these. We can hand-write a typings file describing the APIs we use already, but not type-check against all of es6-shim.d.ts, which gives us too broad a surface to target at runtime.
+1 es6 feature usage should be monitored (as it has implications for ie9 users etc, that we agreed to support) and a custom d.ts would allow us to track those easily.
If the user targets a runtime where more APIs are available, they can bring
typings for those.
But Angular's usage of these APIs forces all users to target such
environments or shim the behavior.
I think Rado knows better why we don't just bundle es6-shim with angular...
On Thu, Nov 12, 2015 at 10:38 PM Evan Winslow [email protected]
wrote:
+1 to vicb comment. If you need the functionality, you might as well
provide the shim yourself?
—
Reply to this email directly or view it on GitHub #5242 (comment).
Just don't use the new APIs. Note that we can use ES6 syntax that
TypeScript de-sugars, just not things that require runtime shims. Evan, is
there a particular API you think we should be using?
On Sun, Nov 15, 2015 at 2:46 PM Evan Winslow [email protected]
wrote:
I guess I'm not clear on the alternative. Provide custom implementations?
Doesn't that bloat the source size just as much as shimming?
—
Reply to this email directly or view it on GitHub #5242 (comment).
Discussed with @IgorMinar this morning. His preference is for Angular to take a dependency on all of ES6, with the observation that users can be responsible for polyfills of anything not in the target browser. But g3 users don't get all those polyfills for free with Closure Compiler, and in fact I believe that Angular 2.0.0 already fails in old browsers because of missing String#startsWith,endsWith etc.
@mhevery has said that we should avoid requiring ES6 shims other than promise and collections. My view is that it makes it harder for them to ship small apps (esp. because the polyfills are probably not tree-shaken by rollup/webpack2? @robwormald can confirm?)
Array.find in es6-subset.d.ts returns a T, while in the TypeScript definition it returns T|undefined.
This definition bled into a Google3 build and led to me puzzling over some code that shouldn't have compiled (it failed to check the return value of find).
So I believe the best fix would be to remove es6-subset.d.ts and use ES5 APIs in angular. Of course this would have to be non-breaking change and should not increase the binary size/performance noticeably.
I'm already doing similar work to remove some facade methods so this is a good time to do it.
Activity
pkozlowski-opensource commentedon Nov 11, 2015
+1
rkirov commentedon Nov 11, 2015
+1 es6 feature usage should be monitored (as it has implications for ie9 users etc, that we agreed to support) and a custom d.ts would allow us to track those easily.
vicb commentedon Nov 13, 2015
On the other hand wouldn't that penalize newer browsers as they would have to include unrequired polyfills/facades ?
ewinslow commentedon Nov 13, 2015
+1 to vicb comment. If you need the functionality, you might as well provide the shim yourself?
alexeagle commentedon Nov 14, 2015
If the user targets a runtime where more APIs are available, they can bring
typings for those.
But Angular's usage of these APIs forces all users to target such
environments or shim the behavior.
I think Rado knows better why we don't just bundle es6-shim with angular...
On Thu, Nov 12, 2015 at 10:38 PM Evan Winslow [email protected]
wrote:
mhevery commentedon Nov 15, 2015
+1 for not using ES6 features in angular. User can always decide, but we should not force.
ewinslow commentedon Nov 15, 2015
I guess I'm not clear on the alternative. Provide custom implementations? Doesn't that bloat the source size just as much as shimming?
alexeagle commentedon Nov 16, 2015
Just don't use the new APIs. Note that we can use ES6 syntax that
TypeScript de-sugars, just not things that require runtime shims. Evan, is
there a particular API you think we should be using?
On Sun, Nov 15, 2015 at 2:46 PM Evan Winslow [email protected]
wrote:
ewinslow commentedon Nov 16, 2015
I'm OK with whatever as long as we don't bloat the source size for folks that don't need the old browser support.
chore(facade): allow es6 methods to be defined in another location.
18 remaining items
evmar commentedon Sep 20, 2016
This bug is closed, but es6-subset.d.ts still exists:
https://github.com/angular/angular/blob/master/modules/es6-subset.d.ts
If this bug is fixed, shouldn't this file go away?
alexeagle commentedon Sep 21, 2016
Discussed with @IgorMinar this morning. His preference is for Angular to take a dependency on all of ES6, with the observation that users can be responsible for polyfills of anything not in the target browser. But g3 users don't get all those polyfills for free with Closure Compiler, and in fact I believe that Angular 2.0.0 already fails in old browsers because of missing String#startsWith,endsWith etc.
@mhevery has said that we should avoid requiring ES6 shims other than promise and collections. My view is that it makes it harder for them to ship small apps (esp. because the polyfills are probably not tree-shaken by rollup/webpack2? @robwormald can confirm?)
evmar commentedon Sep 21, 2016
Array.find in es6-subset.d.ts returns a T, while in the TypeScript definition it returns T|undefined.
This definition bled into a Google3 build and led to me puzzling over some code that shouldn't have compiled (it failed to check the return value of find).
robwormald commentedon Sep 21, 2016
@alexeagle correct, in general tools see polyfill files as one gigantic side-effect
alexeagle commentedon Sep 21, 2016
So I believe the best fix would be to remove
es6-subset.d.tsand use ES5 APIs in angular. Of course this would have to be non-breaking change and should not increase the binary size/performance noticeably.I'm already doing similar work to remove some facade methods so this is a good time to do it.
DzmitryShylovich commentedon Oct 17, 2016
Is this still relevant?
Object.keysis everywhere, for example.According to https://angular.io/docs/ts/latest/guide/browser-support.html es6 polyfills are mandatory.
alexeagle commentedon Oct 19, 2016
Still relevant. The question is, which es6 polyfills are mandatory? Equivalently, which browser/versions are supported without polyfills?
IgorMinar commentedon Feb 8, 2018
this is no longer relevant.
angular-automatic-lock-bot commentedon Sep 13, 2019
This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.
Read more about our automatic conversation locking policy.
This action has been performed automatically by a bot.