Support property renaming for decorators #1125
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
TypeScript converts code like this:
```typescript
class Foo {
@decorator prop = 'hi';
}
```
into JS like this:
```javascript
tslib_1.__decorate([
decorator,
tslib_1.__metadata("design:type", Object)
], Foo.prototype, "prop", void 0);
```
This is a problem for Closure Compiler's property renaming, because the property `prop` may have been renamed, but `"prop"` is just a string literal, and so it won't be renamed. Fortunately there is an API that Closure Compiler knows to process at build time that will rename a string literal representing a field name on a type: https://google.github.io/closure-library/api/goog.reflect.html#objectProperty
With this change, when emitting goog.module output, tsickle will notice calls to `__decorate` and instead emit
```javascript
tslib_1.__decorate([
decorator,
tslib_1.__metadata("design:type", Object)
], Foo.prototype, __googReflect.objectProperty("prop", Foo.prototype), void 0);
```
where `__googReflect` is defined just after the `goog.module` section as
```javascript
const __googReflect = goog.require("goog.reflect");
```
In this way, the decorator may safely use the property name with the assurance that it will be renamed at runtime when compiled with Closure Compiler.
Doc (unfortunately internal to google) considering the various implementation options: https://goto.google.com/renaming-safe-decorators
mprobst
approved these changes
Dec 2, 2019
|
Approved. Let's do another TAP round, and then I can try to land tomorrow. |
|
Last night's TAP run is looking good. See http://test/283069087 (I have fixes for the two failures in TypeScript tests). |
|
Thanks, landed! |
rictic
added a commit
to rictic/tsickle
that referenced
this pull request
Dec 15, 2019
@ExportDecoratedItemsIfPublic is a new decorator modifier for fields which should only be exported if public. When private or protected they are renamable and may be eliminated as dead code. This is more optimal version of @ExportDecoratedItems for fields which can only be accessed by reflection if they're public. Our use case ExportDecoratedItemsIfPublic is the LitElement @Property decorator, where public properties are accessible as HTML attributes and may be written by raw HTML files or various template languages (lit-html, soy, angular templates, etc). This obviously is taking place outside of the class hierarchy of the element and so is only valid for public properties, but it is still useful for private properties to participate in the update lifecycle that comes along with @Property. This change, combined with the already-landed angular#1125 we'll be able to remove the final @ExportDecoratedItems annotation from the LitElement decorators.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
TypeScript converts code like this:
into JS like this:
This is a problem for Closure Compiler's property renaming, because the property
propmay have been renamed, but"prop"is just a string literal, and so it won't be renamed. Fortunately there is an API that Closure Compiler knows to process at build time that will rename a string literal representing a field name on a type: https://google.github.io/closure-library/api/goog.reflect.html#objectPropertyWith this change, when emitting goog.module output, tsickle will notice calls to
__decorateand instead emitwhere
__googReflectis defined just after thegoog.modulesection asIn this way, the decorator may safely use the property name with the assurance that it will be renamed at runtime when compiled with Closure Compiler.
Doc (unfortunately internal to google) considering the various implementation options: https://goto.google.com/renaming-safe-decorators