Before You File a Documentation Request Please Confirm You Have Done The Following...

• I have looked for existingopen or closed documentation requests that match my proposal.
• I haveread the FAQ and my problem is not listed.

Suggested Changes

Right now the rule just quotes TSLint's old docs as evidence:

Users who come from a Java-style OO language may wrap their utility functions in an extra class, instead of putting them at the top level.

...but it doesn't explainwhy wrapping utility functions in an extra class is unnecessary or even bad.

In summary:

• Wrapper classes add extra runtime bloat and cognitive complexity to code without adding any structural improvements
  • Whatever would be put on them, such as utility functions, is already organized by virtue of the module it's in.
  • You can alwaysimport * as ... the module to get all of them in a single object.
• IDEs can't provide as good autocompletions when you start typing the names of the helpers, since they're on a class instead of freely available to import
• It's harder to statically analyze code for unused variables, etc. when they're all on the class (see:ts-prune).

IME, this kind of class structure often comes up and is later regretted with teams that are used to adhering to OOP principles but then work in a runtime (e.g. Node) and project type (e.g. Express) that don't need them. They eventually get used to using ECMAScript modules as their form of organization, and find the extra classes to be unnecessary bloat.

Affected URL(s)

https://typescript-eslint.io/rules/no-extraneous-class