__esDecorate transpiled code uses "Symbol" even of this is shadowed by a local variable

🔎 Search Terms

helper symbol tslib

🕗 Version & Regression Information

• This changed between versions 5.1.6 and 5.2.2

Tested via playground and reading its debug output.

⏯ Playground Link

https://www.typescriptlang.org/play/?ts=5.9.0-dev.20250617#code/GYVwdgxgLglg9mABMOcAiBTCcBOBDKXAClxgHMYw8AbAWQygAs4ATALkTzAE8AaRbGCgYAHlA5duASkQBvAL4AoRaIAOuKAOp4AzjsQBlbgFsARnGpyBCHVBwhoxGbMTzXygAIp0WXAVwqIuo4mhDaeojG3ADC4fqyiohJgrb2jjhEzoiJSbkpmgD6YBgA7kbGiAC8iMUlhibm1JkA3DnuSkA

💻 Code

function fooDecorator(originalMethod: any, context: any) {}

export class Symbol { constructor() { } }

@fooDecorator
export class myClass {
   constructor() { 
      const _newSym = new Symbol();
   }
}

🙁 Actual behavior

The generated js code for myClass contains

const _metadata = typeof Symbol === "function" && Symbol.metadata ? Object.create(null) : void 0;

Which will access my local variable Symbol instead of window.Symbol/globalThis.Symbol.

🙂 Expected behavior

The generated code should access globalThis.Symbol in any case or perhaps only if the file contains a local variable (from class, const or import) with a colliding name.

Additional information about the issue

I found this with an import { Symbol } from "./service"; call (roughly modelled via this Bug Workbench) but this should not change the main problem.

We started to use the class name Symbol in our code (and public API) since 2014.

Right now we circumvent this issue by using different names inside the local file via alias names in import/export
But this is hard to understand and maintain.

リンク先の TypeScript playground から始め、生成された __esDecorate コードでローカルの Symbol 宣言または import を調べます。decorator metadata helper が Symbol 参照をどのように選択するかを追跡し、その後、出力されたコードがローカルバインディングを解決しなくなり、示されている decorator の例も引き続き処理できることを確認します。