Inconsistent property names

[ddenisyuk]

Hello, I'm working with several third-party libraries in TypeScript, particularly those utilizing enums, and I'm facing challenges in maintaining consistent property names when using Google Closure Compiler (GCC) in advanced compilation mode.

My current understanding is that GCC, designed for whole-application optimization, tends to rename variables and object properties unless they are specified in an externs file. However, given the nature of my project involving multiple external libraries, it's impractical to manage an externs file for every potential variable or property.

I've explored a potential workaround and would like to get feedback on its viability. The idea is to modify the GCC source code to prevent the renaming of properties that have quoted usage. Specifically, updating the condition in RenameProperties.java to:
if (p != null && p.newName != null && !quotedNames.contains(oldName)) {

This modification seems to work in my initial tests, but I'm concerned about its broader implications and compatibility with GCC's optimization goals. I understand that modifying the GCC source could lead to unexpected behaviors.

Has anyone faced a similar challenge or has insights into this approach? Are there better alternatives or practices I should consider to maintain property consistency without compromising the advanced optimization features of GCC?

PS: 4 tests failing after mentions changes, but most of failed test are expected "incorrect" behavior. For example IntegrationTest#testConvertToDottedProperties where

String code = "function f() { return this['bar']; } f.prototype.bar = 3;";
String expected = "function f() { return this.bar; } f.prototype.a = 3;";

failed with an error:

-f.prototype.a = 3;
+f.prototype.bar = 3;

[niloc132]

It sounds like you're trying to interact with third-party code without compiling that code along with your application? If so, I encourage you to explore "externs" and "exports". Externs serve the purpose of describing externally defined names/APIs so that the compiler knows what to not rewrite, what types will be returned, etc.

I had remembered that "exports" were the tool for defining your own API, but now that I'm re-reading documentation at https://developers.google.com/closure/compiler/docs/externs-and-exports, it appears that externs instead should be used to declare what symbols should be exported:

Exports also don't provide an API for consumers to follow in the way externs do. Compared to exports, externs document the symbols you intend to expose, their types, and give you a place to add usage information.
That link also omits discussion of the @export jsdoc annotation, discussed at https://github.com/google/closure-compiler/wiki/Annotating-JavaScript-for-the-Closure-Compiler#export-export-sometype.

So, you likely need to document the library you are using in an @externs file, and if you are exporting types for use by another downstream tool, document them in the same way.

I've used https://github.com/angular/tsickle/ with some limited success to auto-generate externs for .d.ts files, but it makes some assumptions that might be difficult (such as using tsickle itself to also transpile your ts into js?). I'm not sure if there are other tools that can do this for you.

[ddenisyuk]

Thank you for your swift reply.

I appreciate your suggestions, but maintaining externs for third-party libraries can be quite challenging and isn't always feasible. Despite trying the tips mentioned, I've encountered difficulties in achieving successful advanced compilation for some of my projects. While manually defining externs is an option, it feels like a complex and daunting task (nightmare even).

However, my primary intent here is to gather feedback on the specific changes I've did. If these changes are found beneficial, they could potentially be merged into the GCC. I'm open to opening a PR if that seems appropriate. At the same time, I'm okay with maintaining my fork if these changes contradict the GCC's vision or roadmap. I'm more interested in understanding the potential side effects of these changes.

[lauraharker]

Closure Compiler used to have a property renaming mode called "heuristic property renaming" that was deleted back in 2015, that isn't exactly what you're proposing but was deprecated for reasons I think would also show up in your proposal. So I don't think this is a change we can merge into the main repo.

The primary issue with heuristic property renaming was that medium/large projects using it found various encounter hard-to-resolve bugs caused by a change in one file affecting renaming in completely unrelated files. e.g. deleting some code function f() { return {'abcd': 0}; } would break code in another file like console.log(x.abcd);, that was unknowingly depending on abcd not being renamed. We settled on externs as a more understandable way to known when properties are/are not renamed.

For your project, one other thing to consider if you continue with this patch, is that more optimizations besides just RenameProperties have special handling for extern properties. See everything that uses compiler.getExternProperties() - this is populated by https://github.com/google/closure-compiler/blob/master/src/com/google/javascript/jscomp/GatherExternProperties.java.

[ddenisyuk]

Thank you for your answer and time