Skip to content
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

Private field incorrectly initialized before the super call #4087

Open
volkanceylan opened this issue Feb 19, 2025 · 0 comments · May be fixed by #4092
Open

Private field incorrectly initialized before the super call #4087

volkanceylan opened this issue Feb 19, 2025 · 0 comments · May be fixed by #4092

Comments

@volkanceylan
Copy link

Sorry that I had to close the prior issue which had no responses (#3939) and open this as this bug is blocking us and our framework users (Serenity) from updating esbuild to 0.24 or later:

This is an issue introduced in 0.24 as 0.23.1 does not have this problem. Probably introduced with the fix to #3913

{
  loader: 'ts',
  format: 'iife',
  target: 'es2015',
  tsconfigRaw: {
    compilerOptions: {
      useDefineForClassFields: false
    }
  }
}
function testDecorator(a: string) {
  return function (target: Function, _context?: any) { }
}

class A {
   constructor() {
   }
}

@testDecorator("a")
class B extends A {
  private m1: any;

  constructor() {
    super();
  }

}

new B();

The generated constructor for the derived B class with a private field includes a field initializer before the super call which results in the following error in browser console if you copy paste the generated code:

VM17:64 Uncaught ReferenceError: Must call super constructor in derived class 
before accessing 'this' or returning from derived constructor
    at new B (<anonymous>:64:7)
    at <anonymous>:71:3
    at <anonymous>:72:3
class B extends (_a = A) {
    constructor() {
      this.m1 = void 0;
      super();
    }
  }

In addition to producing invalid code, I think this behavior should only be applied to properties with decorators themselves (not when only the class itself has a decorator). Otherwise this will be a breaking change for those using useDefineForClassFields: false.

TypeScript does not do this for classes with only class decorators:

https://www.typescriptlang.org/play/?target=2#code/GYVwdgxgLglg9mABFApgZygERROAnAQynwAooC8BzFKALkQLAE8AaRXMVADzoeYEpEAbwBQAXxEiIAGwJo0iAILCRiNRwx4Q0UoNFrEEiSIACqDNlyFieKbPmIAQohQ8UYACYLl+xAFsARnpGJgBuSXUETW0bEj1VAzQQAAcUPDjwtWNjMBQAdycMoA

But only for individual properties with decorators:

https://www.typescriptlang.org/play/?target=2#code/GYVwdgxgLglg9mABFApgZygERROAnAQynwAooC8BzFKALkQLAE8AaRXMVADzoeYEpEAbwBQAXxEiIAGwJo0iAILCRiNRwx4Q0UoNFrEEiVNnzEAIUQoeKMABMFy-YgACqDNlyFieVYgAOeDAAbkQoiAC2AIz0jEwA3JLqCJraPiR6fmpoIP4oeBmJasbGYCgA7haFQA

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
1 participant