Private Member Minification Design Proposal

[mblandfo]

Problem: 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:
#8 (comment)

[emilio-martinez]

@RyanCavanaugh is this still under consideration?

Since private methods and properties are not used externally, even enforced by the compiler, I think this makes a lot of sense. In the case of use cases like Angular, for example, they enforce public methods and properties with component templates, given they're somewhat of an "external entity" to the class, so I'm use cases like that it shouldn't be a problem.

[RyanCavanaugh]

Regarding the proposed emit, it doesn't work, as described in the FAQ
https://github.com/Microsoft/TypeScript/wiki/FAQ#you-should-emit-classes-like-this-so-they-have-real-private-members

We could just rename the identifiers during emit. But this raises more problems -- anyone could derive from the emitted class and declare new members of minified name, breaking both classes at runtime. We'd have to somehow choose identifiers that are both short and unlikely to be used by anyone else, including other TypeScript programs. It's not at all clear that this is possible.

One option is if there were a way for us to signal to a minifier that certain identifiers are "safe" to minify - is this something that those tools support?

[mblandfo]

Ah, good point. It may be possible to create an "externs" file for google closure compiler based on non private members, but that should probably be a plugin or something. Or maybe a standalone program that reads javascript in html.

[harquail]

The latter approach makes a lot more sense for our use case. Currently we will put all public interfaces in separate files and use the AST to find names that are safe to minify based on that. Then, we pass that list of exceptions to UglifyJS. Having a way to emit a list of public member names that are not safe to minify (or the inverse) would greatly simplify our workflow.

This could also work via comment identifiers (similar to /** @Class */) that minifiers could use as signals for minification

[NoelAbrahams]

@RyanCavanaugh,

We'd have to somehow choose identifiers that are both short and unlikely to be used by anyone else, including other TypeScript programs. It's not at all clear that this is possible.

Making the prefix configurable would work for most cases, I'd think:

{
  "compilerOptions": {
    "target": "ESx",
   "minify": {
        "prefix": "_"
     }
}

This would generate:

 class  Foo {
    // Privates 
    _a1(){}
    _a2(){}
   ...
 }

[Palid]

Folks, is this PR dead? It'd be lovely to implement this, especially for projects/libraries using dependency injection frameworks like InversifyJS enforcing private variables everywhere. :)

[marcusbelcher]

Ditto for above, I am really in need of minifying private variable names. Is there any timings for this feature to be implemented?

[john-lemire]

@RyanCavanaugh re: "We could just rename the identifiers during emit. But this raises more problems"
Is this an intractable problem? Couldn't each class have a private member prefix either in a comment that is also discernable in the .js/d.ts or worst case a private static variable of a known name (ie _) All classes that don't extend anything could start with a value of 'a', all classes that extend from others walk the hierarchy to see what prefix their immediate ancestor used and start at 'b' or whatever the next one is. If the class doesn't extend from anything it's members can just start using a,b,c, etc. for the private member names. If the class extends from something then use the prefix followed by the a, b, c, etc. Private methods may be even easier, ie do private methods really even need to be on the prototype?
That's obviously a 4 minute solution that is so simplistic that I'm certain I'm missing many things but this minification thread has been going on for 4 years and we still don't have good solution from the ts team.
We really need the ts team to come up with something, I remain unconvinced that a multi party solution is viable. You've highlighted some of the mismatch issues with closure, others have highlighted the problems of others (ie how to keep source maps working when a post process tool starts inlining things). Like everyone else we have been forced to do the duplicate work of incorporating tools into the process, using uglify/webpack, etc. and are years later still getting unsatisfactory results.
Please, not too proud to beg, please.

[kitsonk]

If the class doesn't extend from anything it's members can just start using a,b,c, etc. for the private member names. If the class extends from something then use the prefix followed by the a, b, c, etc.

But if then the class is subsequently extended, but other code, consuming this as a library, how do you propose this works to avoid conflicts.

It still seems like this is a problem that TypeScript shouldn't be solving (can't solve). With Uglify2, you can choose to mangle "private" properties based on a RegEx.

For example, --mangle-props regex=/^_/ will only mangle property names that start with an underscore.

Isn't it better to use your mangler/minifier than to impose something upstream?