-
Notifications
You must be signed in to change notification settings - Fork 592
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] [api-extractor] Incompatible release tags across package boundaries don't trigger ae-incompatible-release-tags
with bundledPackages
#4430
Comments
I am likely missing some context here, but it seems like this check here should be extracted from the outer conditional - incompatible release tags and missing exports are orthogonal and should be verified independently. |
I'm not sure about that.
Here's two rather different use cases to consider:
As with your issue #4425, perhaps we need a setting to distinguish the intent? (Should it be a separate setting?) |
Thanks for the response. Alongside your notes in #4425, I have a much better understanding of how these features were intended to compose, which didn't align with my understanding. The distinction between these two cases is a fair one. I think I agree that a setting is probably sufficient to accomplish this. But now that I better understand the intention of A single, global option might be the easiest place to start, but I could also see an argument for allowing users to specify package-name/config pairs that specify the desired level of validation. What do you think? |
@octogonz Given this, would unconditionally validating the tag compatibility when |
…e tag compatibility (#20696) Mitigation for API-Extractor [issue 4430](microsoft/rushstack#4430). The original mitigation we had in place was erroneously removed in #19939. Also fixes the handful of violations that have been introduced since that PR.
…e tag compatibility (microsoft#20696) Mitigation for API-Extractor [issue 4430](microsoft/rushstack#4430). The original mitigation we had in place was erroneously removed in Also fixes the handful of violations that have been introduced since that PR.
…e tag compatibility (#20696) (#20699) Mitigation for API-Extractor [issue 4430](microsoft/rushstack#4430). The original mitigation we had in place was erroneously removed in #19939. Also fixes the handful of violations that have been introduced since that PR. Cherry-picked from #20696
Summary
Consider the following example where a mono-repo contains 2 packages:
package-a
andpackage-b
, wherepackage-b
depends onpackage-a
and specifies it inbundledPackages
.package-a
package-b
(depends onpackage-a
)package-b
's api-extractor config contains:and
The expected outcome in this situation is that running api-extractor in
package-b
should trigger theae-incompatible-release-tags
error, but it doesn't.Note that if
Foo
is re-exported bypackage-b
, the error is triggered as expected. But sincepackage-b
specifiespackage-a
inbundledPackages
, the error should occur in either case.Repro steps
I have created a small mono-repro that is configured with a fairly minimal repro of the issue: https://github.com/Josmithr/api-extractor-playground/tree/incompatible-release-tag-bug-repro
Standard questions
Please answer these questions to help us investigate your issue more quickly:
@microsoft/api-extractor
version?node -v
)?The text was updated successfully, but these errors were encountered: