Maintenance: test repo & packages with TypeScript 5.x

[dreamorosi]

Summary

On March 16th TypeScript 5.0 was released. Among other things, the release has some changes related to decorators support.

We should invest some time to test the project with the new version, understand if there's any implication, and if any change is required.

Why is this needed?

We can expect customers will want to start using the new TS version and so we need to test compatibility.

Which area does this relate to?

Other

Solution

No response

Acknowledgment

• This request meets Lambda Powertools Tenets
• Should this be considered in other Lambda Powertools languages? i.e. Python, Java, and .NET

Future readers

Please react with 👍 and your use case to help us understand customer demand.

[dreamorosi]

After some initial research, it appears that the signature/type of how decorators are defined in TS has changed with the new version. This is unfortunate but also not surprising since decorators as a feature in TypeScript/JavaScript are still experimental.

Prior to TS5.0, the signature was this:

type MethodDecorator = <T>(
  target: Object,
  propertyKey: string | symbol,
  descriptor: TypedPropertyDescriptor<T>
) => TypedPropertyDescriptor<T> | void;

Now, with TS5.0, the signature looks like this:

type ClassMethodDecorator = (
  value: Function,
  context: {
    kind: "method";
    name: string | symbol;
    access: { get(): unknown };
    static: boolean;
    private: boolean;
    addInitializer(initializer: () => void): void;
  }
) => Function | void;

Source

The main differences that I can see will affect us are:

• The decorated method is now value (first argument) instead of descriptor.value (3rd argument, which we use now)
• Number of arguments goes from 3 to 2
• The name of the decorated method/function is now context.name and not propertyKey (which has now been removed)

The next step should be to create a small PoC to validate the findings above.

[dreamorosi]

In #1667 we have revisited and simplified the tsconfig.json files in order to have a main one in the root of the project and then have each package in the workspace extend that one and apply their own specific configuration.

In order to avoid breaking changes there are two areas that we have purposefully left out:

• importHelpers, noEmitHelpers, and downlevelIteration
• isolatedModules

As part of this issue, which is in the v2 planning, we should also consider enabling these settings.

[github-actions]

⚠️ COMMENT VISIBILITY WARNING ⚠️

Comments on closed issues are hard for our team to see.
If you need more assistance, please either tag a team member or open a new issue that references this one.
If you wish to keep having a conversation with other community members under this issue feel free to do so.

[github-actions]

This is now released under v1.13.0 version!