Summary
A few of our private workspaces list build/test tools (esbuild, typescript, @types/*) under dependencies instead of devDependencies. Because Dependabot decides whether an update is a "development" or "production" dependency by looking at where the package is declared across the repo, these misplacements cause Dependabot to label the updates as production. That in turn excludes them from the new dev-dependency auto-merge workflow, so a maintainer has to review and merge them by hand even though they're routine tooling bumps.
We found this while checking why a couple of Dependabot PRs weren't auto-merging (#5591 for @types/node, and the esbuild/tooling group). The auto-merge workflow was working correctly — the dependency declarations were the problem.
Why is this needed?
The whole point of the auto-merge workflow is to stop maintainers from hand-merging routine dev-dependency bumps. Every tool stuck in the wrong section quietly defeats that for its updates. Fixing the declarations lets these bumps flow through auto-merge like the rest.
All three affected workspaces are private and never published to npm, so moving these packages to devDependencies has no effect on anything we ship — there's no risk here, just cleanup.
Which area does this relate to?
Automation, Governance
Solution
Correct the dependency declarations, using the root package-lock.json as the source of truth for what's declared where:
examples/app
@types/node — listed in both dependencies and devDependencies; remove from dependencies.@types/aws-lambda — same, listed in both; remove from dependencies.typescript — same, listed in both; remove from dependencies.esbuild — only in dependencies; move to devDependencies.
layers
esbuild — only in dependencies; move to devDependencies.
packages/testing (@aws-lambda-powertools/testing-utils, private)
esbuild — only in dependencies; move to devDependencies.
After the change, run npm install so package-lock.json is regenerated, and confirm the build/test still pass for these workspaces.
Note: the audit only turned up dev tooling in private workspaces. No published package (packages/*) declares a dev tool as a production dependency, so there's nothing to fix on the shipping side.
Acknowledgment
Future readers
Please react with 👍 and your use case to help us understand customer demand.
Summary
A few of our private workspaces list build/test tools (
esbuild,typescript,@types/*) underdependenciesinstead ofdevDependencies. Because Dependabot decides whether an update is a "development" or "production" dependency by looking at where the package is declared across the repo, these misplacements cause Dependabot to label the updates as production. That in turn excludes them from the new dev-dependency auto-merge workflow, so a maintainer has to review and merge them by hand even though they're routine tooling bumps.We found this while checking why a couple of Dependabot PRs weren't auto-merging (#5591 for
@types/node, and theesbuild/tooling group). The auto-merge workflow was working correctly — the dependency declarations were the problem.Why is this needed?
The whole point of the auto-merge workflow is to stop maintainers from hand-merging routine dev-dependency bumps. Every tool stuck in the wrong section quietly defeats that for its updates. Fixing the declarations lets these bumps flow through auto-merge like the rest.
All three affected workspaces are private and never published to npm, so moving these packages to
devDependencieshas no effect on anything we ship — there's no risk here, just cleanup.Which area does this relate to?
Automation, Governance
Solution
Correct the dependency declarations, using the root
package-lock.jsonas the source of truth for what's declared where:examples/app@types/node— listed in bothdependenciesanddevDependencies; remove fromdependencies.@types/aws-lambda— same, listed in both; remove fromdependencies.typescript— same, listed in both; remove fromdependencies.esbuild— only independencies; move todevDependencies.layersesbuild— only independencies; move todevDependencies.packages/testing(@aws-lambda-powertools/testing-utils, private)esbuild— only independencies; move todevDependencies.After the change, run
npm installsopackage-lock.jsonis regenerated, and confirm the build/test still pass for these workspaces.Note: the audit only turned up dev tooling in private workspaces. No published package (
packages/*) declares a dev tool as a production dependency, so there's nothing to fix on the shipping side.Acknowledgment
Future readers
Please react with 👍 and your use case to help us understand customer demand.