🔎 Search Terms
nested constructors type resolution anti-pattern
🕗 Version & Regression Information
- This changed between versions ______ and _______
- This changed in commit or PR _______
- This is the behavior in every version I tried, and I reviewed the FAQ for entries about _________
- I was unable to test this on prior versions because I only report bugs to be helpful, but I don't have time to dive deeper myself.
⏯ Playground Link
https://www.typescriptlang.org/play/?#code/KYDwDg9gTgLgBAE2AYwDYEMrDsiA7AZ3gCF0DgAuOAbwCgBIPYAdwAoBKKu++gawEs8CKgHIAgiIaMWHLnAFDRxEXAC+DdetyF4YuAF44TZjgwECcUDGBCLpcjTW1tROMQNGWpshas2EFnrUTsQAdAoIQA
💻 Code
export declare const Base: {
new(): {
kind: 'A'
new(): { kind: 'B' }
}
}
const A = new class extends Base { }
const B = new class extends A { }
B.kind // shows 'A', but should be 'B'
🙁 Actual behavior
If a ctor returns another ctor, it repeats the first level. In the above example, B.kind is 'A', but since we extended and instantiated twice, it should be 'B'.
🙂 Expected behavior
After extending twice, it should reach the inner class, instead of repeating the outer one.
Additional information about the issue
I can only reproduce this bug with this weird experimental anti-pattern - so on its own probably not a priority at all, but types should probably reflect the runtime state as much as possible, even in weird edge cases such as this, and it might indicate a deeper underlying issue.
🔎 Search Terms
nested constructors type resolution anti-pattern
🕗 Version & Regression Information
⏯ Playground Link
https://www.typescriptlang.org/play/?#code/KYDwDg9gTgLgBAE2AYwDYEMrDsiA7AZ3gCF0DgAuOAbwCgBIPYAdwAoBKKu++gawEs8CKgHIAgiIaMWHLnAFDRxEXAC+DdetyF4YuAF44TZjgwECcUDGBCLpcjTW1tROMQNGWpshas2EFnrUTsQAdAoIQA
💻 Code
🙁 Actual behavior
If a ctor returns another ctor, it repeats the first level. In the above example, B.kind is 'A', but since we extended and instantiated twice, it should be 'B'.
🙂 Expected behavior
After extending twice, it should reach the inner class, instead of repeating the outer one.
Additional information about the issue
I can only reproduce this bug with this weird experimental anti-pattern - so on its own probably not a priority at all, but types should probably reflect the runtime state as much as possible, even in weird edge cases such as this, and it might indicate a deeper underlying issue.