Road to spec decorator

[Austaras]

Some history

There are historically three versions of decorator

1. legacy decorator. Babel and tsc both support it, and it gains widely adopted in js community.
2. static decorator. Some engine people believe version 1 is too dynamic to optimize, so they came up with this. Nobody actually uses it, and babel would drop it in version 8.
3. current decorator. It's already entered stage 3. Babel supports it as 2021-12 and would be default in version 8. TS and esbuild people have already been working on it. It shares many similarities with 1.

Current status of swc

There're currently two options related with decorator in swc, which is jsc.parsre.decorators and jsc.transform.legacyDecoratos. Enable former would enable decorator in parser, and static decorator in transform. Enable later would enable legacy decorator.

This poses a problem in how to expose API for spec decorator.

Possible solution

1. release a new major version to drop support for static decorator, and substitute it with spec decorator. This sounds a bit overreacting, but considering the many problems of current swc js config, it is not entirely unacceptable.
2. add an option in transform, maybe called specDecorators, and if both this and legacyDecoratos is set to true, throw an error. It has no other downside than ugly.

[kdy1]

I think the second option is better, as I want to do much more cleanup (of config) for the next major version release

[Austaras]

Oh, glad to know there'a alreay a plan to clean config

[Austaras]

First ts version that support spec decorator would be 4.8 and it will be release in august. If rework of config could be done before that, solution 1 is still possible

[kdy1]

Problem is that we want to do much more than config cleanup for v2.
One of planned item is stabilization of plugins (with some compat)

[Austaras]

Well tsc people hasn't started working on decorator yet...

[yay]

Looks like they have finished:
https://devblogs.microsoft.com/typescript/announcing-typescript-5-0-beta/#decorators
evanw/esbuild#104 (comment)

[Amareis]

So, TypeScript take different approach - new decorators is available until you specify legacyDecorators: true. Maybe swc should use such strategy too? It's much more straightforward, aligned with ES spec, which obviously will became standart, and doesn't need any additional flags in config.

[Austaras]

TSC can freely do break change while SWC cannot -- SWC would generate old spec decorator if legacyDecorators is not specified, although I haven't seen any people using it.

[kdy1]

Honestly, I don't expect someone to use it, but I'll implement it with an option at start

[kdy1]

I started working at #6950

[tgfisher4]

Hello! Saw that #6950 was included in 1.3.45: thanks for your hard work! However, I am having trouble using the stage 3 spec decorators feature.

---

When I copy the simple example from the TS 5 beta announcement and configure .jsc.parser.syntax: "typescript", .jsc.parser.decorators: true, and .jsc.transform.legacyDecorator: false, the output emitted looks like it's still expecting the legacy decorator interface:

var __decorate = (void 0) && (void 0).__decorate || function(decorators, target, key, desc) {
    var c = arguments.length, r = c < 3 ? target : desc === null ? desc = Object.getOwnPropertyDescriptor(target, key) : desc, d;
    if (typeof Reflect === "object" && typeof Reflect.decorate === "function") r = Reflect.decorate(decorators, target, key, desc);
    else for(var i = decorators.length - 1; i >= 0; i--)if (d = decorators[i]) r = (c < 3 ? d(r) : c > 3 ? d(target, key, r) : d(target, key)) || r;
    return c > 3 && r && Object.defineProperty(target, key, r), r;
};

See this playground. Running the output code in Google Chrome (Version 111.0.5563.146 (Official Build) (arm64)) does not yield the expected logging:

---

I also tried try removing the types and configuring .jsc.parser.syntax: "ecmascript", .jsc.parser.decorators: true, and .jsc.transform.legacyDecorator: false. The output emitted looks like it calls the decorators with a single argument, an elementObject derived from the elementDescriptor derived from an element's def: the elementObject looks somewhat similar to the decorator proposal's context, but is not quite the same:

var elementFinisherExtras = _toElementFinisherExtras((0, decorators[i])(elementObject) || elementObject);

See this playground: running the output code in Google Chrome (Version 111.0.5563.146 (Official Build) (arm64)) yields an error:

---

Are these examples expected to work? Am I missing some configuration needed to use spec decorators with swc? Am I (and the TS 5 beta announcement) mistaken about the spec decorator API or another detail of how this is supposed to work? Is this the right forum to discuss this?

[miso-belica]

I though stage 3 decorators are not supported by SWC but @kdy1 in #3062 (comment) says they are. Now I checked it and it seems legacy decorator structure is still emitted by swc. Is there anything what I have to do to emit stage 3 proposal for decorators the same way as TS v5 emits? I am using @swc/jest and I have the test below. As @tgfisher4 mentions I see in the debugger old structure is emitted.

// .swcrc
{
  "jsc": {
    "parser": {
      "syntax": "typescript",
      "decorators": true,
    },
    "transform": {
      "legacyDecorator": false
    }
  }
}

const _BOUND_FUNCTIONS = {};

export class BackgroundJob {
  static readonly bind = <This, Args extends unknown[], Return extends void>(
    method: (this: This, ...args: Args) => Promise<Return>,
    context: ClassMethodDecoratorContext<This, (this: This, ...args: Args) => Promise<Return>>,
    ...argss: any[]
  ) => {
    const name = String(context.name);
    context.addInitializer(function () {
      _BOUND_FUNCTIONS[name].bind(this, argss);

      this[context.name] = async (...args: Args): Promise<void> => {
        await BackgroundJob.create({name, args});
      };
    });
  };
}

class TestClass {
  calls: string[] = [];

  @BackgroundJob.bind
  success(s: string, n: number) {
    this.calls.push(`success(${s}, ${n})`);
    return Promise.resolve();
  }
}

[kdy1]

Currently, there's no JS api. It's only implemented