Stylistic rules can be very useful to set a standard that's consistent in your code base to help people learning and move between projects, but they make it a more difficult to transition an existing code base, and also makes TypeScript less approachable to beginners. I've seen StackOverflow questions with people writing "Please help me fix this TypeScript issue, I can't commit!" when it's actually just a stylistic lint error.

For this reason (I assume), the defaulteslint:recommended config is quite slim, and it would be nice if@typescript-eslint follows a similar standard for what's recommended.

Even just following the current documentation for the recommended rules would be a nice start 😃

1. They help you adhere to TypeScript best practices.
2. They help catch probable issue vectors in your code.

Stylistic rules

I think these rules should be removed fromrecommended with the 2.0 release. They do not have any effect on the runtime behaviour or type checking of your code (e.g. do not catch issue vectors in your code, and I would not consider something like specific indentation to be a TypeScript best practice)

• @typescript-eslint/array-type
• @typescript-eslint/camelcase
• @typescript-eslint/class-name-casing
• @typescript-eslint/indent
• @typescript-eslint/type-annotation-spacing
• @typescript-eslint/interface-name-prefix
• @typescript-eslint/member-delimiter-style
• @typescript-eslint/no-inferrable-types

"Best practices"

These could be considered best practices by some, but are still quite opinionated so it would be nice to take 2.0 as an opportunity to consider if all rules really are suitable forrecommended.

• @typescript-eslint/explicit-member-accessibility - I personally use this in most projects, but accessibility is optional in TypeScript for a reason so it's more of a matter of preference and opinion rather than a general "TypeScript best practice"
• @typescript-eslint/explicit-function-return-type - SettingallowTypedFunctionExpressions: true as default will help, but it is very unergonomic to use right now.
• @typescript-eslint/no-array-constructor - corresponding rule is not enabled in eslint-recommended
• @typescript-eslint/no-non-null-assertion - the ! operator is a useful escape hatch, having to workaround it leads to a lot more code that is more difficult to understand
• @typescript-eslint/no-object-literal-type-assertion

I hope that a change like this would A) help drive adoption of the project and the very important and relevant rules that would still be left inrecommended, B) avoid driving away beginners that just select "defaults" / "recommended" from the TypeScript ecosystem by overly strict rules that are mostly relevant in some specific code bases.

Thanks!