Bug: `InferOutput` not exported from public types entry point, causing TS2883 with TypeScript 6

[yashar-new10]

Expected Behavior

Code using the parser middleware with safeParse: true should compile cleanly under TypeScript 6. All types that appear in the inferred return type of a consumer function must be reachable via a public package export so TypeScript can generate valid .d.ts declaration files.

Current Behavior

Compiling with TypeScript 6 raises:

error TS2883: The inferred type of 'myHandler' cannot be named without a reference to
'InferOutput' from '.../node_modules/@aws-lambda-powertools/parser/lib/esm/types/parser.js'.
This is likely not portable. A type annotation is necessary.

InferOutput is used in the parser() middleware's type signature but is only reachable at the internal path lib/esm/types/parser.js. It is not re-exported from @aws-lambda-powertools/parser/types or any other public entry point, so TypeScript cannot include a portable reference to it in generated declaration files.

Code snippet

import middy from '@middy/core';
import { parser } from '@aws-lambda-powertools/parser/middleware';
import { APIGatewayProxyEventV2Schema } from '@aws-lambda-powertools/parser/schemas';

// TS2883 is raised on this exported symbol
export const myHandler = middy()
  .use(parser({ schema: APIGatewayProxyEventV2Schema, safeParse: true }))
  .handler(async (event) => {
    return { statusCode: 200 };
  });

Steps to Reproduce

1. Create a TypeScript project with typescript@^6.0.0
2. Install @aws-lambda-powertools/parser, @middy/core, and zod
3. Add the code snippet above to an exported file (declaration emit must be on, or use tsc --noEmit)
4. Run tsc
5. Observe TS2883

Possible Solution

Export InferOutput from packages/parser/src/types/index.ts so it is available at the public @aws-lambda-powertools/parser/types entry point. This is a one-line, type-only change with no runtime impact — TypeScript will then automatically use the public path in generated .d.ts files and the error resolves without any changes required on the consumer side.

I am opening a PR with this fix alongside this issue.

Powertools for AWS Lambda (TypeScript) version

latest

AWS Lambda function runtime

24.x

Packaging format used

npm

Execution logs

[boring-cyborg]

Thanks for opening your first issue here! We'll come back to you as soon as we can.
In the meantime, check out the #typescript channel on our Powertools for AWS Lambda Discord: Invite link

[svozza]

Hi there, thank you for the detailed issue. Just out of curiosity, what change in TypeScript 6.0 caused this breakage? I'm wondering if there are others we may have missed so would like to know the root cause so I can investigate the other utilities.

[yashar-new10]

@svozza I believe TS2883 is introduced in PR #63200.

The existing reportLikelyUnsafeImportRequiredError check in the declaration emit pipeline (which already powered TS2742) was updated to pass the specific symbol name when one can be resolved. The new error code TS2883 fires when a symbol name is available; TS2742 is the fallback when it isn't:

// Before (TS2742 always):
reportLikelyUnsafeImportRequiredError(specifier: string)

// After (TS2883 when symbolName is known, TS2742 otherwise):
reportLikelyUnsafeImportRequiredError(specifier: string, symbolName: string | undefined)

• TS2742: "…cannot be named without a reference to '{internal/path}'"
• TS2883: "…cannot be named without a reference to 'InferOutput' from '{internal/path}'" ← new, symbol-named variant

However the actual root cause is: PR #62243 — "thisless functions not context-sensitive"

This PR (merged Dec 2025, shipped in TS6.0-beta) changed how TypeScript handles type inference for methods that don't use this.

What changed in the type checker

// binder.ts — TS now tracks whether a function body actually uses `this`:
node.flags = seenThisKeyword
  ? node.flags | NodeFlags.ContainsThis
 : node.flags & ~NodeFlags.ContainsThis;

Previously, any method (using method syntax) was considered "context-sensitive", which caused TypeScript to skip it during type argument inference and fall back to a less-specific type. In TS5.9, middy's .use() / .handler() generic method types were skipped this way, the inferred type of myHandler never fully resolved InferOutput, so the declaration emit portability check never triggered.

In TS6, methods that don't reference this are no longer context-sensitive. TypeScript now infers through the full middy chain correctly, and InferOutput surfaces in the inferred type of myHandler. Once it appears, the pre-existing declaration emit check (which has always existed, it just never got a chance to fire before) sees that InferOutput is only reachable at an internal path and raises the error.

TS2742 existed in TS5.9 but never fired because the type was never fully resolved to begin with. TS6's better inference is what exposed the missing export. And because of #63200 improvements now when symbolName is known we get TS2883 instead of the generic TS2742 type error.

[svozza]

Thank you for the detailed explanation. I also did some investigation on my own to figure out why we don't see this type error when we run tsc in our CI or even local dev environment. It looks like TS2883 in this case only fires when consuming the package as an external dependency through node_modules, where the only paths available are the public entry points declared in package.json exports. I need to think about how we can do some tests in this scenario but I don't want to hijack this issue and block your PR so I'm happy to proceed with your fix for now.

[powertools-for-aws-oss-automation]

Warning

This issue is now closed. Please be mindful that future comments are hard for our team to see.
If you need more assistance, please either reopen the issue, or open a new issue referencing this one.
If you wish to keep having a conversation with other community members under this issue feel free to do so.