Version: 7.0.2 (the tsc from the typescript npm package). Emits correctly on 6.x.
With experimentalDecorators on, when a decorated class uses its own name as an object literal property key inside its body, the emitter rewrites the key to the decorator self-reference alias (SessionAuth becomes SessionAuth_1).
Repro
experimentalDecorators: true:
const dec = (t: any) => t;
@dec
class SessionAuth {
static requirement() {
return { SessionAuth: [] };
}
}
Expected emit (what 6.x produces):
static requirement() {
return { SessionAuth: [] };
}
Actual emit on 7.0.2:
var SessionAuth_1;
let SessionAuth = SessionAuth_1 = class SessionAuth {
static requirement() {
return { SessionAuth_1: [] };
}
};
SessionAuth = SessionAuth_1 = __decorate([dec], SessionAuth);
The SessionAuth in the object literal is a property name, not a reference to the class, so it should be left alone. The wrong key only shows up at runtime. In our case it renamed an OpenAPI security scheme key and broke request validation after we upgraded.
The same substitution happens for other name positions that match the class name (a shorthand method name, a class field name). Property access on other objects and string-literal keys are not affected.
Likely a missed instance of a known problem
This looks like the same root cause as #3146 (enum member access with the same name as a decorated class), which was closed via #3147. That fix covered the enum-access position; the object-literal-key position seems to have been missed. Might be worth checking whether the fix can be widened to cover all name positions rather than the enum case on its own.
Version: 7.0.2 (the
tscfrom thetypescriptnpm package). Emits correctly on 6.x.With
experimentalDecoratorson, when a decorated class uses its own name as an object literal property key inside its body, the emitter rewrites the key to the decorator self-reference alias (SessionAuthbecomesSessionAuth_1).Repro
experimentalDecorators: true:Expected emit (what 6.x produces):
Actual emit on 7.0.2:
The
SessionAuthin the object literal is a property name, not a reference to the class, so it should be left alone. The wrong key only shows up at runtime. In our case it renamed an OpenAPI security scheme key and broke request validation after we upgraded.The same substitution happens for other name positions that match the class name (a shorthand method name, a class field name). Property access on other objects and string-literal keys are not affected.
Likely a missed instance of a known problem
This looks like the same root cause as #3146 (enum member access with the same name as a decorated class), which was closed via #3147. That fix covered the enum-access position; the object-literal-key position seems to have been missed. Might be worth checking whether the fix can be widened to cover all name positions rather than the enum case on its own.