"Exported APIs cannot use un-exported type", even though the type IS exported #1818
Comments
udondan
added
bug
|
Turns out the issue is with how you use Basically, the TypeScript compiler does not report the Thankfully, it looks like a trivial fix! |
|
Indeed, I've just figured out the other exports are not available in the Python, Nuget, Maven packages. I was just experimenting with the export definitions. |
|
I'm preparing a PR with a fix that'll make the There's a secondary issue here which is a little trickier... those types you are not exporting from the module's entry point ( |
When specific symbols are exported from a module using the
*ExportDeclaration* syntax:
```ts
export { Foo } from './foo';
```
Those declarations would not be processed at all, because they lack the
`ts.ModifierFlags.Export` modifier (which is to be expected from a
declaration that **is** an export statement).
Added the necessary code (and a test) to ensure these statements are
correctly detected, and the exported symbols are correctly processed
into the output assembly.
Fixes #1818
|
Thanks Romain, that's super helpful. I was preparing a PR on my end with |
|
Yeah - I've been thinking that I'd want the So basically at this point I reckon the error message you'd be getting is awkward and possibly needs improving - but I'm not too sure how to make it relevant & actionnable. I was looking to improve the locality of the source reference of it, too (this usually helps improve actionability of the error message) - but it turns out to be tricky enough that I don't want to commingle in #1829. |
RomainMuller
added
p1
module/compiler
|
Looks like i have a billion issues like method names not allowed by jsii... I think I have to change the complete API of the package. 😆 I tried to set the Anyway, I'll wait for your PR getting merged then, so I can keep my export statements the way I had them. Maybe this now comes from the |
When specific symbols are exported from a module using the
*ExportDeclaration* syntax:
```ts
export { Foo } from './foo';
```
Those declarations would not be processed at all, because they lack the
`ts.ModifierFlags.Export` modifier (which is to be expected from a
declaration that **is** an export statement).
Added the necessary code (and a test) to ensure these statements are
correctly detected, and the exported symbols are correctly processed
into the output assembly.
Fixes #1818
---
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
|
Thanks @RomainMuller - I tested this today 👍 |
|
This issue seems to have cropped back up for me despite using versions of JSII well past when the fix was introduced Given the following directory structure: And the following export statements: I get this error: |
|
@icj217 were you able to fix this? I got a similar issue for cdk8s |
|
@ganeshgk I was not. I ended up doing a |
🐛 Bug Report
General Information
What is the problem?
I'm having trouble building a package with multiple exports that depend on one another. One exported class uses another one of the same package. Both classes are exported. JSII though fails with Exported APIs cannot use un-exported type.
For code reference I point to my PR of iam-floyd where I'm facing this problem https://github.com/udondan/iam-floyd/pull/22/files
My package index looks like this:
The
./generatedsub-package (do you actually call it like that?) has an export Ec2.The
./collectionsub-package uses this Ec2 Class.Now when running jsii it complains about Ec2 not being exported:
I also tried to:
import {Ec2} from '../generated/amazonec2'export { Ec2 } from './generated';All the same.
Verbose Log
Now here's the interesting thing. If I remove the export of
Collectionfrom theindex.tsfile, it runs through, but the verbose output looks like this:Even though the
index.tscontains more exports, I do not see them mentioned at all. To me this looks like something is wrong with detecting the other exports. Though the resulting package works and is perfectly usable. We're using the published package in the latest version w/o issues.The text was updated successfully, but these errors were encountered: