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
[api-extractor] Better support for nominal types #4654
Comments
This was referenced Apr 18, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Overview
My team is currently leveraging package.json exports combined with trimmed type rollups to manage our package APIs. We have our packages configured with something like the following:
By default, consumers of our packages only see the
public
types, but we provide explicit entrypoints for ourbeta
andalpha
APIs that can be used from the same package dependency.This is extremely convenient, as we neither need to maintain multiple packages for different release scopes, nor do customers have to change dependencies to opt into experimental features.
While this pattern works fine for structurally typed exports, it breaks down for nominally typed exports.
Example Scenario
Consider the following example, the code for which can be found here:
A repository contains 2 packages with the following dependency relationship:
package-b
-depends-on->package-a
.package-a
exports the following nominally typed class:package-a
is leveraging package.json exports to surface 2 variations of its API:.
)/internal
.package-b
consumes nominally typed classFoo
, but it does so via a mix of the two export paths (this is a contrived example, but it reflects a scenario that occurs easily with more code modules).package-b
has the following code:Ideally, this would work fine - both of the rollups being leveraged refer to the same underlying type.
Unfortunately, since API-Extractor generates the rollups via redeclarations, TypeScript deems the 2 nominally typed class declarations as being incompatible.
And, in fact, the above code in
package-b
fails to build.Feature Request
Ideally, API-Extractor could surface nominally typed exports in such a way that guarantees compatibility.
A naive solution, which we have adopted internally, is to simply re-export existing declarations from the
d.ts
entrypoint API-Extractor consumes, rather than redeclaring them. It isn't immediately clear to me if such a pattern is compatible with API-Extractor's use-cases or not.Would love to hear thoughts from the maintainers on this.
The text was updated successfully, but these errors were encountered: