Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Maintenance: drop support for Node.js 16 #2223

Open
1 of 2 tasks
dreamorosi opened this issue Mar 13, 2024 · 5 comments
Open
1 of 2 tasks

Maintenance: drop support for Node.js 16 #2223

dreamorosi opened this issue Mar 13, 2024 · 5 comments
Labels
confirmed The scope is clear, ready for implementation internal PRs that introduce changes in governance, tech debt and chores (linting setup, baseline, etc.)

Comments

@dreamorosi
Copy link
Contributor

Summary

Important

Starting from July 1, 2024 Powertools for AWS Lambda (TypeScript) will end support for Node.js 16.

This action follows the date when AWS Lambda will mark the nodejs16.x as deprecated and precedes the date after which you will no longer be able to create new functions using the runtime.

We recommend that you upgrade your existing Node.js 16 functions to Node.js 20 before July 1st, 2024.

End of support does not impact existing functions and functions using versions of Powertools for AWS Lambda (TypeScript) released before the date, however starting from this date we will not guarantee compatibility with Node.js 16.

You can use the following AWS CLI command to list all functions in a specific region using Node.js 16, including published function versions:

Note

Make sure to replace the value of the --region flag and run this command in each region you have Lambda functions workloads

aws lambda list-functions --function-version ALL --region <Region> --output text --query "Functions[?Runtime=='nodejs16.x'].FunctionArn"

Why is this needed?

Starting from July 15, 2024 we will no longer be able to deploy new Lambda functions using the nodejs16.x runtime, this means we will no longer be able to run integration tests for new code changes.

With this in mind, and considering our iteration cycles last two weeks, we plan on dropping support for the runtime just two weeks before the date.

Which area does this relate to?

Governance

Solution

No response

Acknowledgment

Future readers

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

@dreamorosi dreamorosi added internal PRs that introduce changes in governance, tech debt and chores (linting setup, baseline, etc.) confirmed The scope is clear, ready for implementation labels Mar 13, 2024
@dreamorosi dreamorosi pinned this issue Mar 13, 2024
@dreamorosi
Copy link
Contributor Author

Check the useDefineForClassFields value in tsconfig.json which will flip to true once we target ES2022 (docs).

@dreamorosi
Copy link
Contributor Author

Consider removing errorWithCause type guard since starting from ES2022 all errors have a cause property.

@dreamorosi
Copy link
Contributor Author

Check if noEmitHelpers can be enabled again for ESM build when target is ES2022 (ref #2230).

@dreamorosi
Copy link
Contributor Author

Consider replacing occurrences of object.hasOwnProperty('foo') (example) with more modern alternative Object.hasOwn(object, 'foo') (docs) since it's supported in ES2022.

@dreamorosi
Copy link
Contributor Author

Consider replacing usage of Array.prototype.indexOf() with Array.prototype.at() where it makes sense, since it's supported in ES2022 and also works in reverse order (i.e. array.at(-1) gets you the last item) - docs.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
confirmed The scope is clear, ready for implementation internal PRs that introduce changes in governance, tech debt and chores (linting setup, baseline, etc.)
Projects
Development

No branches or pull requests

1 participant