[suggest] constructor init delegation with "strictPropertyInitialization"

[jonlepage]

🔍 Search Terms

strictPropertyInitialization, Property has no initializer and is not definitely assigned in the constructor.

✅ Viability Checklist

• This wouldn't be a breaking change in existing TypeScript/JavaScript code
• This wouldn't change the runtime behavior of existing JavaScript code
• This could be implemented without emitting different JS based on the types of the expressions
• This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
• This isn't a request to add a new utility type: https://github.com/microsoft/TypeScript/wiki/No-New-Utility-Types
• This feature would agree with the rest of our Design Goals: https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals

⭐ Suggestion

Hello, have you ever considered adding a special hack to delegate the role of a class constructor when using strictPropertyInitialization: true in the tsconfig file?

In fact, I have an issue with an architecture that makes the constructor unnecessary until the class is injected into a facade that activates the system and creates the private dependencies of the class.

There is no other solution except to disable this rule, which is frankly not great and very limiting when a project uses several design patterns requiring a distinct approach.
To take advantage of the security of strictPropertyInitialization, would it be possible to have maybe a special utility type that tells TypeScript to check this method instead of the constructor?

Here are 3 examples that could potentially be good solutions:
I personally prefer examples 2 and 3.
The first example can bring more complexity

---

📃 Motivating Example

Suggest 1: method with special type

We add methodname( this:ThisConstructor )

class SystemA {
	public readonly instanceNeedDependancyAvaibleLater: object; // Property 'instanceNeedDependancyAvaibleLater' has no initializer and is not definitely assigned in the constructor.

	constructor() {
	}

	// ThisConstructor can be a special type flag thas tell to tsserveur with "strictPropertyInitialization" to ignore the constructor and scan asignation in this method instead
	init( this:ThisConstructor ) {
		this.instanceNeedDependancyAvaibleLater = {};
	}
}

issues:

• can add complexity
• can add perf issue with ts (need scan all method)

---

Suggest 2: detect with illegal this in constructor.
It is currently illegal to use "this" in the constructor.
We could take this opportunity to tell ts to check another methods for props initialisation.
I using "string" here, but is juste for give the idea.

class SystemA {
	public readonly instanceNeedDependancyAvaibleLater: object; // Property 'instanceNeedDependancyAvaibleLater' has no initializer and is not definitely assigned in the constructor.

	//  this:'methodName' can maybe tell ts to find this method and scan assignation instead use this constructor
	constructor( this:'init' ) {
	}

	init( ) {
		this.instanceNeedDependancyAvaibleLater = {};
	}
}

issues:

• will maybe not work with protected and private method based ont how ts work
• rename or security issue if using "string", ts will need index the token or suggest types

---

Suggest 3: using comment

class SystemA {
	public readonly instanceNeedDependancyAvaibleLater: object; // Property 'instanceNeedDependancyAvaibleLater' has no initializer and is not definitely assigned in the constructor.

	//  using a comment flag to scan .init method instead of constructor
	//@ts-strictPropertyInitialization {SystemA.prototype.init}
	constructor( ) {
	}

	init( ) {
		this.instanceNeedDependancyAvaibleLater = {};
	}
}

issues:

• will maybe not work with protected and private method based ont how ts work
• not read friendly

---

💻 Use Cases

1. What do you want to use this for?
   This is to address the need for an architecture that requires initialization after adding a loosely coupled facade.
   The idea is to maintain the security of declarations, which current solutions do not allow.
   This approach can also open the door to design patterns that are difficult to manage with TypeScript.

2. What shortcomings exist with current approaches?
   Currently, there are various tricks that do not allow to maintain the security and philosophy of TypeScript.
   1: //@ts-ignore
   2: public props!:object
   3: strictPropertyInitialization:false

3. What workarounds are you using in the meantime?
   public props!:object

[jcalz]

Is this just like an opt-in version of #32194 and #30462?