Backend Lambda switches from container image to ZIP via CDK NodejsFunction and esbuild
dropthejase abandoned the ARM64 Lambda container approach and moved to ZIP packaging via CDK's `NodejsFunction`, eliminating a 99-line hand-rolled deploy script and the Docker/Finch requirement for backend deploys. One specific gotcha: `pdfjs-dist` must stay in `nodeModules` because its dynamic `.mjs` import breaks esbuild bundling.
The migration removes Dockerfile.lambda and deletes scripts/deploy-backend.sh, which had been doing npm ci --omit=dev --os linux --cpu arm64, copying into lambda-pkg/, zipping, and calling aws lambda update-function-code. The CDK stack switches lambda.DockerImageFunction for NodejsFunction pointing directly at backend/src/lambda.ts. A cdk.context.json pins eu-west-1 AZs for reproducible synth.
The esbuild bundling config goes through several iterations. An initial nodeModules list includes pdfjs-dist, libreoffice-convert, mammoth, docx, and jszip. Then libreoffice-convert is removed from the API Lambda because conversion moved to its own dedicated Lambda. docx is removed as unused. The nodeModules list gets dropped once none of the remaining heavy deps require it - except pdfjs-dist. That one stays because its dynamic require('pdfjs-dist/legacy/build/pdf.mjs') is unsafe for esbuild to process.
The final config at 60fa124: Node 22, minify: false, sourceMap: true, @aws-sdk/client-bedrock-runtime added to externalModules to prevent bundling conflicts.
Spotted something wrong? Or know the PR text has fresher detail than the writeup above?