Skip to content
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

Look into using api-extractor to control exports' visibility #1131

Open
unflxw opened this issue Sep 19, 2024 · 1 comment
Open

Look into using api-extractor to control exports' visibility #1131

unflxw opened this issue Sep 19, 2024 · 1 comment
Labels

Comments

@unflxw
Copy link
Contributor

unflxw commented Sep 19, 2024

In #1130 we use the stripInternal config option and /** @internal */ JSDoc comments to control which symbols are exported by the TypeScript compiler into .d.ts files, which in turn controls what TypeScript-enabled editors will suggest for autocompletions.

This is quite error-prone, since as @tombruijn pointed out (#1130 (review)) the compiler does not validate that the resulting set of .d.ts files is valid -- that is, some type definitions in one file might reference type definitions in another file that have been stripped out, causing the TypeScript compiler to error when handling its type definitions.

In our setup, this failure mode is mitigated somewhat by our integration tests, which attempt to compile TypeScript projects that use these definitions, failing the build if this compilation fails. Still, it might be worth looking into api-extractor, as recommended by the TypeScript documentation, which seems to be a Microsoft-backed solution for this problem space.

@backlog-helper
Copy link

backlog-helper bot commented Sep 19, 2024

✔️ All good!

New issue guide | Backlog management | Rules | Feedback

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants