Repository navigation
TypeScript fails to detect self-reference issue in "Parameter Properties" of constructors #62414
Description
🔎 Search Terms
- private property self reference
- private property self reference constructor
- Parameter Properties constructor self reference
🕗 Version & Regression Information
- This is reproducible at least between v4.9.5 and nightly -- I have not tried earlier versions
⏯ Playground Link
💻 Code
import { join as _f } from 'node:path';
abstract class MyClassBase {
// this will cause issue in g()!
constructor (private f: typeof _f = f) {
}
g (...args: string[]) {
return this.f(...args);
}
/* // this does not work, however
myFun (f: typeof _f = f) {
f();
}*/
}
class NewClass extends MyClassBase {
join (...args: string[]) {
this.g(...args);
}
}
const c = new NewClass();
console.log(c.join('a', 'b', 'c')); 🙁 Actual behavior
TypeScript compiler does not report any errors.
if you copy transpiled JS file and run that with Node.js, you will see
constructor(f = f) {
^
ReferenceError: Cannot access 'f' before initialization
🙂 Expected behavior
TypeScript clearly shows an error, similar to what would have been seen in regular function parameters
Parameter 'f' cannot reference itself.
Additional information about the issue
The issue originated from this -- microsoft/vscode-js-debug-browsers#19, and I just discovered that the issue in the project or TypeScript has never been fixed. If someone at Microsoft could do a favor and ping the maintainer of that repo as well, it will be much appreciated.
Reacted by Ryan Cavanaugh
Activity
mag123c commentedon Sep 9, 2025
The root cause is that parameter property self-reference checks are missing in the type checker.
I'll create a draft PR with a fix that adds detection in
checkParameterfor parameter properties with initializers.mag123c commentedon Sep 10, 2025
I really want to try and help fix this issue.
After studying the code more, I think the problem might be that parameter properties have two symbols (parameter + property), and the existing self-reference check might need to handle both.
Would it be the right direction to extend the existing check in
onSuccessfullyResolvedSymbolinstead of adding a new check incheckParameter?I apologize for my previous inadequate PR. I'm eager to learn and contribute properly. Any guidance would be greatly appreciated.
Thank you for your patience with a first-time contributor