Should lib support disposable? Should decorators be merged with esnext.decorators? #54822

Activity

1. Ryan Cavanaugh (RyanCavanaugh)

   added

   Needs InvestigationThis issue needs a team member to investigate its status.This issue needs a team member to investigate its status.

   on Jun 29, 2023
2. Ryan Cavanaugh (RyanCavanaugh)

   assigned

   Ron Buckton (rbuckton)

   on Jun 29, 2023
3. rbuckton commented on Jun 30, 2023

   

   Ron Buckton (rbuckton)

   on Jun 30, 2023

   Last edited by rbuckton

   Contributor

   More actions

   Currently, you can access all the explicit resource management stuff via the following lib option:

       "lib": ["es2022", "esnext.disposable"],

   This is consistent with most other features we provide via lib, especially those that are tied to a specific version of JavaScript because they introduce new runtime values.

   However, the following doesn't work:

       "lib": ["es2022", "disposable"],

   Should it? It is kind of weird that there is no disposable setting whereas you can for decorators.

   When I looked into this, I realized an oddity - that there is both a decorators and esnext.decorators, but that they are not the same thing despite both being part of esnext. The only difference is that esnext.decorators defines Symbol.metadata.

   It should not. lib.esnext.disposable.d.ts introduces runtime values that are required for use that are related to a specific version of JavaScript. The decorator types don't introduce types for new runtime values and thus can be used in every target down to ES5. Only the new Symbol.metadata declaration introduces a new runtime value, and that is provided by lib.esnext.decorators.d.ts, not lib.decorators.d.ts.

   These are both part of esnext, so should they be merged?

   No, doing so would break anyone who is currently writing Stage 3 decorators that does not depend on Symbol.metadata.