Description
Summary
After we launched v2 with ESM support, customers found some friction (#2523, #2290, #2464) when migrating due to X-Ray SDK for Node.js being built for CJS only and Tracer using the require
keyword to monkey patch the imports for the http
and https
modules.
Due to the Tracer's usage of the keyword, customers that forget to add the banner see Powertools for AWS mentioned in the stack trace and think that there is a bug on our side. To mitigate this, as well as remove an unnecessary usage of the require
keyword we should investigate if it's possible to avoid using it.
Why is this needed?
So that it's clearer where the issue resides and
Note that this won't remove the need for the banner, since the SDK will still only support CSJ, however the error and stack trace will change from something like this:
{
"errorType": "ReferenceError",
"errorMessage": "require is not defined in ES module scope, you can use import instead",
"stack": [
"ReferenceError: require is not defined in ES module scope, you can use import instead",
" at ProviderService.captureHTTPsGlobal (file:///opt/nodejs/node_modules/@aws-lambda-powertools/tracer/lib/esm/provider/ProviderService.js:25:9)",
" at new Tracer (file:///opt/nodejs/node_modules/@aws-lambda-powertools/tracer/lib/esm/Tracer.js:122:27)",
" at (/infra/src/pipeline/config/lambda-fns/common/powertools.ts:24:16)",
" at ModuleJob.run (node:internal/modules/esm/module_job:222:25)",
" at async ModuleLoader.import (node:internal/modules/esm/loader:323:24)",
" at async _tryAwaitImport (file:///var/runtime/index.mjs:1008:16)",
" at async _tryRequire (file:///var/runtime/index.mjs:1057:86)",
" at async _loadUserApp (file:///var/runtime/index.mjs:1081:16)",
" at async UserFunction.js.module.exports.load (file:///var/runtime/index.mjs:1119:21)",
" at async start (file:///var/runtime/index.mjs:1282:23)"
]
}
to this:
{"errorType":"Error","errorMessage":"Dynamic require of \"util\" is not supported","stack":["Error: Dynamic require of \"util\" is not supported"," at file:///var/task/index.mjs:11:9"," at node_modules/cls-hooked/context.js (file:///var/task/index.mjs:270:16)"," at __require2 (file:///var/task/index.mjs:14:50)"," at node_modules/aws-xray-sdk-core/dist/lib/context_utils.js (file:///var/task/index.mjs:1862:15)"," at __require2 (file:///var/task/index.mjs:14:50)"," at node_modules/aws-xray-sdk-core/dist/lib/aws-xray.js (file:///var/task/index.mjs:7641:24)"," at __require2 (file:///var/task/index.mjs:14:50)"," at node_modules/aws-xray-sdk-core/dist/lib/index.js (file:///var/task/index.mjs:7947:22)"," at __require2 (file:///var/task/index.mjs:14:50)"," at file:///var/task/index.mjs:8924:40"]}
Which will help customers better pinpoint the issue.
Which area does this relate to?
Tracer
Solution
Test if it's possible to remove the hardcoded require
in the packages/tracer/src/ProviderService.tsfile and let
tsc` convert it based on the build mode. Then, if this is successful, test that the X-Ray SDK for Node.js can still monkey patch the import even when using ESM.
Acknowledgment
- This request meets Powertools for AWS Lambda (TypeScript) Tenets
- Should this be considered in other Powertools for AWS Lambda languages? i.e. Python, Java, and .NET
Future readers
Please react with 👍 and your use case to help us understand customer demand.
Metadata
Metadata
Assignees
Labels
Type
Projects
Status