In target: ES5, Base class constructor's primitive return value should be ignored

[Josh-Cena]

Bug Report

🔎 Search Terms

class, extends, constructor, return primitive

🕗 Version & Regression Information

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

⏯ Playground Link

Playground link with relevant code

💻 Code

new class extends class {
  constructor() {
    return 1;
  }
} {
  constructor() {
    super();
    console.log(typeof this);
  }
}

🙁 Actual behavior

Logs "number"

🙂 Expected behavior

Logs "object"

[MartinJohns]

This is working as intended. It's legit JavaScript. For TypeScript to change this behaviour would violate the language design goals.

Related: #38519 / #27594 / #13819

[Josh-Cena]

@MartinJohns The change can be trivially done in the downleveling—it requires no type information.

new /** @class */ (function (_super) {
    __extends(class_1, _super);
    function class_1() {
-       var _this = _super.call(this) || this;
+       var _this = _super.call(this);
+       if (_this === null || (typeof _this !== "object" && typeof _this !== "function"))
+           _this = this;
        console.log(typeof _this);
        return _this;
    }
    return class_1;
}(/** @class */ (function () {
    function class_2() {
        return 1;
    }
    return class_2;
}())));

FWIW, anything that Babel does right but tsc does wrong looks like a bug to me.

[MartinJohns]

Nevermind my earlier comment. I wrongly assumed the JavaScript will behave the same.

[fatcerberus]

You probably should have specified that this only happens with ES5-downleveled code. From the OP it seemed like you meant this happened regardless of target (which would indicate it was just normal JS behavior).

[RyanCavanaugh]

FWIW, anything that Babel does right but tsc does wrong looks like a bug to me.

You should use Babel in that case. The TS emit takes some complexity/compliance tradeoffs and is much less configurable.

I don't think we want to risk breaking any ES5 programs at this point given how old of a target it is.

[Josh-Cena]

I can guess the historical context here (tsc implementing classes before the latter getting standardized), but IMO the current behavior doesn't benefit anyone and is unlikely to be relied on. If this is a primitive, it means you can't mutate it whatsoever. Unless you do something really weird like:

function SomethingThatReturnsEitherObjectOrNumberIDK() {
  if (somethingNotGoingWell) return 1;
  return {
    the: "actual object that I want to construct",
  };
}

declare class SomethingThatReturnsEitherObjectOrNumberIDK {
  the?: string;
}

new class extends SomethingThatReturnsEitherObjectOrNumberIDK {
  constructor() {
    super();
    if (typeof this === "number")
      return { the: `number wrapped into an object: ${this}` }; // type: { the: never }
  }
}

But that doesn't even get correct types! Why would someone use tsc, choose its bizarre subclassing behavior, but also disregard the types?

Built-in subclassing not working is a missed but understandable tradeoff, but this one seems niche and not as breaking-change-prone, while increasing tsc's conformance.