[@aws-cdk/aws-lambda-nodejs] Failed to bundle asset TestStack/handler/Code/Stage: test/lib/lib/test-stack.handler.ts does not exist

[markusl]

Specifying projectRoot for the NodejsFunction seems to fail the local parcel bundling. If we don't specify projectRoot the project will fail in AWS CodePipeline with an error Error: Cannot find project root. Please specify it with projectRoot.

Could you please provide a reference setup of how the construct is meant to be used?

Reproduction Steps

Initialize an empty project and run npm install --save-dev parcel@next.

export class TestStack extends cdk.Stack {
  constructor(scope: cdk.Construct, id: string, props?: cdk.StackProps) {
    super(scope, id, props);

    new lambda_nodejs.NodejsFunction(this, 'handler', {
      projectRoot: '.',
      runtime: lambda.Runtime.NODEJS_12_X,
      minify: true,
      description: 'Handler',
      nodeModules: [],
    });
  }
}

What did you expect to happen?

I would expect the code to be synthesized properly.

What actually happened?

Synthetizing the code will lead to an error:

> tsc

Bundling asset TestStack/handler/Code/Stage...
🚨 Build failed.
Error: Entry test/test/lib/test-stack.handler.ts does not exist
Error: Entry test/test/lib/test-stack.handler.ts does not exist
    at EntryResolver.resolveEntry (test/node_modules/@parcel/core/lib/EntryResolver.js:44:13)
    at async EntryRequestRunner.runRequest (test/node_modules/@parcel/core/lib/RequestTracker.js:372:43)
    at async test/node_modules/@parcel/core/lib/AssetGraphBuilder.js:305:9
    at async PromiseQueue._runFn (test/node_modules/@parcel/utils/lib/PromiseQueue.js:98:7)
    at async PromiseQueue._next (test/node_modules/@parcel/utils/lib/PromiseQueue.js:85:5)
Failed to bundle asset TestStack/handler/Code/Stage, bundle output is located at test/cdk.out/bundling-temp-HBHI5M-error: Error: bash exited with status 1

Environment

• CLI Version : 1.61.1 (build 347918f)
• Framework Version:
• Node.js Version: 14
• OS : macOs
• Language (Version): 4.0.2

Other

---

This is 🐛 Bug Report

[jogold]

Can you try with a path relative to _dirname?

path.join(__dirname, '..'); // adapt '..' if needed

Adapt .. if needed to go from the file where your NodejsFunction is defined to your project root. The project root is the folder where your top level node_modules folder is located, will add this to the doc/error message.

[markusl]

@jogold yep, that seems to work. It would be good if it worked out of the box with sensible defaults for the usual use cases :)

[jogold]

It would be good if it worked out of the box with sensible defaults for the usual use cases :)

Agree

[leimd]

I was consistently hitting this issue in AWS CodeBuild as well, I haven't run into this problem in my dev environment though. To troubleshoot this issue, I have put in some console.logs into util.js and run it on CodeBuild to see what's different.
I was running cdk 1.62.0
Here is what I have modified in util.js:

And the way I get CodeBuild to use this file is by uploading it to a Github gist and download it during build time and override the original file.

When running in CodeBuild, it seems the findUp method for package.json works just fine, here are some of the logs from my CodeBuild job:

But when it's the turn to find the .git folder, process.cwd() has defaulted to start from the base folder:

It turned out the process.cwd() in this method defaults to this folder in my project's folder and didn't actually end up finding the correct projectRoot.

As a result, I have implemented a new method in util.ts called getCallerDir where it will always start to look from the directory of the file where a new NodeJsFunction is instantiated.

Here is the PR: #10331

I do have to add a new nodejs library and in order to pass the pgklint test, that package was added to the root package.json's nohoist list, it would be great someone can help me with this to see if this is necessary.

After I made the change and built the js files, I have tested with my own CodeBuild job by swapping out util.js and bundling.js during build time and the error no longer persists.