Add a flag to require JS object literals to be initialized with all declared members

I'm aware JavaScript files work somewhat differently from TypeScript files, so I'm assuming this behavior is intentional. But if not, feel free to consider this as a bug instead.

🔍 Search Terms

empty object label:"Domain: JavaScript"

✅ 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

In JavaScript files it is possible to assign an empty object to a variable, as long as you provide it with the expected properties later:

/**
 * @typedef Foo
 * @property {string} hello
 */

/** @type {Foo} */
const x = {};
x.hello = "hello";

But this can cause all sorts of issues later down the line. In .ts files this is not an issue because this behavior immediately emits an error when assigning the empty object.
It would be nice to have a new compiler option that makes this behaviour more strict, similar to the current behavior in .ts files.

📃 Motivating Example

Consider the following code:

/**
 * @typedef Foo
 * @property {string} myCoolString
 */

/** @type {Foo} */
let x = {};

x.myCoolString.split(","); // Cannot read properties of undefined!

x.myCoolString = "hello";

TypeScript acts as if there is nothing wrong with this, but when running this, you'll end up with an error when trying to use x.myCoolString before it's been assigned.

Perhaps an even more subtle situation would be where you forget to assign one of your properties:

/**
 * @typedef Foo
 * @property {string} str1
 * @property {string} str2
 */

/** @type {Foo} */
let x = {};
x.str1 = "hello";

x.str2.split(","); // Cannot read properties of undefined!

In this case, it's easy to imagine a scenario where you add a new @property to the @typedef comment, expecting TypeScript to warn you about all cases in your codebase where you may be creating new objects. But in reality, if you are using dot notation anywhere in your codebase to create Foo, then you'll be out of luck.

💻 Use Cases

Stricter type checking!

The issue provides JavaScript examples using JSDoc typedefs and typed empty object literals; review the compiler's JavaScript type-checking and object-literal assignability behavior first. The payload names no files or tests. Done means an opt-in flag reports missing declared members in these patterns without changing emitted JavaScript.