Reproducible Bug: ESBuild's removal of a class's name from its declaration breaks static initialization blocks

[axefrog]

The following is valid syntax because the class constructor is visible within the scope of static initializers:

class Foo {
  static {
    console.log(new Foo());
  }
}

ESBuild translates the above code to:

(() => {
  var __defProp = Object.defineProperty;
  var __name = (target, value) => __defProp(target, "name", { value, configurable: true });

  // dist/client/client.js
  var Foo = class {
    static {
      console.log(new Foo());
    }
  };
  __name(Foo, "Foo");
})();

I'm not sure why you're stripping the class name out of the declaration rather than just leaving it intact, but doing so puts identifier Foo into an uninitialized state at the time that the static initializer executes, thus breaking any reference to Foo that may be used within the initializer.

I discovered this bug as I am working with decorators in TypeScript, and my use of private class fields in an inline class declaration being passed to a method-decorator-producing function causes the TypeScript compiler to generate a static class block within the class declaration whose method is being decorated. A heavily stripped-down example of what I'm doing looks like this:

const Decorator = (C): MethodDecorator => () => {};
class Foo {
  @Decorator(class Metadata {
    readonly #data: any;
    constructor (data: any) { this.#data = data; }
  })
  run () {}
}

The TypeScript compiler's output for this is:

var __decorate = (this && this.__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;
};
const Decorator = (C) => () => { };
class Foo {
    run() { }
    static {
        __decorate([
            Decorator(class Metadata {
                #data;
                constructor(data) { this.#data = data; }
            })
        ], Foo.prototype, "run", null);
    }
}

As you can see, this code generated by the TS compiler needs to access the constructor of Foo from within Foo's static initializer block.

Related issues: #2800, #2389

Temporary workaround is to have ESBuild target es2020, which changes the generated output to account for the fact that static initializer blocks do not exist in the ES2020 standard.

[hyrious]

An interesting workaround to your first posted code is using this to refer to the class:

var Foo = class {
  static { console.log(new this) } // Foo {}
}

Because classes will have the name of the assigning variable.

But since the code is generated by tsc, there's no way to fix it :/

---

I'm not sure why you're stripping the class name out of the declaration rather than just leaving it intact

This is an issue. Thinking in a bundler, it's easy to come up with an idea that every exported name is a var (or let). That's what esbuild does transformation for function and class. However it is not always safe:

• class: The class declaration has the same scoping like let, and the static field/block make things become more complex.
• function: The function declaration behaves like var but is slightly different (When the input code has nested function declaration, the output code errors with Identifier 'foo' has already been declared #2809) that it won't conflict with outer scope consts. The js quirk mode makes things become more complex.

There're 2 refactor requests we can conclude:

• Keep declaration's original form like class <name> or function <name> (the better if keeping top-level const and let for targeting library)
• Lowering static fields/blocks should be carefull, when it has problems maybe lowering both.

[axefrog]

@hyrious Thanks for the reply. ESBuild has some other unfortunate quirks too, like renaming things that don't need to be renamed. keepNames is okay for some things, but a lot of diagnostic work is done in the console, and ESBuild's habit of renaming everything makes the console somewhat less useful for just inspecting outputs at a glance. I need to move forward though, so I've now switched to Webpack, which seems plenty fast enough for what I'm doing, and all of its output is predictable and correct.

[TheWind3]

Here an another example of the same bug I stumbled upon right now.

Here is typescript-compiled code:

export class SomeClass {
  static { this.One = 1; }
  static { this.Two = SomeClass.One * 2; }
}

After esbuild-ing this code turns into this:

var SomeClass = class {
  static {
    this.One = 1;
  }
  static {
    this.Two = SomeClass.One * 2;
  }
};
```
The second static block will fail at runtime because SomeClass is still undefined.