(Aware of other issues) No "exports" main defined in /var/task/node_modules/@middy/core/package.json about middy HOT 7 CLOSED

We're facing the same issue and this blocks us from upgrading v.4.7.0 -> v.5

from middy.

Are you both using TypeScript? From my understanding TS transpiles (tsc?) to commonJS first before importing dependencies, which would cause this issue.

from middy.

Are you both using TypeScript? From my understanding TS transpiles (tsc?) to commonJS first before importing dependencies, which would cause this issue.

It would be disappointing if the library no longer supports TS.
If that is the case with v5, then some sort of LTS v4 needs to be produced and continued support.

I have encountered this issue in JS and TS with lambdas, Nodejs, and other frameworks.

from middy.

Does the sample compiler options found at https://middy.js.org/docs/intro/typescript/ need to be updated? If so, a PR would be most welcome.

from middy.

Yes we're using typescript.. that sounds like it would be the issue and needs updating. Unfortunately I'm not too familiar with how the PR would look like for this fix

from middy.

Hello, I spent a bit of time trying to troubleshoot this with @willfarrell today and we were not able to fully reproduce your issue, this is what we did:

package.json

{
  "name": "middy-test",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "type": "module",
  "keywords": [],
  "author": "",
  "license": "ISC",
  "devDependencies": {
    "aws-lambda": "^1.0.7",
    "typescript": "^5.4.5"
  },
  "dependencies": {
    "@middy/core": "^5.3.3"
  }
}

tsconfig.json

{
  "compilerOptions": {
    "target": "ES2022",
    "module": "ES2022",
    "lib": [
      "es2022"
    ],
    "outDir": "./dist",
    "declaration": true,
    "strict": true,
    "noImplicitAny": true,
    "strictNullChecks": true,
    "noImplicitThis": true,
    "alwaysStrict": true,
    "noUnusedLocals": false,
    "noUnusedParameters": false,
    "noImplicitReturns": true,
    "noFallthroughCasesInSwitch": false,
    "inlineSourceMap": true,
    "inlineSources": true,
    "experimentalDecorators": true,
    "strictPropertyInitialization": false,
    "typeRoots": [
      "./node_modules/@types",
      "./types"
    ],
    "moduleResolution": "node",
    "esModuleInterop": true,
    "forceConsistentCasingInFileNames": true,
    "skipLibCheck": true
  },
  "include": [
    "src/**/*"
  ],
  "exclude": [
    "node_modules",
    "cdk.out",
    "./dist/**/*" // Excluding the output directory
  ]
}

src/test.ts

// testing an import of middy using ESM
import middy from '@middy/core'

// testing a top level await promise
await Promise.resolve("hello")

// testing building a simple handler
export const handler = middy(async function(_event: any, _context: any) {
  return {
    statusCode: 200,
    body: JSON.stringify({
      message: 'Hello world'
    })
  }
})

Then we run:

node_modules/.bin/tsc

and if we execute the compiled file with:

node dist/test.js

It runs correctly with no error...

Can you see if what we did makes sense to you and spot any difference with your current setup?

Also, can you double check that your compiled files are actually using ESM (import/export) and not CommonJS (require)?

Hopefully this helps...

PS: note that our compiled file looks like this:

import middy from '@middy/core';
await Promise.resolve("hello");
export const handler = middy(async function (_event, _context) {
    return {
        statusCode: 200,
        body: JSON.stringify({
            message: 'Hello world'
        })
    };
});

and that we are using:

❯ node_modules/.bin/tsc --version
Version 5.4.5

from middy.

Will try troubleshooting this week with your setup above, I wonder if it's only an issue once deployed to AWS for some reason

from middy.