Skip to content

Decorators do not work, when targeting ES2022 #55787

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
paulsmithkc opened this issue Sep 19, 2023 · 2 comments
Closed

Decorators do not work, when targeting ES2022 #55787

paulsmithkc opened this issue Sep 19, 2023 · 2 comments
Labels
Working as Intended The behavior described is the intended behavior; this is not a bug

Comments

@paulsmithkc
Copy link

paulsmithkc commented Sep 19, 2023

πŸ”Ž Search Terms

decorator, target:ES2022, experimentalDecorators, emitDecoratorMetadata, TC39

πŸ•— Version & Regression Information

This changed between target:ES2021 and target:ES2022

⏯ Playground Link

https://github.com/paulsmithkc/typescript-decorators

πŸ’» Code

tsconfig.json

{
  "compilerOptions": {
    "target": "ES2022",
    "module": "commonjs",
    "outDir": "dist",
    "declaration": true,
    "experimentalDecorators": true,
    "emitDecoratorMetadata": true
  },
  "include": ["src"],
  "exclude": ["node_modules", "dist"]
}

src/index.ts

function setting(defaultValue: string): any {
  function settingExperimental(target: unknown, property: string | symbol): void {
    console.log('settingExperimental', { defaultValue, target, property });
    target[property] = process.env[String(property)] || defaultValue;
    return;
  }
  function settingTC39(_target: unknown, context: ClassFieldDecoratorContext): () => string {
    return function (): string {
      console.log('settingTC39', { defaultValue, target: this, context, type });
      return process.env[String(context.name)] || defaultValue;
    };
  }
  return function (target: unknown, context: string | symbol | ClassFieldDecoratorContext) {
    if (typeof context !== 'object') {
      return settingExperimental(target, context);
    } else {
      return settingTC39(target, context);
    }
  };
}

console.log('CLASS DECLARATION.');
class Config1 {
  @setting('default_1') SETTING_ONE: string;
}
class Config2 extends Config1 {
  @setting('default_2') SETTING_TWO: string;
}

console.log('OBJECT INSTANTIATION.');
const configInstance = new Config2();
console.log({
  prototype1: Config1.prototype,
  prototype2: Config2.prototype,
  SETTING_ONE: configInstance.SETTING_ONE,
  SETTING_TWO: configInstance.SETTING_TWO,
});

if (!configInstance.SETTING_ONE) {
  throw new Error('SETTING_ONE NOT INITIALIZED');
}
if (!configInstance.SETTING_TWO) {
  throw new Error('SETTING_TWO NOT INITIALIZED');
}

console.log('DONE.');

run with:

tsc --project tsconfig.json && node dist/index.js

πŸ™ Actual behavior

When targeting ES2022:

  • SETTING_ONE and SETTING_TWO are both undefined.

When targeting ES2021:

  • SETTING_ONE and SETTING_TWO are populated as expected.

πŸ™‚ Expected behavior

When targeting an version of ECMA script:

  • SETTING_ONE and SETTING_TWO are populated as expected.

Additional information about the issue

The generate code differs from ES2021 to ES2022, which is what is causing this issue.

ES2021

class Config1 {
}
class Config2 {
}

ES2022

class Config1 {
    SETTING_ONE;
}
class Config2 extends Config1 {
    SETTING_TWO;
}
@MartinJohns
Copy link
Contributor

MartinJohns commented Sep 19, 2023

This is working as intended. See: https://www.typescriptlang.org/tsconfig/useDefineForClassFields.html

And also: #48814

@RyanCavanaugh RyanCavanaugh added the Working as Intended The behavior described is the intended behavior; this is not a bug label Sep 19, 2023
@typescript-bot
Copy link
Collaborator

This issue has been marked as "Working as Intended" and has seen no recent activity. It has been automatically closed for house-keeping purposes.

@typescript-bot typescript-bot closed this as not planned Won't fix, can't repro, duplicate, stale Sep 22, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Working as Intended The behavior described is the intended behavior; this is not a bug
Projects
None yet
Development

No branches or pull requests

4 participants