Allow .d.ts files to represent anonymous class expressions with private members

Re-opening of

False error TS4094: ... exported class expression may not be private or protected. #30355

That other issue is labeled "working as intended" so instead of this feature being a bug report, it is a feature request.

Wouldn't it be cool if this had some text in it?

It doesn't need, the other issue has details, but it is closed. I just think that this is a valid problem that is faced much too often by TS devs.

Related to #17293 (actually the same) - see #17293 (comment)

Related to #17744 - see my comment explaining why this is important #17744 (comment)

any process?

Encountered this issue when trying Builder Pattern.

Titian Cernicova-Dragomir (@dragomirtitian)

This seems like it would be a way to annotate classes that have computed properties when using isolated declarations. Right now the only way to type this

export class Foo implements Iterable<number> {
  [Symbol.iterator]: () => {
  // ^ Computed property names on class or object literals cannot be inferred with --isolatedDeclarations.ts(9038)
    ...
  }
}

is to do something like

interface FooInstance extends Iterable<number> {}

interface FooClass {
  constructor(): FooInstance;
}

const _Foo = class {
  [Symbol.iterator]: () => {
    ...
  }
};

export const Foo: FooClass = _Foo;
export type Foo = FooInstance;

which is pretty verbose and doesn't quite have the exact same semantics in some cases.

If anonymous class types were allowed then we could perhaps do something like

export const Foo: class implements Iterable<number> {} = class {
  [Symbol.iterator]: () => {
    ...
  }
}

cc Titian Cernicova-Dragomir (@dragomirtitian) Wesley Wigham (@weswigham)

[FIX] ts: fix compiling of `.d.ts` files

I thought I'd try to be a little bit cool, so I added some text for some context. 😎😄

A notable use case for this is support for class-factory mixins.

This code,

type Constructor<T = object, A extends any[] = any[], Static = {}> = (new (...a: A) => T) & Static

function CoolMixin(Base: Constructor<HTMLElement>) {
  return class CoolClass extends Base {
    private foo = 123

    meth(other: CoolClass) {
      console.log(other.foo)
    }
  }
}

currently produces the type error

Property 'foo' of exported anonymous class type may not be private or protected. ts(4094)

playground

Note that using the newer #hashtag private syntax,

type Constructor<T = object, A extends any[] = any[], Static = {}> = (new (...a: A) => T) & Static

function CoolMixin(Base: Constructor<HTMLElement>) {
  return class CoolClass extends Base {
    #foo = 123

    meth(other: CoolClass) {
      console.log(other.#foo)
    }
  }
}

does not have a type error!

playground

However! Mixins that use #hashtag private fields will experience runtime errors in JavaScript. This code,

type Constructor<T = object, A extends any[] = any[], Static = {}> = (new (...a: A) => T) & Static

function CoolMixin(Base: Constructor<HTMLElement>) {
  return class CoolClass extends Base {
    #foo = 123

    meth(other: CoolClass) {
      console.log(other.#foo)
    }
  }
}

class One extends CoolMixin(HTMLElement) {}
customElements.define('x-one', One)

const one = new One()

class Two extends CoolMixin(HTMLElement) {}
customElements.define('x-two', Two)

const two = new Two

two.meth(one) // Runtime error!

throws the error

TypeError: Cannot read private member #foo from an object whose class did not declare it

playground

The simplest workaround is to use a convention like prefixing members with _ (one underscore) for protected, and prefixing members with __ (two underscores) for private, abandoning protected, private, and #private altogether.

This works:

type Constructor<T = object, A extends any[] = any[], Static = {}> = (new (...a: A) => T) & Static

/**
 * Members prefixed with __ are private, don't touch or you're a gonner!
 */
function CoolMixin(Base: Constructor<HTMLElement>) {
  return class CoolClass extends Base {
    __foo = 123

    meth(other: CoolClass) {
      console.log(other.__foo)
    }
  }
}

class One extends CoolMixin(HTMLElement) {}
customElements.define('x-one', One)

const one = new One()

class Two extends CoolMixin(HTMLElement) {}
customElements.define('x-two', Two)

const two = new Two

two.meth(one)

playground

For now, I use underscore conventions because that's easy! It does mean that the "protected" and "private" members are technically public, visible for IDE autocompletion in contexts when they otherwise wouldn't be, which is not ideal, but the visible underscores should be enough of a clue, especially if the convention is well documented.

Another workaround, for private members, it to use WeakMaps, but that's a bit more cumbersome than the simple underscore convention.

Isolated declarations was later extended to support the case I brought up. My previous comment can be disregarded.

Navigation Menu

Repository navigation

Allow .d.ts files to represent anonymous class expressions with `private` members #36060

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Allow .d.ts files to represent anonymous class expressions with private members #36060

Description

Activity

RyanCavanaugh commented on Jan 8, 2020

trusktr commented on Jan 20, 2020

web-padawan commented on Jan 22, 2020

RonnieLincoln commented on Aug 28, 2022

MichaelMitchell-at commented on May 26, 2024

trusktr commented on Oct 13, 2025

MichaelMitchell-at commented on Jan 13, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

Allow .d.ts files to represent anonymous class expressions with `private` members #36060