Stage 3 Class Method Decorators break references to classes declared on the module scope

[nigelwtf]

Bug Report

🔎 Search Terms

decorator, decorators

🕗 Version & Regression Information

• This is using version 5.0.4

⏯ Playground Link

Workbench Repro

💻 Code

function myDecorator(target: any) {
    return function(this: any, ...args: any[]) {
        return target.apply(this, args);
    }
}

export class MyClass {
    @myDecorator
    public foo() {
        return 'bar';
    }
}

export const myClassInstance = new MyClass();

🙁 Actual behavior

Interestingly the Workbench doesn't reproduce the issue - but when running tsc locally, the outputted JS code looks like this:

exports.MyClass = (() => {
    var _a;
    let _instanceExtraInitializers = [];
    let _foo_decorators;
    return _a = class MyClass {
      ...
    },
    (() => {
        _foo_decorators = [someDecorator];
        __esDecorate(_a, null, _foo_decorators, { ... });
    })(),
    _a;
});

exports.myClass = new MyClass();

Because MyClass is now defined under the exports object, the last line fails :'(

This only happens when a member decorator is present in the class. When the decorator is omitted, MyClass is declared under the module scope, and then assigned to the exports object later.

🙂 Expected behavior

I should be able to instantiate an exported class with a stage 3 decorator from within the same module.

[nigelwtf]

Also, FWIW, I'd be happy to contribute a fix, but some guidance would be welcomed :)

I created an issue first, just to ensure I wasn't duplicating a known defect (though I did search through the open issues beforehand).

[jcalz]

You didn't fill out the new issue template (if you clicked "New Issue" and then choose "Bug" you should have seen a form to fill out); could you please edit your post to do that?

[nigelwtf]

Ah - weirdly I wasn't prompted. I'll fill it out now.

[MrSimmmons]

Weird I've run into this as well. There are two work arounds, but being workaround I would rather not have to do them :P
1st Is to make the compile version in tsconfig es5. Why this works is because classes dont exist in es5 js, so the compiled file ends up looking like this:

var MyClass = exports.MyClass = function () {
    var _a;
    var _instanceExtraInitializers = [];
    var _foo_decorators;
    return _a = /** @class */ (function (_super) { ... })
}();

exports.myClassInstance = new MyClass();

So this doesnt break the file scope as MyClass gets defined as a variable first.

And 2nd is to not export the class, but to add the class to the exports object at the bottom of the file. So like this

class MyClass {
    @myDecorator
    public foo() {
        return 'bar';
    }
}

exports.MyClass = MyClass;

export const myClassInstance = new MyClass();

That way the exported file looks like this, which also doesnt break the scope

var MyClass = (() => {
    var _a;
    var _instanceExtraInitializers = [];
    var _foo_decorators;
    return _a = class MyClass { ... }
})();

exports.MyClass = MyClass;
exports.myClassInstance = new MyClass();

Both of these will work, but yeah. As stated above I would rather not have to do them. This does seem like a genuine problem with the way the ES6 compiler is handling decorators.

[rbuckton]

This is a duplicate of #53332 and has already been fixed by #53725, which is available in the 5.1 beta