Aws-cdk: [core] Unable to Synthesize CDK in 1.57: Assets must be defined indirectly within a "Stage" or an "App" scope

[tneely]

After upgrading to 1.57 I get the following error when trying to synthesize my application:

unable to determine cloud assembly output directory. Assets must be defined indirectly within a "Stage" or an "App" scope

I tried specifying outdir in my App as well as my Stage, but neither works (in App throws same error, in Stage throws nested stage error).

Reproduction Steps

I haven't quite nailed down the triggering code, but here's my general setup:

export interface MyStackProps extends cdk.StackProps {
    source: s3deploy.ISource;
    code: lambda.Code;
}

class MyStack extends cdk.Stack {
    constructor(scope: cdk.Construct, props: MyStackProps) {
        super(scope, "MyStack", props)

       ...

        new lambda.Function(this, "ApiHandler", {
          code: props.code,
        });

        new s3deploy.BucketDeployment(this, "DeployWithInvalidation", {
          sources: [props.source],
          destinationBucket: someDistributionBucket,
          distribution: someDistribution,
        });
    }
}

class MyStage extends cdk.Stage {
  constructor(scope: cdk.Construct, id: string, props?: cdk.StageProps) {
    super(scope, id, props);

    new MyStack(this, {
       // Changing these values to `{} as any` still throws the same scope error
        code:  lambda.Code.fromAsset("../api/dist"),
        source: s3deploy.Source.asset("../app/build"),
    });
  }
}

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

    const sourceArtifact = new codepipeline.Artifact();
    const cloudAssemblyArtifact = new codepipeline.Artifact("CloudAssemblyArtifact");

    const pipeline = new pipelines.CdkPipeline(this, "Pipeline", {
      pipelineName: "MyAppPipeline",
      cloudAssemblyArtifact,

      sourceAction: new codepipeline_actions.GitHubSourceAction({...}),

      synthAction: pipelines.SimpleSynthAction.standardNpmSynth({
        sourceArtifact,
        cloudAssemblyArtifact,
        ...
      }),
    });

    pipeline.addApplicationStage(new MyStage(this, "Prod"));
  }
}

const app = new cdk.App();
new PipelineStack(app, "PipelineStack");

What did you expect to happen?

The CDK app synthesizes correctly.

What actually happened?

Synthesis fails with the message unable to determine cloud assembly output directory. Assets must be defined indirectly within a "Stage" or an "App" scope

Environment

• CLI Version : 1.57
• Framework Version: 1.57
• Node.js Version: v14.3.0
• OS : Ubuntu (on WSL2)
• Language (Version): TypeScript (3.9.7)

Other

Here's where the error is being thrown

---

This is :bug: Bug Report

[eladb]

Just for sanity: can you please nuke your node_modules directory, verify that all the CDK modules in your package.json use the exact same version (preferably pinned), reinstall (yarn install or npm install) and let us know if this persists?

[tneely]

I'll give it a shot and update you shortly. I was debugging the synth and found it's failing on isStage(x) (Stage.of(this) returns undefined). Which is weird because at one point the loop hits the MyStage class and doesn't consider it an instanceof Stage despite having __proto__: Stage

Update: nuked node_modules and reinstalled and the error persists. The versions aren't pinned but I did a quick ctrl+f of the package-lock.json and confirmed nothing is on 1.56.

[billmcknight1953]

I am also getting this error when following this blog post blog. I get this error during the build step after adding the first application stage. I got the error with 1.57, downgraded to 1.56 and am still getting this error. I nuked my node-modules, verified that every entry has the same cdk version.

[tneely]

My package structure is a bit weird since I'm writing a construct library. It looks something like this:

my-custom-construct/
 - lib/
 - package.json
 - example/
    - lib/
    - package.json

where my-custom-construct/example/package.json has the following dependency "my-custom-construct": "file:../".

I noticed that when running cdk synth in the example directory, it's using the @aws-cdk/core package from the root directory. As an experiment I brought the root lib code into example, removed the my-custom-construct dependency, and deleted the root node_modules to ensure it wouldn't be used. With everything contained in the example directory, Stage.of() properly returned MyStage and synthesis worked just fine. Maybe instanceof Stage from my-custom-construct/node_modules was failing against the Stage class in the my-custom-construct/example/node_modules?

I'll spend some time digging into Node's package system so that I can better understand what's happening and update later.

[tneely]

Ok, here's what I think's happening. I'm going to close the issue since this seems specific to my setup.

By using "my-custom-construct": "file:../" in my-custom-construct/example/package.json Node will symlink my-custom-construct/ at my-custom-construct/example/node_modules/my-custom-construct. Because the way module resolution works with require(), Node is only checking for dependencies at my-custom-construct/node_modules/. Because of this we end up using two different versions of Stage, which, despite them being the same 1.57 version, causes instanceof Stage to fail and cause the output directory validation to fail as well.

I was able to work around the issue by using yalc to "package" my-custom-construct and reference it in the example package as "my-custom-construct": "file:.yalc/my-custom-construct"

[eladb]

Thanks for following up

[johnmarian]

I have constructs in a library that I'm importing and I'm getting this same error since updating the library and the application to 1.57.0

[inirudebwoy]

Yes, I also have this issue. Managed to work around it by downgrading to 1.56.

[Dzhuneyt]

This is far from a perfect workaround for developers that create AWS CDK constructs as packages. You will often find yourself including external npm packages using the file:../..... approach. Is there a better workaround that makes CDK core recognise the path the the assets, even when they are symlinked.

[Dzhuneyt]

Just managed to reporoduce this in a clean AWS CDK app without any relative packages in package.json. I have a clean stack with only the following construct:

new lambda.Function(this, 'js', {
                handler: "handler",
                runtime: lambda.Runtime.NODEJS_12_X,
                code: lambda.Code.fromAsset(path.resolve(__dirname, './../lambda/js'))
            });

Versions:

  "devDependencies": {
    "@aws-cdk/assert": "1.45.0",
    "@types/jest": "^25.2.1",
    "@types/node": "10.17.5",
    "aws-cdk": "^1.57.0",
    "jest": "^25.5.0",
    "ts-jest": "^25.3.1",
    "ts-node": "^8.1.0",
    "typescript": "~3.7.2"
  },
  "dependencies": {
    "@aws-cdk/aws-lambda-nodejs": "^1.57.0",
    "@aws-cdk/core": "^1.57.0",
    "source-map-support": "^0.5.16"
  }

[Dzhuneyt]

Fixing all CDK related packages to 1.56.0 seems to resolve the issue.

[kennu]

I got the same error message with 1.57.0 when trying to deploy a NodejsFunction with TypeScript in it. I couldn't figure out how to configure AWS CDK to make it work.

While trying to figure it out, I removed tsconfig.json and package.json from my Lambda function directory and got some weird permission errors about not being able to create .parcel-cache. At some point .parcel-cache was created as owned by root. Not sure if these problems are caused because I run AWS CDK itself in a Docker container. The asset implementation doesn't seem to be entirely mature yet.

I'm hoping the NodejsFunction construct will have clear documentation about everything that is needed to make it work.

[billmcknight1953]

Two of us at my company got this error message when closely implementing this CDK Pipelines blog post. In our case the problem was due to a package.json entry for aws-cdk/core of "1.57.0" while all the other CDK packages were "^1.57.0".

Once the packages are all aligned, of course, you should delete your node_modules, and package.lock.json, and perform a npm install. The error message implies a cloud assembly output location has not been configured but this seems a misleading error message considering how we fixed it, See also https://github.com/aws/aws-cdk/issues/957

[fongie]

I had this problem in v1.58.0 when following the CDK Pipelines blog post. I have a local npm package reference (file:../etc) as well. Removing the local package did not fix it, but downgrading to pinned 1.56.0 fixed it for me, even when reintroducing the local package.

Maybe this issue should be reopened?

[GCSDC]

I had the same issue and fixed it with these steps:

1. Set version of all cdk related packages to "ˆ1.59.0"

   "devDependencies": {
   "@aws-cdk/assert": "^1.59.0",
   "@types/jest": "^25.2.1",
   "@types/node": "10.17.5",
   "aws-cdk": "^1.59.0",
   "jest": "^25.5.0",
   "ts-jest": "^25.3.1",
   "ts-node": "^8.1.0",
   "typescript": "~3.7.2"
   },
   "dependencies": {
   "@aws-cdk/aws-apigateway": "^1.59.0",
   "@aws-cdk/aws-codepipeline": "^1.59.0",
   "@aws-cdk/aws-codepipeline-actions": "^1.59.0",
   "@aws-cdk/aws-lambda": "^1.59.0",
   "@aws-cdk/core": "^1.59.0",
   "@aws-cdk/pipelines": "^1.59.0",
   "@types/aws-lambda": "^8.10.61",
   "source-map-support": "^0.5.16"
   }
   

2. Delete both node_modules and package-lock.json

3. Run npm install

[thiagotgo90]

I followed the steps from @GCSDC using ^1.60.0 and it worked for me.

[hades2510]

+1 on @GCSDC solutions. You need to match the package version for dev deps also.

[blncoxauto]

I can confirm @Dzhuneyt 's experience

The error I am getting is with Code.fromAssetPath in a use case similar to @tneely with an examples subdirectory.

            code: lambda.Code.fromAsset(path.resolve(__dirname, './../lambda/js'))

Updating to 1.60 and doing a clean of package-lock.json and node-modules with a clean install didn't resolve things. If I update the lambda to use an inline block of code it doesn't fail.

[misk0]

I was following this tutorial and on step "Add the service to the app" (its first time lambda is wired with CDK) it broke with this message:

d:\SUPSI\workspace\MyWidgetService>cdk synth
d:\SUPSI\workspace\MyWidgetServicenode_modules\@aws-cdk\aws-s3-assetsnode_modules\@aws-cdk\corelib\asset-staging.js:39
throw new Error('unable to determine cloud assembly output directory. Assets must be defined indirectly within a "Stage" or an "App" scope');
^

Error: unable to determine cloud assembly output directory. Assets must be defined indirectly within a "Stage" or an "App" scope
at new AssetStaging (d:\SUPSI\workspace\MyWidgetServicenode_modules\@aws-cdk\aws-s3-assetsnode_modules\@aws-cdk\corelib\asset-staging.js:39:19)
at new Asset (d:\SUPSI\workspace\MyWidgetServicenode_modules\@aws-cdk\aws-s3-assetslib\asset.js:21:25)
at AssetCode.bind (d:\SUPSI\workspace\MyWidgetServicenode_modules\@aws-cdk\aws-lambdalib\code.js:137:26)
at new Function (d:\SUPSI\workspace\MyWidgetServicenode_modules\@aws-cdk\aws-lambdalib\function.js:83:33)
at new WidgetService (d:\SUPSI\workspace\MyWidgetServicelib\widget_service.js:12:21)
at new MyWidgetServiceStack (d:\SUPSI\workspace\MyWidgetServicelib\my_widget_service-stack.js:14:5)
at Object. (d:\SUPSI\workspace\MyWidgetService\bin\my_widget_service.js:7:1)
at Module._compile (internal/modules/cjs/loader.js:1138:30)
at Object.Module._extensions..js (internal/modules/cjs/loader.js:1158:10)
at Module.load (internal/modules/cjs/loader.js:986:32)
Subprocess exited with error 1

I'm using cdk 1.61.1

[philhorrocks]

Im also getting the error after update to 1.61.1. I have tried rebuilding using npm install. Still getting "unable to determine cloud assembly output directory. Assets must be defined indirectly within a "Stage" or an "App" scope"

[billmcknight1953]

There may at least two separate situations which trigger this error: The first case is one where there is a simple discrepancy in the aws cdk version libraries. This can be as subtle as having a package.json with the following entries

    "@aws-cdk/aws-lambda": "^1.60.0",
    "@aws-cdk/core": "1.60.0",

especially after a new version has come out.

If your problem is solved by changing the package.json & setting the cdk libraries to have the exact same version (either all pinned or not) -- and updating the package.lock.json-- then it seems to me that the error message is misleading when it says that "_Assets must be defined indirectly within a "Stage" or an "App" scope_"

The second case is one where there is some nesting of the assets (like a lambda). And here the error message kind of makes sense, and is unlikely to be solved by updating the aws cdk package versions.

[misk0]

I saw cdk 1.62.0 is out so I canceled node_modules and downloaded all but the error remains the same :(

[jonny-rimek]

As far as I can tell the error is caused by some dependencies being pinned and and some aren't, when you create a new repo with cdk init.

I fixed it by unpinning all dependencies, deleting node_modules and deleting package-lock.json.

{
  ...
  "devDependencies": {
    "@aws-cdk/assert": "^1.62.0",
    "@types/jest": "^26.0.13",
    "@types/node": "10.17.27",
    "aws-cdk": "^1.62.0",
    "jest": "^26.0.4",
    "ts-jest": "^26.1.3",
    "ts-node": "^8.1.0",
    "typescript": "~3.9.6"
  },
  "dependencies": {
    "@aws-cdk/aws-ec2": "^1.62.0",
    "@aws-cdk/aws-ecs": "^1.62.0",
    "@aws-cdk/aws-ecs-patterns": "^1.62.0",
    "@aws-cdk/aws-rds": "^1.62.0",
    "@aws-cdk/aws-s3": "^1.62.0",
    "@aws-cdk/core": "^1.62.0",
    "source-map-support": "^0.5.16"
  }
}

rm package-lock.json rm -rf node_modules

worked perfectly.

@billmcknight1953 I had both errors and fixed both with the above steps

[misk0]

@jonny-rimek This really helped. I aligned version of all packages, eliminated node_modules and package-lock.json and I had to reinstall aws-cdk because it wasn't updated to last version. And it works..
So I suppose in my case one part of the problem was old (1.32.0) version of aws-cdk installed on my machine.
Thanks

[jonny-rimek]

yea the CDK init template should definitely be fixed @eladb

[mattiLeBlanc]

Yup, removing node_modules and removing lock file also got rid of that error when using new AssetCode() for the Lambda src.

[gbooth27]

Yup, removing node_modules and removing lock file also got rid of that error when using new AssetCode() for the Lambda src.

@mattiLeBlanc I did the removal of lock files and node modules to get them all to the exact same CDK version, but I also have lambdas that use the asset code for the lambda source:
code: lambda.Code.asset(path.join(__dirname, '../../lambdas/datadog_lambda')),
how were you able to resolve the errors from that?

[mattiLeBlanc]

@gbooth27 What is your error message?

I am using asset like this:
```
...
code: new AssetCode( [path to lambda source]),
...

[gbooth27]

@mattiLeBlanc ah ok thats slightly different than what I am doing, you can find more detail on my issues here https://github.com/aws/aws-cdk/issues/10314 I eventually just gave up and only upped it to 1.56.0 as from this thread it sounds like the issues with the asset error only start showing up in 1.57.0

[jonny-rimek]

@gbooth27 did you try unpinning all versions and reinstalling from scratch? thats what worked for me and also got rid of the asset error.

[gbooth27]

@jonny-rimek no, I can give that a shot, I tried the pinning them all at the same version and re-installing everything after removing the node modules and lock files

[mattiLeBlanc]

I have the same issue now again with version 1.63 :(

unable to determine cloud assembly output directory. Assets must be defined indirectly within a "Stage" or an "App" scope
Subprocess exited with error 1

Just nuked the node_modules folder, alas.
Downgrading everything to "1.6.2" worked. Weird.

[Shogan]

Hitting the exact same bug and its definitely when you specify Lambda function with lambda.Code.fromAsset. See https://github.com/aws/aws-cdk/issues/10314#issuecomment-700293757 for details.

[codeandcats]

I had this error because I had two version of aws-cdk in my monorepo. I fixed it by moving them onto the same version, nuking all my node modules and reinstalling them. 👌

[kmturley]

There seems to be another issue with semvar dependencies using the hat symbol `^. For example:

"devDependencies": {
    "@aws-cdk/assert": "^1.68.0",
    "aws-cdk": "^1.68.0",
  },
  "dependencies": {
    "@aws-cdk/aws-waf": "^1.68.0",
    "@aws-cdk/core": "^1.68.0",
    "@aws-solutions-constructs/aws-cloudfront-s3": "^1.68.0",
  }

Steps:

• Removing node_modules
• Removing package-lock.json
• running npm install

Then looking at the package-lock.json I see it's installed 1.69.0 somehow:

"dependencies": {
    "@aws-cdk/assert": {
      "version": "1.69.0",
      "resolved": "https://registry.npmjs.org/@aws-cdk/assert/-/assert-1.69.0.tgz",
      "integrity": "sha512-VGjF1sNx05ez5/dwQ8Gn1Bc72X4Tjg1zOPRXq/1LOan2PFWz7WiwHvpww85dRWK1N0R462k6ntUshU8U3TSOBA==",
      "dev": true,
      "requires": {
        "@aws-cdk/cloud-assembly-schema": "1.69.0",
        "@aws-cdk/cloudformation-diff": "1.69.0",
        "@aws-cdk/core": "1.69.0",
        "@aws-cdk/cx-api": "1.69.0",
        "constructs": "^3.0.4"
      }
    }

If I lock my dependencies by removing the hat symbols ^ from versions e.g.:

"devDependencies": {
    "@aws-cdk/assert": "1.68.0",
    "aws-cdk": "1.68.0",
  },
  "dependencies": {
    "@aws-cdk/aws-waf": "1.68.0",
    "@aws-cdk/core": "1.68.0",
    "@aws-solutions-constructs/aws-cloudfront-s3": "1.68.0",
  }

Then it installs correctly:

"dependencies": {
    "@aws-cdk/assert": {
      "version": "1.68.0",
      "resolved": "https://registry.npmjs.org/@aws-cdk/assert/-/assert-1.68.0.tgz",
      "integrity": "sha512-KHL0Z+7jzGzpZnjlCXmGONS0nBecU4eMWOQaUaMXtzQ5iwEEMq/GCwdy59m0TM919UQi3RgPvGV+YPY/Laptxg==",
      "dev": true,
      "requires": {
        "@aws-cdk/cloud-assembly-schema": "1.68.0",
        "@aws-cdk/cloudformation-diff": "1.68.0",
        "@aws-cdk/core": "1.68.0",
        "@aws-cdk/cx-api": "1.68.0",
        "constructs": "^3.0.4"
      }
    },

This fixed the issue I was having

[andrewmcoupe]

Updating aws-cdk and @aws-cdk/* versions fixed this for me.