Invalid type definitions - static import of ESM types from CJS types
Describe the bug
../../node_modules/.pnpm/@[email protected]/node_modules/@netlify/functions/dist/function/v2.d.ts:1:30 - error TS1479: The current file is a CommonJS module whose imports will produce 'require' calls; however, the referenced file is an ECMAScript module and cannot be imported with 'require'. Consider writing a dynamic 'import("@netlify/serverless-functions-api")' call instead.
1 export type { Context } from '@netlify/serverless-functions-api';
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Found 1 error in ../../node_modules/.pnpm/@[email protected]/node_modules/@netlify/functions/dist/function/v2.d.ts:1
Configuration
Import the library in a project which has the following in the tsconfig.json:
"module": "node16",
"moduleResolution": "node16",
This issue can be worked around with "skipLibCheck": true, so ensure that is not set when reproducing. It is not set by default.
Thanks for reporting this! It's good to know there's a workaround, i'll add it to our internal triage.
I'm a bit surprised about TypeScript emitting this error for a .d.ts file. That can't use require anyways, right?
They're not using require, but you can only import CJS from ESM if you use a dynamic import. Another possible solution besides updating the types would be to distribute this package as ESM.
They're not using require, but you can only import CJS from ESM if you use a dynamic import.
We're only importing @netlify/serverless-functions-api for types:
https://github.com/netlify/functions/blob/main/src/function/v2.ts#L1
So I don't think that an actual import line shows up in the generated JS file. This seems to be purely about the declaration file that TypeScript generates, and I would have expected TypeScript to generate it in a way that's compliant with CJS, because that's how it's configured:
https://github.com/netlify/functions/blob/755237528a51e88204b22f07cd47e93a7ea42759/tsconfig.json#L27
Anyways, distributing this as ESM makes sense to me. @eduardoboucas do you see any reason why this might become a problem? Maybe consumption from within Next.js sites?
I think this will be fixed by #473