Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

"Property 'assetParameters' implicitly has type 'any'" error #5497

Closed
NGL321 opened this issue Dec 20, 2019 · 6 comments
Closed

"Property 'assetParameters' implicitly has type 'any'" error #5497

NGL321 opened this issue Dec 20, 2019 · 6 comments
Assignees
Labels
closed-for-staleness This issue was automatically closed because it hadn't received any attention in a while. management/tracking Issues that track a subject or multiple issues third-party This issue is related to third-party libraries or applications.

Comments

@NGL321
Copy link
Contributor

NGL321 commented Dec 20, 2019

Typescript 3.6 had a bug where the noImplicitAny check would incorrectly be performed on private ambient private getters (such as assetParameters()).

This was tracked by our jsii issue #994, and resolved in Typescript PR #33896.

This issue no longer exists in Typescript >3.7.

However, for users using both Typescript <3.7 who have noImplicitAny: true in their tsconfig.json file (set to true in CDK 1.19.0), npm run build will result in the error:

node_modules/@aws-cdk/core/lib/stack.d.ts:425:17 - error TS7033: Property 'assetParameters' implicitly has type 'any', because its get accessor lacks a return type annotation.

425     private get assetParameters();
                    ~~~~~~~~~~~~~~~

This can be resolved by updating the typescript dependency to >=3.7 OR through either of the following workarounds in the tsconfig.json file:

noImplicitAny: true,  =>  noImplicitAny: false,

OR

+ skipLibCheck: true,
@NGL321 NGL321 added management/tracking Issues that track a subject or multiple issues third-party This issue is related to third-party libraries or applications. labels Dec 20, 2019
@NGL321 NGL321 pinned this issue Dec 20, 2019
@bo67192
Copy link

bo67192 commented Jan 8, 2020

I don't have much typescript experience, would it be reasonable to add a dependency to the core module for typescript ^3.7?

That way at least builds would throw an error if they're on the wrong version

@skinny85
Copy link
Contributor

skinny85 commented Jan 8, 2020

I don't have much typescript experience, would it be reasonable to add a dependency to the core module for typescript ^3.7?

That way at least builds would throw an error if they're on the wrong version

The thing is, you can also work around it by changing noImplicitAny: true to false in tsconfig.json, so throwing an error here would be a little too harsh.

@bo67192
Copy link

bo67192 commented Jan 8, 2020

@skinny85 fair enough.

Is there any better way of letting users know they should double check for this? Maybe in the release notes? We've stumbled into it in two projects so far.

@skinny85
Copy link
Contributor

skinny85 commented Jan 8, 2020

Not really :( unfortunately, we missed this change when we released it, that's why it's not in the release notes, and hence this pinned issue.

@ghost
Copy link

ghost commented Nov 11, 2020

I had a similar error
changing noImplicitAny: true to false in tsconfig.json
delete node_modules folder
run
npm i
next step restart the vscode to effect the changes

@github-actions
Copy link

This issue has not received any attention in 1 year. If you want to keep this issue open, please leave a comment below and auto-close will be canceled.

@github-actions github-actions bot added closing-soon This issue will automatically close in 4 days unless further comments are made. closed-for-staleness This issue was automatically closed because it hadn't received any attention in a while. and removed closing-soon This issue will automatically close in 4 days unless further comments are made. labels Nov 11, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
closed-for-staleness This issue was automatically closed because it hadn't received any attention in a while. management/tracking Issues that track a subject or multiple issues third-party This issue is related to third-party libraries or applications.
Projects
None yet
Development

No branches or pull requests

3 participants