Bug Report

Hello,

I'm a mixin evangelist, perhaps you've seen my blog posts on the topic:
https://www.bryntum.com/blog/the-mixin-pattern-in-typescript-all-you-need-to-know/
https://www.bryntum.com/blog/the-mixin-pattern-in-typescript-all-you-need-to-know-part-2/
https://bryntum.github.io/chronograph/docs/modules/_src_guides_advancedfeatures_.html#mixins

The main advantage of using mixins instead of classic single class inheritance, is that mixins allows you to organize the hierarchy as a graph, instead of a tree, and write polymorphic code in the type-safe way.

However, when using mixins, enabling the generation of the declaration files fails when using certain form of class extension lambda. It works with another form, see below. In both cases, the compilation w/o declaration files works fine.

The issue is that, as a user, I expect, that if compilation passes, the declaration files generation should "just work". And currently, you can have your project to fully typecheck, but generation of declaration files will fail.

🔎 Search Terms

declaration files mixin

🕗 Version & Regression Information

I've tried with TypeScript 4.2.3 and 4.4.0-dev.20210527

⏯ Playground link

The reproducible case is reduced to a bare minimum. The full mixin library looks like this

🙁 Actual behavior

As you can see in the playground, the declaration of XmlElement2 fails with

'extends' clause of exported class 'XmlElement2' has or is using private name 'XmlElement2'.

The very similar declaration of XmlElement works, even that it also uses the private name XmlElement. However, the generated type for the parent property is any, which is incorrect, but at least it does not fail.

The reason I'm using the declaration form of XmlElement2 is that it supports decorators. Try un-commenting the decorator in the XmlElement declaration and see that it fails with another error.

So currently, I can either have decorators supported or declaration files, but not both.

🙂 Expected behavior

I expect the declaration file generation to always succeed, if regular compilation completes w/o errors.