FYI @rbuckton

Ideally, we can take this for the 5.2 beta which has a deadline of this Friday. Let me know if you need me to help with any part of this PR to get it in this week.

@rbuckton Thank you so much for taking the time to review this PR 👍🏻. I have added the esnext.decorators library and made changes related to types and factory helpers. I have noticed that the super call is transformed into Reflect.get in classFields. I'm not entirely sure if this is okay, I will check it tomorrow…

Some tests are failing and there are merge conflicts. Can you verify baselines and update with main?

@rbuckton I've merged changes from the main

It looks like one of your evaluation tests is failing.

@typescript-bot pack this

Heya @rbuckton, I've started to run the tarball bundle task on this PR at 3515e58. You can monitor the build here.

It looks like one of your evaluation tests is failing.

Yes. It due to #54657 (comment)

Hey @rbuckton, I've packed this into an installable tgz. You can install it for testing by referencing it in your package.json like so:

{
    "devDependencies": {
        "typescript": "https://typescript.visualstudio.com/cf7ac146-d525-443c-b23c-0d58337efebc/_apis/build/builds/155600/artifacts?artifactName=tgz&fileId=907D5787AC0EB0691771857360E56A79917C1534F3C1E3FF9382E73F0CF73DCE02&fileName=/typescript-5.2.0-insiders.20230622.tgz"
    }
}

and then running npm install.

There is also a playground for this build and an npm module you can use via "typescript": "npm:@typescript-deploys/[email protected]".;

We should also add this to esnext.decorators.d.ts:

interface Function {
  [Symbol.metadata]?: object | null;
}

Sorry, we should add it to src/lib/decorators.d.ts instead, per my other suggestion.

This is looking fairly close to ready, once the baselines are reviewed and accepted I'll hopefully be able to take a final pass and approve.

@rbuckton What are your thoughts on moving the following types from decorators.d to esnext.decorators.d?

interface Function {
    [Symbol.metadata]: DecoratorMetadata | null;
}

It shouldn't be optional since it will already get the | undefined from the DecoratorMetadata type with the definition I suggested. Placing it in esnext.decorators makes sense given the dependence on Symbol.

oke, I've moved it to esnext.decorators.d.

It shouldn't be optional since it will already get the | undefined from the DecoratorMetadata type with the definition I suggested. Placing it in esnext.decorators makes sense given the dependence on Symbol.

I should have added more detail to this, but it was late. The main reason to not make it an optional property of Function is that we wouldn't be able to make it not optional in esnext (or es2024, etc.). There is a way to do that, but it would have been more complex and employ the same mechanism as DecoratorMetadata already does, i.e.:

type FunctionMetadata =
    typeof globalThis extends { Symbol: { readonly metadata: symbol } } ? {
        [Symbol.metadata]: DecoratorMetadataObject | null;
    } : {
        [Symbol.metadata]?: DecoratorMetadataObject | null;
    };

interface Function extends FunctionMetadata {
}

But I think the approach of just using DecoratorMetadata—which already includes this conditional—and leaving the property as non-optional is fine.