TypeScript unable to infer types

[canassa]

Describe the bug

I’m trying to implement this example from the Middy documentation. I copied it exactly into my project, but when I run it, TypeScript is unable to determine the types of event and context. I believe this example originated from a comment by @bilalq, maybe he knows how to get this to work?

src/functions/health/get.ts:32:21 - error TS7006: Parameter 'event' implicitly has an 'any' type.

32     .handler(async (event, context) => {
                       ~~~~~

src/functions/health/get.ts:32:28 - error TS7006: Parameter 'context' implicitly has an 'any' type.

32     .handler(async (event, context) => {
                              ~~~~~~~

My TS config:

{
  "include": ["src/**/*.ts", "*.ts"],
  "compilerOptions": {
    "allowJs": true,
    "checkJs": true,
    "declaration": false,
    "emitDecoratorMetadata": true,
    "esModuleInterop": true,
    "experimentalDecorators": true,
    "forceConsistentCasingInFileNames": true,
    "importHelpers": true,
    "module": "node16",
    "moduleResolution": "node16",
    "noEmit": true,
    "resolveJsonModule": true,
    "skipLibCheck": true,
    "sourceMap": true,
    "strict": true,
    "target": "es2022",
    "verbatimModuleSyntax": true
  }
}

Environment:

• Node.js: 20
• Middy: 5.4.3
• TypeScript: 5.5.3

[bilalq]

Summary

It looks like this is a regression in Middy 5, maybe. I still use Middy 4 due to that being the latest version supported by AWS Powertools, so I never noticed this problem. Also, the example in the docs has a minor bug where it references event.path instead of req.path.

Reproduction Steps

This differs a bit from the example shared in the issue description because the tsconfig there gave me ESM problems that weren't really related to the problem at hand. Maybe I needed to set module: true in package.json or something, but I just can't be bothered to deal with any more ESM related problems in my life, so here's a simplified reproduction that sidesteps that:

Create files

package.json:

{
  "name": "middy-example",
  "version": "1.0.0",
  "dependencies": {
    "@middy/core": "^5.4.3",
    "@middy/secrets-manager": "^5.4.3",
    "@types/aws-lambda": "^8.10.141",
    "@types/node": "^20.14.10",
    "typescript": "^5.5.3"
  }
}

tsconfig.json:

{
  "compilerOptions": {
    "target": "es2022",
    "module": "commonjs",
    "esModuleInterop": true,
    "strict": true,
    "skipLibCheck": true
  }
}

index.ts:

import middy from '@middy/core'
import secretsManager from '@middy/secrets-manager'
import { APIGatewayProxyEvent, APIGatewayProxyResult } from 'aws-lambda'

export const handler = middy<APIGatewayProxyEvent, APIGatewayProxyResult>()
  .use(
    secretsManager({
      fetchData: {
        apiToken: 'dev/api_token',
      },
      awsClientOptions: {
        region: 'us-east-1',
      },
      setToContext: true,
    })
  )
  .handler(async (req, context) => {
    // The context type gets augmented here by the secretsManager middleware.
    // This is just an example, obviously don't ever log your secret in real life!
    console.log(context.apiToken)
    return {
      statusCode: 200,
      body: JSON.stringify({
        message: `Hello from ${req.path}`,
        req,
      }),
    }
  })

Run tsc to check types

Command:

npm install && npx tsc --noEmit --pretty

index.ts:17:19 - error TS7006: Parameter 'req' implicitly has an 'any' type.

17   .handler(async (req, context) => {
                     ~~~

index.ts:17:24 - error TS7006: Parameter 'context' implicitly has an 'any' type.

17   .handler(async (req, context) => {
                          ~~~~~~~


Found 2 errors in the same file, starting at: index.ts:17

Workaround

Downgrading to Middy 4 makes it work:

{
  "name": "middy-example",
  "version": "1.0.0",
  "dependencies": {
    "@middy/core": "^4.7.0",
    "@middy/secrets-manager": "^4.7.0",
    "@types/aws-lambda": "^8.10.141",
    "@types/node": "^20.14.10",
    "typescript": "^5.5.3"
  }
}

[canassa]

Thanks!

I created a separate PR to fix the docs.

[willfarrell]

merged, and docs rebuilding now

[canassa]

@willfarrell The PR I opened only addresses the documentation. However, this regression issue remains unresolved.