Microsoft/TypeScript
Auf GitHub ansehenError span incorrect when `this` constraint on member function fails
Open
#60.709 geöffnet am 7. Dez. 2024
Domain: Related Error SpansHelp WantedPossible Improvement
Repository-Metriken
- Stars
- (48.455 Stars)
- PR-Merge-Metriken
- (Durchschn. Merge 6T 17h) (9 gemergte PRs in 30 T)
Beschreibung
🔎 Search Terms
- error span
this: never- this chain
- builder pattern
🕗 Version & Regression Information
- This is the behavior in every version I tried (including the latest 5.7.2)
⏯ Playground Link
💻 Code
/**
* Member function based case
*/
class FunctionBasedBuilder<Step extends number=1> {
step1(this: Step extends 1 ? this : never): FunctionBasedBuilder<2> {
return this as any;
}
step2(this: Step extends 2 ? this : never): FunctionBasedBuilder<3> {
return this as any;
}
// skip step 3 explicitly to demonstrate the error
step4(this: Step extends 4 ? this : never): FunctionBasedBuilder<5> {
return this as any;
}
}
/**
* Member variable based case
*/
class VariableBasedBuilder<Step extends number=1> {
step1: (Step extends 1 ? () => VariableBasedBuilder<2> : never) = (() => {
return this as any;
}) as any;
step2: (Step extends 2 ? () => VariableBasedBuilder<3> : never) = (() => {
return this as any;
}) as any;
// skip step 3 explicitly to demonstrate the error
step4: (Step extends 4 ? () => VariableBasedBuilder<5> : never) = (() => {
return this as any;
}) as any;
}
const funcBuilder = new FunctionBasedBuilder();
// all of `foo.step1().step2()` turns into an unhelpful error message
funcBuilder.step1().step2().step4();
const varBuilder = new VariableBasedBuilder();
// the error properly appears only on step 4
varBuilder.step1().step2().step4();
🙁 Actual behavior
In the function case, the entire span from foo.step1().step2() gets marked as an error instead of only step4() which is what actually caused the error
🙂 Expected behavior
Just like in the member variable case, it would be better if the error was shown on step4()
Additional information about the issue
I think this ends up being equivalent to #28159 so I'm not sure it can be solved without introducing the "curse" mentioned in #60140