Decorators support inconsistent with Typescript

Bug Report

I was trying to port build pipeline (webpack) from ts-loader to babel-loader. I am using decorator (for redux action types) implementation bellow.

Current Behavior My input code works just fine with typescript. However using babel, prototype in actionClass in my decorator is undefined. I also tried various modifications (omit prototype and set type directly on actionClass) but all failed. I was simply unable to set type on the base class with decorator.

// Babel console.log(actionClass);
Descriptor {kind: "class", elements: Array(0), Symbol(Symbol.toStringTag): "Descriptor"}

Input Code

abstract class Action {
    public type: string;
    constructor() {
        this.type = this.type;
    }
}

export interface ActionClass<T extends Action> {
    prototype: T;
}

export function typeName(name: string): <T extends Action>(actionClass: ActionClass<T>) => void {
    return actionClass => {
        actionClass.prototype.type = name;
    };
}

// Usage :
export interface TestActionPayload {
    sample: string;
}
@typeName('TEST_ACTION')
export class TestAction extends Action {
    constructor(public payload: TestActionPayload) {
        super(payload);
    }
}

Expected behavior/code It is partly unclear to me if this is a bug, or problem on my end. However, one way or another, I am expecting to be able to set properties on base class with decorators. Currently I can’t.

// Typescript console.log(actionClass);
ƒ TestAction(payload) {
    var _this = _super.call(this, payload) || this;
    _this.payload = payload;
    return _this;
}

Babel Configuration (.babelrc, package.json, cli command)

options: {
    cacheDirectory: true,
    babelrc: false,
    presets: [
        [
            "@babel/preset-env",
            { targets: { browsers: "last 2 versions" } } // or whatever your project requires
        ],
        "@babel/preset-typescript",
        "@babel/preset-react"
    ],
    plugins: [
        ["@babel/plugin-proposal-decorators", { decoratorsBeforeExport: true }],
        ["@babel/plugin-proposal-class-properties", { loose: true }],
        "@babel/plugin-syntax-dynamic-import",
        "react-hot-loader/babel"
    ]
}

Environment

• Babel version(s): [7.1.2]
• Node/npm version: [Node 9.5.0/npm 6.4.1]
• OS: [Windows 10]
• Monorepo [no]
• How you are using Babel: [loader]

Possible Solution

Additional context/Screenshots Add any other context about the problem here. If applicable, add screenshots to help explain.

[trusktr]

This issue is 2 years old

There are still quite a few differences, and even after 2 years they still aren’t documented well. If I find more differences, I will document them here to start with, and then maybe I’ll put them in an article later, compadre. 😉

[trusktr]

I can’t imagine why @PeterKottas had any issue with that. It works fine for me.

But in general, the legacy decorators in Babel behave different than legacy decorators in TypeScript. For example:

• In Babel legacy decorators, they may receive an initializer property instead of a value property, but in TypeScript there is never an initializer property, only a value property.
• In TypeScript, decorators must return a descriptor for them to be chained with other decorators on the same class element.
• In TypeScript, the previous point (decorator returning a descriptor) results in the class field (if decorator was used on a field) having [[Set]] semantics when useDefineForClassFields is set to false (otherwise many decorators would break).
• In Babel, if a legacy decorator returns a descriptor, this causes the class field to always use [[Define]] semantics, regardless of the value of the loose option for the plugin-proposal-class-properties option (which seems like a bug), which is opposite of TypeScript behavior.
• In TypeScript property decorators don’t receive a descriptor, but they do in Babel.
• etc

And there are more differences. Overall, they are two very different decorator systems, although they both supposedly are based on the legacy spec. Maybe one evolved with the legacy spec more than the other over time?

If anyone knows of more differences in detail, please do list them here. That would be helpful!