Option to report errors enabled by `useDefineForClassFields`, but still transpile using assignment semantics

🔍 Search Terms

"useDefineForClassFields", "class fields errors"

✅ 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

Add an option to have TSC generate the same errors it currently generates for useDefineForClassFields = True, but while still continuing to transpile fields using the non-spec-compliant assignment semantics.

📃 Motivating Example

We must run TS with useDefineForClassFields = false, because we find the output code size of define semantics unacceptably large.

We want to be certain that our code continues to behave the same way when we are able to ship this code to environments that understand class fields without transpilation.

We want to eliminate from our code base all cases where field definitions behave differently between the 2 semantics, and then prevent them from ever returning.

To do this, it would be extremely helpful if TSC could report errors for code that would behave differently with define semantics, but also continue transpiling with assign semantics.

💻 Use Cases

1. What do you want to use this for?
2. What shortcomings exist with current approaches?
3. What workarounds are you using in the meantime?

For 1:

see the Motivating Example.

For 2 & 3:

The only workaround I know of is to run TSC twice with different options, once for the output we want and once for the errors we want. This is prohibitively expensive to do at scale.

Start by reviewing the existing useDefineForClassFields compiler option and the two class-field emit modes described in the issue. Compare the diagnostics produced with define semantics against assignment-semantic output, then identify how a separate checking option could preserve those diagnostics without changing emitted JavaScript; no file or test is named, so completion would require adding coverage for both modes.