Is it possible to move an abstract base classes / base interface into a private module

[shivlaks]

❓ Guidance

Affected Languages

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

General Information

• JSII Version: 1.13.0
• Platform:: OS X

The Question

It's common within a CDK construct library to have an abstract class that is not exported and only concrete implementations are exported.

When attempting to move the base class to it's own file in aws/aws-cdk#10925, JSII hits me with a warning
during build time that precludes the ability to move it to a folder such as .private

The desired outcome is a better organization of code where each concrete implementation has it's own file.
Similarly, if there is a props interface that the concrete implementations extend from, the same error message is presented.

The error message indicates that this may be by design. Is this a limitation that can be remediated or is it fundamentally required that classes be structured where the base class is in the same file as concrete implementations?

Error Message:

Unable to resolve type "@aws-cdk/aws-cognito.UserPoolIdentityProviderBase". It may be @iternal or not exported from the module's entry point (as configured in "package.json" as "main").

[RomainMuller]

Basically, jsii is unable to determine whether you decided/meant not to export this type from your module, or whether you forgot to export it. This could result in weird API breakage if you later realize your error and fix that, so jsii prefers to complain rather than ignore.

What you are trying to doc should be achievable by annotating your "private" types as /** @internal */, which is the way jsii is notified that you intended for this declaration not to be visible outside of the module.

[RomainMuller]

This is a duplicate of #1980 -- the main thing here is the error message is bad. This needs to be improved.

[github-actions]

⚠️COMMENT VISIBILITY WARNING⚠️

Comments on closed issues are hard for our team to see.
If you need more assistance, please either tag a team member or open a new issue that references this one.
If you wish to keep having a conversation with other community members under this issue feel free to do so.

[shivlaks]

@RomainMuller when I added @internal initially, the yarn package step still produced the base class in the generated code packages. I'll revisit it now, is there a better / more correct way to verify that the intended behaviour is still achieved?