aws / aws/jsii

JSII3000 (unexported type) error for a type that comes from a submodule of a JSII peer dependency

Open
#3,095 6 comments 1 reaction 0 assignees View on GitHub
bug module/jsii p2
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

Open the contributing 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.