Feature/support nodejs18 esmodule #535
Conversation
…s' into feature/vscode-debugger-support
…vscode-debugger-support
…vscode-debugger-support
kai-nguyen-aligent
requested review from
AdamJHall,
TheOrangePuff,
tvhees and
SamMenzel
and removed request for
AdamJHall
| @@ -1,3 +1,21 @@ | |||
| #!/bin/sh | |||
|
|
|||
There was a problem hiding this comment.
@TheOrangePuff could you review this section?
| @@ -0,0 +1,46 @@ | |||
| """ | |||
There was a problem hiding this comment.
@kai-nguyen-aligent there's a fair bit in this PR that doesn't seem related to the PR topic/description.
There was a problem hiding this comment.
@tvhees So sorry. I think it's my bad when I create this branch. Look like it include the changes from the other PR. Let me create another one with only the changes for node18 & esm
| @@ -1,15 +1,30 @@ | |||
| import 'source-map-support/register'; | |||
| import axios from 'axios'; | |||
| import { getConfigurations } from './lib/collect-ssm-params'; | |||
|
|
|||
| // AWSLambda.Handler is provides very generic typing | |||
| // for handler functions. Specific argument and output | |||
| // types can be supplied using generic arguments | |||
| // e.g. AWSLambda.Handler<string, object>, and/or using | |||
| // event-specific handler types e.g. AWSLambda.S3Handler | |||
| export const handler: AWSLambda.Handler = async (event, context) => { | |||
There was a problem hiding this comment.
Interesting that GitHub is throwing errors for this - that's typescript complaining I assume? We should probably check that in the main template.
There was a problem hiding this comment.
I got this complaining by both typescript & eslint.
'context' is defined but never used.eslint[@typescript-eslint/no-unused-vars](https://typescript-eslint.io/rules/no-unused-vars) 'context' is declared but its value is never read.ts(6133)
|
My bad while creating this branch. It included some of my local modification & seem to be branch off the |
This PR support the following things:
--enable-source-mapsnode runtime option.axios,aws-sdk v3,jest,ts-jest, etc…While working on this, there are few caveats that worth to mentioned:
While ES module format enable top-level await and significantly reduce the init billing duration, we have to use a hack to make it works otherwise we will not be able to use any native runtime library. This is an issue of esbuild as mention in this PR: Rewrite
require()calls of Node built-ins to import statements when emitting ESM for Node by eduardoboucas · Pull Request #2067 · evanw/esbuild. For the time being, we need to tell esbuild to inject a banner like so to the output:import { createRequire } from 'module'; const require = createRequire(import.meta.url);If we have top-level await in our code, Jest mock will not work normally unless we do the following things:
a. Tell node to run jest in
--experimental-vm-modulesmode.b. We have to use
unstable_mockModulefunction to mock and then dynamically import our test modules as demonstrated incollect-ssm-params-tests.test.tsexample.If we do not want to take advantage of top-level await (requires ES module format) or leverage the native
aws-sdk v3in AWS Lambda NodeJS18 runtime (reduce package size) then there is no significant reason to upgrade at the moment.