Private Member Minification Design Proposal
See original GitHub issueProblem: For front end data binding frameworks such as Angular, Knockout, React, etc, making the choice to use typescript results in larger minified output files.
Proposal: Add a tsconfig option “minifyPrivateMembers” (default false)
Details:
Since front end binding frameworks can have references to members in html, we cannot easily minify these members using existing tooling. For example, using google closure compiler would require using an externs file for all the public properties I want to keep. That would be awful to hand maintain. It’d be really nice if typescript could just minify anything marked private. Typescript wouldn’t even have to minify anything else, uglify can do the rest.
Edit: removed incorrect example.
Minification of private members in the greeter example is 18% better than minification in javascript only. I also expect many classes would have many more private members than public members, so savings could be much greater than 18%. Actually with many custom knockout bindingHandlers almost every single member can be made private!
this["greeting"]
var x = "gr" + "eeting";
var y = this[x];
If typescript notices that a class is using string access with variable strings to its own members it could choose to not minify private members for that class. Alternatively if this feature just breaks code like that then I think that’s okay as long as it’s documented. It will already break external use of private members, and that’s why the option defaults to false.
Created from here: https://github.com/Microsoft/TypeScript/issues/8#issuecomment-303423733
Issue Analytics
- State:
- Created 6 years ago
- Reactions:47
- Comments:23 (3 by maintainers)
This is absolutely a problem that the TypeScript team needs to address and not try to shift responsibility entirely to Javascript post-processors. The transformation is best done during compilation, when you have information about the source available, instead of having to guess at it from emitted magic comments or name formatting. Bottom line is, we do not want the private members of a base class to stop the declaration of a field with the same name in a derived class. After all, private members should only be accessed from inside the class itself. One easy way to generate these private names would be to find the depth of the class hierarchy up to that point and prefix the emitted private names with a number of prefix characters equal to depth, e.g.
would result in a generated class C like
This would still leave the private fields human-readable (if only prefixed), non-clashing, source-mappable and targetable from an external tool via regex (matching
_+\$
in this case).Edit: an alternative that is smaller:
<prefix><depth><suffix><varname>
:targetable with
_\d+\$
@kitsonk,
Why would you want to impose the underscore convention on anyone? It’s outdated and ugly. That’s the reason we have a
private
keyword.