aws-cdk: @aws-cdk/aws-lambda-nodejs doesn't give useful error messages when builds fail.

We’re looking at switching over from Serverless to CDK for deploying our lambdas to minimise size. One of the things that Serverless does that I don’t know how to do cleanly in CDK is excluding devDependencies from the final built package that gets zipped / uploaded.

How do I go about configuring this behaviour in CDK?

This is a 📕 documentation issue

About this issue

Original URL
State: closed
Created 4 years ago
Comments: 20 (9 by maintainers)

Commits related to this issue

fix(lambda-nodejs): no parcel error message when build fails Parcel outputs its error message to `stdout` not `stderr`. Also refactored tests to isolate tests on the `build` function. Fixes #6274 — committed to jogold/aws-cdk by jogold 4 years ago
fix(lambda-nodejs): not meaningful parcel error message when build fails (#6277) * fix(lambda-nodejs): no parcel error message when build fails Parcel outputs its error message to `stdout` not `stde... — committed to aws/aws-cdk by jogold 4 years ago

Most upvoted comments

@jogold I went ahead and ran npm i -g parcel-bundler to work around that error.

Now I get:

[project directory]/backend/packages/infrastructure/node_modules/@aws-cdk/aws-lambda-nodejs/lib/build.ts:85
    throw new Error(`Failed to build file at ${options.entry}: ${err}`);
          ^
Error: Failed to build file at [project directory]/backend/packages/consumer-api/src/index.ts: Error
    at Object.build ([project directory]/backend/packages/infrastructure/node_modules/@aws-cdk/aws-lambda-nodejs/lib/build.ts:85:11)
    at new NodejsFunction ([project directory]/backend/packages/infrastructure/node_modules/@aws-cdk/aws-lambda-nodejs/lib/function.ts:89:5)
    at Object.exports.attach ([project directory]/backend/packages/infrastructure/src/consumer-api/v1/index.ts:31:22)
    at Object.exports.attach ([project directory]/backend/packages/infrastructure/src/consumer-api/index.ts:17:5)
    at new ApiService ([project directory]/backend/packages/infrastructure/src/index.ts:29:15)
    at Object.<anonymous> ([project directory]/backend/packages/infrastructure/src/index.ts:36:1)
    at Module._compile (internal/modules/cjs/loader.js:778:30)
    at Module.m._compile ([project directory]/backend/packages/infrastructure/node_modules/ts-node/src/index.ts:814:23)
    at Module._extensions..js (internal/modules/cjs/loader.js:789:10)
    at Object.require.extensions.(anonymous function) [as .ts] ([project directory]/backend/packages/infrastructure/node_modules/ts-node/src/index.ts:817:12)

Not sure what to do to figure out what the Error actually is.

thekevinbrown on Feb 14, 2020

a) new lambdaNodejs.NodejsFunction by default builds the handler code next to the source code, not in ./.build as your command implies

Yes I know, the point was to see if this is a parcel error and what kind of error. In this case the out-dir doesn’t matter.

deleting any build files, then modifying your command’s out-dir to parcel build src/restart-service/index.ts --out-dir src/restart-service/.build --out-file index.js --global handler --target node --bundle-node-modules --log-level 2 --no-minify, THEN runnning the tests fails

The lambdaNodejs.NodejsFunction builds in a subfolder of src/restart-service/.build. Again just a test here to see if it’s parcel related. Looks like it’s not?

jogold on Mar 10, 2020

I should note that I’ve also tried to use @aws-cdk/aws-lambda-nodejs but I get Error: spawnSync parcel ENOENT when I try that, so I was wondering if there was a way to do this without using aws-lambda-nodejs or if I should keep trying to work through the ENOENT error.

thekevinbrown on Feb 14, 2020