-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
Don’t enforce export/declare overload modifier consistency across module augmentations #59416
Conversation
…ule augmentations
@typescript-bot test it |
Hey @andrewbranch, the results of running the DT tests are ready. Everything looks the same! |
@andrewbranch Here are the results of running the user tests with tsc comparing Everything looks good! |
I feel like I don't have a good understanding of the old behavior to be able to assess the new one. Why was the old behavior in place? What are the bad scenarios we're trying to avoid, exactly? |
@andrewbranch Here they are:
tscComparison Report - baseline..pr
System info unknown
Hosts
Scenarios
Developer Information: |
Stating my understanding, but I might have some of the details wrong. AFAIK, overloads are additional declarations of the same method/function symbol. Since there’s ultimately only one merged symbol, all these modifiers necessarily apply uniformly to the symbol. We don’t really have mechanisms in place to reason about what it would mean for some signatures to be exported while others aren’t. And the presence or absence of export function foo(x: T1): T2;
export function foo(x: T3): T4;
function foo(x: T5): T6;
export function foo(x: any): any {
// ...
} looks like it might make the third overload file-local, but there’s actually nothing in place to make that happen, so we want to enforce consistency in the modifiers. |
@andrewbranch Here are the results of running the top 400 repos with tsc comparing Everything looks good! |
Fixes #58756
These rules are only there because it looks confusing to have overload declarations like
But if the overloads came from a module augmentation, it's reasonable for them to have different modifiers (see code comment and tests for the differences that are allowed).