JSII3000 (unexported type) error for a type that comes from a submodule of a JSII peer dependency
- Dominant language
- TypeScript
- Stars
- 2.9k
- Forks
- 267
- Avg merge
- 1d 25m
- Merged PRs (30d)
- 14
Description
## :bug: Bug Report
### Affected Languages
- [x] `TypeScript` or `Javascript`
- [ ] `Python`
- [ ] `Java`
- [ ] .NET (`C#`, `F#`, ...)
- [ ] `Go`
### General Information
* **JSII Version: 1.40.0 (build 9713b9d), typescript 3.9.10**
* **Platform: OS X**
### What is the problem?
With our 0.7 release of CDKTF we [switched the provider generation](https://github.com/hashicorp/terraform-cdk/pull/1101) for the AWS provider to use JSII submodules. This change brought up an issue in a custom constructs that makes use of those pre-built provider bindings:
[Exported APIs cannot use un-exported type "@pahud/cdktf-aws-eks.EKS.EksCluster"](https://github.com/hashicorp/terraform-cdk/issues/1203) (originally reported here: https://github.com/hashicorp/cdktf-provider-aws/issues/465)
When exporting the namespace like this in the pre-built AWS provider:
```
export { EKS } from './EKS';
```
instead of
```
export * from './EKS';
```
JSII can compile the custom construct.
However that also causes JSII to not treat those namespaces as submodules anymore ([related comment](https://github.com/hashicorp/terraform-cdk/pull/1212#issuecomment-951998436)) – hence I think it does not solve the underlying problem but rather rolls back the change.
So I dug a bit deeper and added a bit of logging to the [`_allTypeReferencesAreValid`](https://github.com/aws/jsii/blob/52123f772965cde8c6c7b104d0d5b193eb655523/packages/jsii/lib/validator.ts#L180) validator function.
Apparently (and as visible in the error message) the `typeRef` causing the JSII3000 error is `{ fqn: '@pahud/cdktf-aws-eks.EKS.EksCluster' }`.
I also logged all `assembly.types` known to JSII: ([full output](https://gist.github.com/ansgarm/3a230d94c73b67f59f1fce6ccb8ee6ab))
```
{
'@pahud/cdktf-aws-eks.CapacityType': {...},
'@pahud/cdktf-aws-eks.ScalingConfig': {...},
'@pahud/cdktf-aws-eks.NodeGroupOptions': {...},
'@pahud/cdktf-aws-eks.NodeGroupProps': {...},
'@pahud/cdktf-aws-eks.NodeGroup': {...},
'@pahud/cdktf-aws-eks.ClusterProps': {...},
'@pahud/cdktf-aws-eks.NodeGroupBaseOptions': {...},
'@pahud/cdktf-aws-eks.Cluster': {...},
'@pahud/cdktf-aws-eks.KubernetesVersion': {...}
}
```
And it appears that there is no namespace `@pahud/cdktf-aws-eks.EKS` and JSII somehow must be incorrectly inferring `@pahud/cdktf-aws-eks.EKS.EksCluster` for the `EKS.EksCluster` [referenced here](https://github.com/pahud/cdktf-aws-eks/blob/d3db456c85ebf568de321558b2fa86a072e7dbf6/src/cluster.ts#L122). It should probably be `@cdktf/provider-aws.EKS.EksCluster` or similar.
Could you point me to the logic that determines / resolves that name? My current suspicion is that it lacks support for submodules, but I'm only guessing here.
### Reproduction example
https://github.com/ansgarm/jsii-namespace-peer-deps
Contributor guide
Research direction
Start with packages/jsii/lib/validator.ts and the _allTypeReferencesAreValid function, then reproduce the failure using the linked jsii-namespace-peer-deps example. Trace how EKS.EksCluster is resolved and verify that the referenced type is correctly recognized without triggering JSII3000.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- typescript
- Domain
- compilers, devtools
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 32/100