when decorators emit type information class ordering becomes important

[paul-marechal]

Bug Report

When using decorators along with design type info, decorating a class that depends on another one implicitly adds a class definition ordering constraint. Not properly ordering those class definitions will result in a runtime crash, and the only way to know this is to know this issue before hand.

🔎 Search Terms

decorator initialization

🕗 Version & Regression Information

typescript 3.9.9 and 4.2.3

• This is the behavior in every version I tried, and I reviewed the FAQ for entries about Decorators

⏯ Playground Link

Playground link with relevant code

💻 Code

function someDecorator<T>(target: T): T {
    return target
}

@someDecorator
class A {
    constructor(arg?: B) {
        console.log('constructed A!', arg)
    }
}

class B {}

const a = new A()

Relevant generated JavaScript:

// [...]
let A = class A {
    constructor(arg) {
        console.log('constructed A!', arg);
    }
};
A = __decorate([
    someDecorator,
    // EARLY REFERENCE ISSUE: B is defined below, so the JS runtime will complain about not-initialized refs!
    __metadata("design:paramtypes", [B])
], A);
// LATE DEFINITION OF B:
class B {
}
// [...]

🙁 Actual behavior

[ERR]: can't access lexical declaration 'B' before initialization

🙂 Expected behavior

TypeScript to either emit code in the right way, or complain at build time to prevent the runtime issue.

[MartinJohns]

Duplicate of #27519. The error is different, the cause is the same.

[typescript-bot]

This issue has been marked as a 'Duplicate' and has seen no recent activity. It has been automatically closed for house-keeping purposes.