Guidelines for supporting ADVANCED compile

[pcj]

Given a typescript codebase with no prior knowledge of Closure, what steps need to be taken to make it safe for advanced closure compilation (through tsickle)?

[evmar]

It would be great for us to document this, thanks for filing the bug!

To start with, https://developers.google.com/closure/compiler/docs/api-tutorial3 is a good read.

It is my ultimate goal with tsickle that it always just does the right thing and you don't need to worry about what the compiler will do. See this bug label:
https://github.com/angular/tsickle/issues?q=is%3Aopen+is%3Aissue+label%3A%22prevent+closure+antipatterns%22

[pcj]

Thanks @evmar, sounds like tsickle won't be able to insulate the user (in this case a generic typescript author) from knowing about what patterns to avoid to use ADVANCED compile.

I'm coming into a project that has a medium'ish sized existing typescript codebase, probably overly optimistic / naiive to expect that it will work with advanced compilation without some serious examination of the codebase.

Is that your sense as well?

[evmar]

In practice it boils down to a few things:

• never access both foo.bar and foo["bar"] on the same object
• be careful around JSON

[evmar]

And yes, it's likely you'll compile your project and discover some problems. However, usually it's not super hard to debug, though you will have to squint at some optimized code.

[pcj]

Does tsickle convert foo["bar"] to foo.bar, which would become $foo$.$bar$ and then a.b?

[evmar]

No. It's important to be able to write foo["bar"] and have it make it into Closure, as it supports code patterns like:

let obj = JSON.parse(someText);
console.log(obj["foo"]);  // should use "foo" in the output, as that's what the JSON has
// note that Closure might actually compile that into obj.foo as that's fewer characters

My current thinking is we should warn people away from it in the case where you're using a string to access a property:
#23