`disallowClassExpressions`

[valler]

🔍 Search Terms

class, expression

✅ Viability Checklist

• This wouldn't be a breaking change in existing TypeScript/JavaScript code
• This wouldn't change the runtime behavior of existing JavaScript code
• This could be implemented without emitting different JS based on the types of the expressions
• This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
• This isn't a request to add a new utility type: https://github.com/microsoft/TypeScript/wiki/No-New-Utility-Types
• This feature would agree with the rest of our Design Goals: https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals

⭐ Suggestion

A compiler option disallowClassExpressions or noClassExpressions

This is option would primarily be intended to strengthen language level understanding / error prevention. In addition it would help prevent errors hitting compiler "bugs"/limitations.

With the exception of actual class factories, there seems to be no practical use case for class expressions. It is merely an artifact of JS classes being syntax sugar for design patterns around functions, which in turn leads to (seemingly a lot of) confusion, errors and misuse.

A subset of issues that popped up because of class expressions, where there seems to be no obvious use case for leveraging that feature to solve a certain problem, but rather to get rid of an error message about declaration file capabilities; and on the contrary, all seem to show examples of "bad practice":

• False error TS4094: ... exported class expression may not be private or protected. #30355 (closed)
• Allow .d.ts files to represent anonymous class expressions with private members #36060 (same, just reopened due to pushback)
• Unexpected TS4094 with the build parameter declaration: true #17293

This option would fit well among options like strict, noImplicitAny, noUncheckedIndexedAccess, and any other option that moves the compiler towards the stricter end of the type checking spectrum.

📃 Motivating Example

// These, and maybe more, have cleaner, less error prone and more capable alternatives,
// and seem to completely lack actual use cases among open or closed TS issues:
const foo = () => class Foo {}
const bar = class Bar {}

// Write this instead:
class Foo {}
class Bar {}

// For whatever use case, this then still achieves the same goal:
const foo = () => Foo;
const bar = Bar;

// Opting out of `disallowClassExpressions` via typing,
// something that tells the compiler that class assignment is expected.
// Maybe, maybe not. ts expect error might be safer than conflating expressions with assignability.
const foo: () => new () => any = () => class {};
const bar: new () => any = class {};

💻 Use Cases

1. What do you want to use this for?

   Preventing runtime errors/overhead (TS design goal 1)

2. What shortcomings exist with current approaches?

   Without this option, some authors tend to confuse "bad code" with compiler limitations, more often than actually hitting a compiler limitation/bug.

3. What workarounds are you using in the meantime?

   manual maintenance, maybe custom linter rules.

Edit: Stumbled upon a situation that would render this option less useful than I initially imagined it to be. Being scoped to expressions, it would have no effect on declarations in closures (which should be in scope according to the motivating examples). Set aside that some already consider it to be out of scope, as stated, it wouldn't do what the name suggests (bad) or is less effective than it should be.

[krryan]

This feels like a linting thing, not a compiler thing. What’s the rationale for putting it in the compiler?

[valler]

Maybe, maybe not. I leave drawing the line between linter and type checker to others. The rationale would be analogues to why the other mentioned options exist in tsc and weren't delegated to linters. If runtime errors/exceptions alone would be the rationale, none of those options would live inside tsc. Going for tsc instead of a linter has the benefit of not having to reimplement that rule among existing linters.

Edit: Plus this option/rule is strongly correlated to compiler features/limits that, as mentioned, pop up as compiler issues, not linter rule requests. OP already mentions linters as workarounds.

[MartinJohns]

why the other mentioned options exist in tsc and weren't delegated to linters.

Legacy. From a time before linter support for TypeScript was good enough.

[valler]

Still, this is about language and an understanding of the language and its types, not about style.
A class is not a class expression and people seem to confuse one for the other on the language level.

[MartinJohns]

I disagree. TypeScript not being smart enough in some cases is not a good case to limit the syntax that's supported. This is in no way in the same realm as strict.

Besides, ESLint already supports this check. The no-restricted-syntax rule with the option "ClassExpression" does what you want.

ESLint playground

Of course the decision lies with the maintainers. But given that ESLint already supports it I wouldn't get my hopes up. :-)

[valler]

Linters support a lot of things type checkers support, especially those with builtin type checkers; and the compiler has a lot of features that effectively limit the syntax to achieve type safety. Writing type safe JS without TS syntax limitations/additions would look a lot different. There's a ton of "you should use a type guard instead", "use loops over iterator methods", or the exact opposite of the latter, etc; at the same time some/many of those features exist the way they are, because of feasibility, not because they're syntactically or structurally ideal in relation to JS.

[valler]

Of course the decision lies with the maintainers. But given that ESLint already supports it I wouldn't get my hopes up. :-)

I'd rather see it dismissed than not having suggested it 😄 First of all, TS is a language, not a compiler, and its features and design are primarily guided in relation to JS, not some other package(s). Given state of the art tooling your argument renders tsc as a whole obsolete, leaving nothing but a language spec (which these days does not even exist anymore), when in fact it's the baseline.

TypeScript not being smart enough in some cases is not a good case to limit the syntax that's supported.

It's not about tsc being smart or capable. It's about authors. Meaning, you want that option, with or without current declaration file limitations. You don't want classes in closures for roughly the same reason you don't want to index into static interfaces treating them as maps.

[RyanCavanaugh]

I don't see how this improves the situation at all, frankly. If someone's trying to shoehorn in a class expression to solve a problem, the existence of this compiler option among the dozens of others isn't going to stop them, nor sate them if they encountered a design limitation.

[valler]

Thanks for reviewing @RyanCavanaugh

the existence of this compiler option among the dozens of others isn't going to stop them

That is true for the language as a whole, yet the language does seem to improve the situation for its users. Just sayin'.

nor sate them if they encountered a design limitation

Not the intent, although it may help to not encounter them in the first place, for as long as they exist.

[valler]

Stumbled upon a situation that would render this option less useful than I initially imagined it to be. Being scoped to expressions, it would have no effect on declarations in closures (which should be in scope according to the motivating examples). Set aside that some already consider it to be out of scope, as stated, it wouldn't do what the name suggests (bad) or is less effective than it should be.