Skip to content

don't allow arbitrary ES6 APIs usage #5242

Closed

Description

@alexeagle

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.

Activity

  1. self-assigned this
    on Nov 11, 2015
  2. pkozlowski-opensource commented on Nov 11, 2015

    @pkozlowski-opensource
    Member

    +1

  3. rkirov commented on Nov 11, 2015

    @rkirov
    Contributor

    +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.

  4. vicb commented on Nov 13, 2015

    @vicb
    Contributor

    On the other hand wouldn't that penalize newer browsers as they would have to include unrequired polyfills/facades ?

  5. ewinslow commented on Nov 13, 2015

    @ewinslow

    +1 to vicb comment. If you need the functionality, you might as well provide the shim yourself?

  6. alexeagle commented on Nov 14, 2015

    @alexeagle
    ContributorAuthor

    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).

  7. mhevery commented on Nov 15, 2015

    @mhevery
    Contributor

    +1 for not using ES6 features in angular. User can always decide, but we should not force.

  8. ewinslow commented on Nov 15, 2015

    @ewinslow

    I guess I'm not clear on the alternative. Provide custom implementations? Doesn't that bloat the source size just as much as shimming?

  9. alexeagle commented on Nov 16, 2015

    @alexeagle
    ContributorAuthor

    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).

  10. ewinslow commented on Nov 16, 2015

    @ewinslow

    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.

  11. 18 remaining items

  12. evmar commented on Sep 20, 2016

    @evmar
    Contributor

    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?

  13. reopened this on Sep 20, 2016
  14. alexeagle commented on Sep 21, 2016

    @alexeagle
    ContributorAuthor

    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?)

  15. evmar commented on Sep 21, 2016

    @evmar
    Contributor

    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).

  16. robwormald commented on Sep 21, 2016

    @robwormald
    Contributor

    @alexeagle correct, in general tools see polyfill files as one gigantic side-effect

  17. alexeagle commented on Sep 21, 2016

    @alexeagle
    ContributorAuthor

    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.

  18. DzmitryShylovich commented on Oct 17, 2016

    @DzmitryShylovich
    Contributor

    Is this still relevant? Object.keys is everywhere, for example.

    According to https://angular.io/docs/ts/latest/guide/browser-support.html es6 polyfills are mandatory.

  19. alexeagle commented on Oct 19, 2016

    @alexeagle
    ContributorAuthor

    Still relevant. The question is, which es6 polyfills are mandatory? Equivalently, which browser/versions are supported without polyfills?

  20. IgorMinar commented on Feb 8, 2018

    @IgorMinar
    Contributor

    this is no longer relevant.

  21. angular-automatic-lock-bot commented on Sep 13, 2019

    @angular-automatic-lock-bot

    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.

  22. locked and limited conversation to collaborators on Sep 13, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions