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

[jsii] Confusing error message when using internal types in exported declarations #1830

Closed
1 of 4 tasks
RomainMuller opened this issue Jul 29, 2020 · 1 comment
Closed
1 of 4 tasks
Labels
bug This issue is a bug. closed-for-staleness effort/medium Medium work item – a couple days of effort p1

Comments

@RomainMuller
Copy link
Contributor

🐛 Bug Report

Affected Languages

  • TypeScript or Javascript
  • Python
  • Java
  • .NET (C#, F#, ...)

General Information

  • JSII Version: 1.9.0
  • Platform: any

What is the problem?

It can be useful to have internal base types that are intentionally not exported out of the module. In many cases, developers want to organize their code in such a way that those types are internally exported within the module, but not from the module's entry point:

  • Declaring these types in private files, unexpected from the index
  • Declaring these types in public files, but only exporting specific symbols in the index (using export { ... } from "...";)

When such a type is extended/implemented, the jsii compiler does not automatically erase those (as it would for un-exported types, or those documented as @internal), and instead produces the following errors (see #1818 for more context of this particular one):

lib/shared/policy-statement/9-final.ts:6:1 - error TS9999: JSII: Unable to resolve referenced type 'iam-floyd.PolicyStatement'. Type may be @internal or unexported

  6 export class PolicyStatement extends PolicyStatementWithPrincipal {
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  7   protected cdkApplied = false; // internally used to check if resources, actions and conditions have already been applied to the policy
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
... 
 15   }
    ~~~
 16 }
    ~
lib/generated/awsdeeplens.ts:8:1 - error TS9999: JSII: Unable to resolve referenced type 'iam-floyd.PolicyStatement'. Type may be @internal or unexported

  8 export class Deeplens extends PolicyStatement {
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  9   public servicePrefix = 'deeplens';
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
... 
514   }
    ~~~
515 }
    ~

These are misleading:

  • The declaration is not marked @internal, and it quite likely should have (the user expressly states this type is not part of the public API fo the module)
  • The declaration is (locally) exported, however it is not exported from the module

This error needs to be enhanced in order to improve the actionability of it (clarify the problem and highlight possible solutions). Additionally, it would be useful if the locality of the error would be enhanced (so the specific usage site for the declaration is flagged, instead of the whole referenced or referencing type).

@RomainMuller RomainMuller added bug This issue is a bug. effort/medium Medium work item – a couple days of effort p1 labels Jul 29, 2020
@RomainMuller RomainMuller self-assigned this Jul 29, 2020
@RomainMuller RomainMuller changed the title [jsii] Confusing error message when using internal types [jsii] Confusing error message when using internal types in exported declarations Jul 29, 2020
mergify bot pushed a commit that referenced this issue Oct 23, 2020
…wnstream (#2172)

Stop setting `stipInternal: true` in `tsconfig.json` files, as this makes it impossible
to mark intentionally unexported types as `@internal` without causing downstream
compilation failures due to missing type declarations.

Fixes #1947
Related to #1830 

---

By submitting this pull request, I confirm that my contribution is made under the terms of the [Apache 2.0 license].

[Apache 2.0 license]: https://www.apache.org/licenses/LICENSE-2.0
nija-at pushed a commit to aws/aws-cdk that referenced this issue Oct 29, 2020
This reverts commit 65be3a0.
Original PR: #10531
Co-authored-by: Ayush Goyal <goyalayu@amazon.com>

This commit was previously reverted due to a bug in jsii - aws/jsii#1947
and aws/jsii#1830. This has been fixed in jsii version 1.14.0.
mergify bot pushed a commit to aws/aws-cdk that referenced this issue Oct 30, 2020
This reverts commit 65be3a0.
Original PR: #10531
Co-authored-by: Ayush Goyal <goyalayu@amazon.com>
relates #10119

This commit was previously reverted due to a bug in jsii - aws/jsii#1947
and aws/jsii#1830. This has been fixed in jsii version 1.14.0.

----

*By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
@RomainMuller RomainMuller removed their assignment Jun 24, 2021
eladb pushed a commit to cdklabs/decdk that referenced this issue Jan 18, 2022
This reverts commit 4641fd47a464ea20f5536c0d58cfb8f24f9698fe.
Original PR: #10531
Co-authored-by: Ayush Goyal <goyalayu@amazon.com>
relates #10119

This commit was previously reverted due to a bug in jsii - aws/jsii#1947
and aws/jsii#1830. This has been fixed in jsii version 1.14.0.

----

*By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
@github-actions
Copy link
Contributor

This issue has not received any attention in 2 years. 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 and removed closing-soon This issue will automatically close in 4 days unless further comments are made. labels Jun 25, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug This issue is a bug. closed-for-staleness effort/medium Medium work item – a couple days of effort p1
Projects
None yet
Development

No branches or pull requests

1 participant