Si alguien ve esto, se encuentra con el mismo problema. Consulte lo siguiente del soporte técnico oficial de AWS:

"Sus instrucciones para usar package.json { "type": "module" } son correctas, pero los módulos ECMAScript no son compatibles con el tiempo de ejecución de Lambda Node.js 14 en este momento".

Publicaré una actualización de esta publicación cuando escuche más sobre cuándo hay soporte disponible. Dejo esta pregunta aquí en caso de que otras personas tengan el mismo problema.

AWS Lambda no es compatible oficialmente con ESM, pero con las siguientes soluciones funciona sin problemas.

Esta respuesta es un resumen de diferentes soluciones inspiradas en las respuestas/comentarios de Evan Sosenko y Dan Kantor y algunas ideas adicionales mías. Esto incluye un manejo más agradable para proyectos mecanografiados, pero partes de él también se pueden usar para proyectos simples de javascript.

Asumo lo siguiente:

1. Se utiliza la versión 14 de Node.js: FROM public.ecr.aws/lambda/nodejs:14
2. Se utilizan contenedores sin servidor: FROM public.ecr.aws/lambda/nodejs:14
3. Las importaciones locales deberían funcionar sin que finalice el archivo: import { success } from './utils/log';
4. Las importaciones desde libs deben usar la sintaxis de ESM: import AWS from 'aws-sdk';
5. La lambda está escrita en mecanografiado: (.ts es el sufijo del archivo).

(También proporciono información para .js simple en lugar de mecanografiado al final)

Dockerfile

 FROM public.ecr.aws/lambda/nodejs:14 # copy only package.json + package-lock.json COPY package*.json ./ # install all npm dependencies including dev dependencies RUN npm install # copy all files not excluded by .dockerignore of current directory to docker container COPY . ./ # build typescript RUN tsc # remove npm dev dependencies as they are not needed anymore RUN npm prune --production # remove typescript sources # RUN rm -r src # rename all .js files to .mjs and fix imports except for handler.js RUN find ./dist -type f -name "*.js" -exec sed -i 's/\.js/\.mjs/g' {} \; RUN find ./dist -type f -name -and -not -name "handler.js" "*.js" -exec sh -c 'mv "$0" "${0%.js}.mjs"' {} \; # allow local imports without file ending - see: https://nodejs.org/api/esm.html ENV NODE_OPTIONS="--experimental-specifier-resolution=node" # set handler function CMD ["dist/lambda/handler.handler"]

Explicación

Dado que AWS Lambda solo admite commonJS, el punto de entrada de Lambda es un archivo commonJS. Esto se especifica mediante un paquete.json vacío que sobrescribe el paquete.json desde la raíz del proyecto. Como este archivo está vacío, no contiene: "type":"module" y por defecto todos los archivos en esa carpeta y subcarpetas son commonJS. Un archivo commonJS puede acceder a los archivos ESM si tiene la extensión .mjs, pero como el mecanografiado se compila en .js, uso algunos comandos de Unix para cambiar el nombre de todos los archivos con ".*js" después de llamar a tsc. El handler.js tiene que permanecer como ".js", así que le cambio el nombre de .mjs.
Más sobre ".js/.mjs"

Estructura de carpetas

 - src - - lambda - - - handler.ts (commonJS) - - - package.json (contains only: `{}`) - - app.ts (ESM) - - services - - - (other .ts files ESM) - package.json (contains `{"type": "module"}`, but also other settings) - Dockerfile - tsconfig.json

manejador.ts

 exports.handler = async (event) => { const {App} = await import('../app.js'); const app = new App(); return await app.run(event); };

aplicación.ts

 // example import library import AWS from 'aws-sdk'; // example import local file import {FileService} from './services/file.service'; class App { constructor() { } async run(event) { // write your logic here return { 'statusCode': 200, 'body': JSON.stringify({'message': 'hello world'}) } } } export {App};

tsconfig.json

 { "compilerOptions": { "module": "ESNext", "moduleResolution": "Node", "esModuleInterop": true, "declaration": true, "removeComments": true, "allowSyntheticDefaultImports": true, "target": "es6", "sourceMap": true, "outDir": "./dist", "baseUrl": "./src", "lib": [ "es6", "dom" ] }, "include": [ "src/**/*" ] }

Diferencias si no se usa mecanografiado

Supongamos que no está utilizando mecanografiado, pero javascript como se menciona en la pregunta que cambia lo siguiente:

• no use el comando tsc en Dockerfile
• no tiene un archivo tsconfig.json
• todos los archivos deben tener el nombre *.js en lugar de *.ts
• obviamente no use ninguna escritura mecanografiada (en mi ejemplo no hay ninguna)

Esto funcionó para mí en Lambda Node 14.x -

en aplicación.js

 exports.lambdaHandler = async (event, context) => { const { App } = await import('./lib/app.mjs'); return new App(event, context); }

Y luego en lib/app.mjs -

 class App { constructor(event, context) { return { 'statusCode': 200, 'body': JSON.stringify({ 'message': 'hello world' }) } } } export {App}

Parece que desde ayer finalmente hay soporte nativo para la sintaxis del módulo ES6 en Node 14 lambdas - consulte https://aws.amazon.com/blogs/compute/using-node-js-es-modules-and-top-level -esperar-en-aws-lambda