-
Notifications
You must be signed in to change notification settings - Fork 245
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
Labels
bug
This issue is a bug.
closed-for-staleness
effort/medium
Medium work item – a couple days of effort
p1
Comments
RomainMuller
added
bug
This issue is a bug.
effort/medium
Medium work item – a couple days of effort
p1
labels
Jul 29, 2020
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*
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*
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
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
🐛 Bug Report
Affected Languages
TypeScript
orJavascript
Python
Java
C#
,F#
, ...)General Information
1.9.0
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:
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):These are misleading:
@internal
, and it quite likely should have (the user expressly states this type is not part of the public API fo 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).
The text was updated successfully, but these errors were encountered: