Compile without type declarations showing up as undefined initialisations

[mksunny1]

🔍 Search Terms

type declaration

✅ 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

I would love to see a compiler option for compiling TypeScript files with optional field declarations disappearing from the JavaScript class body. The current behaviour is for the fields to just be listed in the class body which leads to them being initialised to undefined per instance. This can lead to unnecessary memory bloat in some cases. I tried using the exactOptionalPropertyTypes compiler option but unfortunately it does not work for this scenario.

📃 Motivating Example

I am creating a reactive library using TypeScript here. An important detail about my implementation is wrapping existing objects with reactive ones. The wrapping objects have many optional fields, that should not be present at all unless they are needed to function. Typescript enforces type declarations for all members, including optional ones, so that all the properties end up getting initialised to undefined in the output JavaScript.

TS input:

class ReactiveObject {
    children?: { [key: string | number | symbol]?: any }
    props?: any;
    // ...
}

JS output:

class ReactiveObject {
    children;
    props;
    // ...
}

What I prefer:

class ReactiveObject {
    // ...
}

My current workaround is to manually comment out the optional variables after compiling, but this cannot scale in an automation environment.



### 💻 Use Cases

1. What do you want to use this for? To create a memory-efficient reactive library.
2. What shortcomings exist with current approaches? Unnecessary memory allocations
3. What workarounds are you using in the meantime? Manually editing the output JavaScript

[MartinJohns]

This is working as intended and is for compatibility with the ECMAScript standard. You can disable the behavior by turning off useDefineForClassFields.

[mksunny1]

Thanks @MartinJohns. Knew there should be something for this...