Aws-cdk: Argument of type 'this' is not assignable to parameter of type 'Construct'.

[mikegwhit]

If you get this error, please follow these instructions:

1. Make sure all CDK modules in your package.json file have the exact same version.
2. Nuke your local node_modules
3. Run npm install (or yarn install).

---

See #542

Reproduction Steps

1. Utilize any two separate versions of a @aws-cdk/* package. I suspect the source of error is if any two separate files are used when pulling the source or definition of the Construct class. Typically, this has been remarked as an item of two separate @aws-cdk/* package versions in your package.json OR due to a package version range specified in package.json where the team has updated the package version recently. I'll introduce a new suspected cause in my notes.

2. Upon running TSC when utilizing constructing any Construct utilizing two separate versions of the Construct file (even if they syntactically 100% the exact same contents), the referenced error will occur: Argument of type 'this' is not assignable to parameter of type 'Construct'.

Note: This refers to the usage of new SomeConstruct(someConstructReference, ...) where SomeConstruct references some different source file for defining Construct vs. what someConstructReference references for its definition of Construct, even if the two source files are 100% identical.

Environment

• CLI Version : 1.30
• Framework Version: 1.30
• OS : Windows
• Language : TypeScript

Other

We had decent luck resolving these issues due to errors relating to mismatched versions. This breaks, however, when utilizing some package depending on CDK as a global since the dependencies of the global (i.e. some different CDK file defining Construct) are not installed into the dependee module (i.e. a file that ultimately depends on some other CDK file defining Construct).

Please see this: https://www.sitepoint.com/solve-global-npm-module-dependency-problem/

I have an idea to resolve, will post a follow-up if this yields luck. Suggest dropping a note into your docs regarding any team trying to build a global module that depends on CDK (where dependees also depend on CDK in some way).

---

This is :bug: Bug Report

[eladb]

Thanks for reporting this! We are well aware that this is still a major issue in consuming the CDK and publishing modules, and working hard to solve it.

See https://github.com/aws/aws-cdk-rfcs/pull/122

[mikegwhit]

So steps I took last week included installing a local dependency to build types, then running the binary from a global context. This was less than ideal for a different set of reasons. Basically, given the model of A depends on B depends on CDK (A->B->CDK), the following occurred:

• ✔️ could compile A via TypeScript because all definitions of CDK were installed locally via B
• ✔️ could run global executable B because B was also installed globally
• ❌ ran into lots of issues because when A imported some B file, there were different class objects referenced for B where some were the B (local) and some were the B (global) objects.

Settled on using NPX to run an executable B package locally (explicitly not installing B globally). If the goal is to remove NPX, some other tricks I use include symlinking a local dependency B into the global NPM path.

My hunch is that there has to be a simple way to resolve TypeScript errors. This could be via distributing definition files, but I really don't know TypeScript well enough to comment.

I can take a look at RFCs #122 as I might have remarks about monolithic repositories as I maintain a tool in this space.

[mattiLeBlanc]

I assume I am seeing the same issue:

Argument of type 'this' is not assignable to parameter of type 'Construct'.
  Type 'DynamoDbConstruct' is not assignable to type 'Construct'.
    Property 'onValidate' is protected but type 'Construct' is not a class derived from 'Construct'.t

where

export class DynamoDbConstruct extends Construct {
...
const dynamoDBTable = new Table(this, `Table`, {
...

The typescript error is highlighted on the this param in the Table constructor.

I am running

    "@aws-cdk/aws-dynamodb": "^1.36.0",
    "@aws-cdk/core": "^1.32.2",

When I downgrade @aws-dynamodb to 1.32.2 the type error disappears.

*update: same happens for @aws-cdk/[email protected] in combination with CDK/core 1.32.2. So my guess is that typing changed for the Constructs and those versions are out of sync? However, right now Core 1.32.2 seems to be the latest available.

[mattiLeBlanc]

@aws/core 1.36.1 is now available and resolves the type issues.

[spuds51]

Hi,

I am using cdk v1.36.1 .. seeing the following from a npm (v6.14.4) run build cmd on amazon linux instance (is there a linux version of this issue?) ..

[email protected] build /home/ec2-user/environment/RecordsApp
tsc

lib/records_service.ts:15:37 - error TS2345: Argument of type 'this' is not assignable to parameter of type 'Construct'.
Type 'RecordsService' is not assignable to type 'Construct'.
Property 'onValidate' is protected but type 'Construct' is not a class derived from 'Construct'.

15 const lambdaRole = new iam.Role(this, 'AuroraServerlessBlogLambdaRole', {
~~~~

lib/records_service.ts:23:41 - error TS2345: Argument of type 'this' is not assignable to parameter of type 'Construct'.

23 const handler = new lambda.Function(this, "RecordsHandler", {
~~~~

lib/records_service.ts:35:40 - error TS2345: Argument of type 'this' is not assignable to parameter of type 'Construct'.

35 const api = new apigateway.RestApi(this, "records-api", {
~~~~

Found 3 errors.

[maxpaj]

I'm getting this too.

Here are my packages.
```
"devDependencies": {
"@aws-cdk/assert": "^1.42.0",
"@types/jest": "^25.2.1",
"@types/node": "10.17.5",
"aws-cdk": "^1.42.0",
"jest": "^25.5.0",
"ts-jest": "^25.3.1",
"ts-node": "^8.1.0",
"typescript": "~3.7.2"
},
"dependencies": {
"@aws-cdk/aws-certificatemanager": "^1.42.0",
"@aws-cdk/aws-cloudfront": "^1.42.0",
"@aws-cdk/aws-iam": "^1.42.0",
"@aws-cdk/aws-s3": "^1.42.0",
"@aws-cdk/core": "^1.42.0",
"source-map-support": "^0.5.16"
}

[hoegertn]

@maxpaj you should always pin your CDK versions to exactly one version and not use the caret ^.

[eladb]

Added instructions in issue description and closing for now. This will be addressed systemically in v2.0