You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The published Lambda layer bundles only 10 of the 14 public @aws-lambda-powertools/* utilities. The hardcoded utilities array in layers/src/layer-publisher-stack.ts (lines 107-118) omits four utilities that are published to npm:
validation and kafka predate the last update to the layer list (#4956, which added event-handler); data-masking and signer came afterward. None were ever appended. @aws-lambda-powertools/testing-utils is private: true and is correctly excluded.
Why is this needed?
Customers using the layer cannot import these utilities without installing them separately — the modules are simply absent from /opt/nodejs/node_modules, so a function relying on the layer alone fails at runtime with a module-not-found error. Beyond fixing the four missing packages, the hardcoded list is a recurring drift hazard: it has silently fallen behind the workspace four times already.
Which area does this relate to?
Other (Lambda layer publishing / layers/)
Solution
Rather than adding the four names to the hardcoded list (which will drift again the next time a utility is added), derive the layer contents from the workspace: scan packages/*/package.json and bundle every non-private @aws-lambda-powertools/* package. This bundles the four missing utilities today and any future utility automatically.
Touch points:
layers/src/layer-publisher-stack.ts — replace the hardcoded utilities array with a scan of packages/, filtering private: true. The published-install path (<name>@<version>), the buildFromLocal build/pack path (-w packages/<dir>), and the npm pack tarball naming all need to key off the derived package name/dir rather than an assumed short name.
layers/tests/e2e/layerPublisher.class.test.functionCode.ts (lines 89-99) — the version-parity check has the same hardcoded list (also missing jmespath). Make it iterate the layer's @aws-lambda-powertools/ directory so it verifies whatever actually shipped.
Considerations to review during implementation:
validation pulls in ajv@^8 → increases layer size (jmespath, its other dep, is already bundled).
data-masking declares @aws-crypto/client-node as an optional peer, so it won't be installed by default. Decide whether to ship a crypto backend in the layer or leave it to the customer (consistent with the "we don't ship AWS SDK clients" policy from fix(layers): do not ship AWS SDK clients in the Lambda layer #5512).
kafka optional peers are arktype/valibot/zod; zod is already installed in the layer, the others are optional and not bundled.
signer adds @smithy/* packages (small).
Auto-derivation means any newly-added public package ships in the layer without an explicit opt-in — acceptable given all 14 current public packages are intended to ship, but worth noting.
Summary
The published Lambda layer bundles only 10 of the 14 public
@aws-lambda-powertools/*utilities. The hardcodedutilitiesarray inlayers/src/layer-publisher-stack.ts(lines 107-118) omits four utilities that are published to npm:@aws-lambda-powertools/data-masking(added feat(data-masking): add Data Masking utility #5143)@aws-lambda-powertools/signer(added feat(signer): add SigV4 request signing utility #5344)@aws-lambda-powertools/kafka(added feat(kafka): new kafka utility #4058)@aws-lambda-powertools/validation(added chore(validation): add workspace pkg #3592)validationandkafkapredate the last update to the layer list (#4956, which addedevent-handler);data-maskingandsignercame afterward. None were ever appended.@aws-lambda-powertools/testing-utilsisprivate: trueand is correctly excluded.Why is this needed?
Customers using the layer cannot
importthese utilities without installing them separately — the modules are simply absent from/opt/nodejs/node_modules, so a function relying on the layer alone fails at runtime with a module-not-found error. Beyond fixing the four missing packages, the hardcoded list is a recurring drift hazard: it has silently fallen behind the workspace four times already.Which area does this relate to?
Other (Lambda layer publishing /
layers/)Solution
Rather than adding the four names to the hardcoded list (which will drift again the next time a utility is added), derive the layer contents from the workspace: scan
packages/*/package.jsonand bundle every non-private@aws-lambda-powertools/*package. This bundles the four missing utilities today and any future utility automatically.Touch points:
layers/src/layer-publisher-stack.ts— replace the hardcodedutilitiesarray with a scan ofpackages/, filteringprivate: true. The published-install path (<name>@<version>), thebuildFromLocalbuild/pack path (-w packages/<dir>), and thenpm packtarball naming all need to key off the derived package name/dir rather than an assumed short name.layers/tests/e2e/layerPublisher.class.test.functionCode.ts(lines 89-99) — the version-parity check has the same hardcoded list (also missingjmespath). Make it iterate the layer's@aws-lambda-powertools/directory so it verifies whatever actually shipped.Considerations to review during implementation:
validationpulls inajv@^8→ increases layer size (jmespath, its other dep, is already bundled).data-maskingdeclares@aws-crypto/client-nodeas an optional peer, so it won't be installed by default. Decide whether to ship a crypto backend in the layer or leave it to the customer (consistent with the "we don't ship AWS SDK clients" policy from fix(layers): do not ship AWS SDK clients in the Lambda layer #5512).kafkaoptional peers are arktype/valibot/zod;zodis already installed in the layer, the others are optional and not bundled.signeradds@smithy/*packages (small).