[indent][meta issue] Problems with the indent rule

[bradzacher]

STOP! DO NOT FILE ANY NEW ISSUES ABOUT THE INDENT RULE

Your specific indent bug might not have an issue created. That does not matter. Don't file a new issue. If you raise an issue we will just close it and reference this issue.
Please don't waste our time by doing that.

The rule is broken and telling us different ways in which it is broken doesn't change the fact that it is broken.

For the same reason - please don't comment on this issue with bug reports.

---

TL;DR - the indent rule is broken on TypeScript codebases. Due to bandwidth constraints it will remain broken indefinitely unless the community is able to step up to fix it.

The Problem

Many of you that have used our indent extension rule have quickly run into problems with it.

It incorrectly handles many cases that seem trivial, or it handles a block of code in one form, but breaks when you put in a new line. There are unfortunately a myriad of issues with it.

So when I first implemented it over a year ago (bradzacher/eslint-plugin-typescript#219), I took a very naive approach to solving the problem - I made TypeScript nodes look like JavaScript nodes, and called existing handlers in the base rule's implementation.

This worked well enough for simple cases, but was quickly discovered to be a terrible solution due to the complexity of TypeScript and the myriad ways in which its constructs can be nested and combined, and also in how users expect each combination to be indented by default.

So I began the process of forking the base rule codebase by copying it over and adding types (#439). I had grand plans to implement every single TypeScript node in this fork, so we could support it fully. This was another naive thought, as it quickly dawned on me how complex the rule's implementation is, and how difficult it is to handle every single variation of each node.

For example, take a simple union type:

   type T = foo | bar
//          ^^^^^^^^^ expected indent = 0

   type T = foo
//          ^^^ expected indent = 0
     | bar
//   ^^^^^ expected indent = 1

   type T = 
     foo
//   ^^^ expected indent = 1
     | bar
//   ^^^^^ expected indent = 1

   type T =
     | foo
//   ^^^^^ expected indent = 1
     | bar
//   ^^^^^ expected indent = 1
    
   type T = | foo
//          ^^^^^ expected indent = 0
     | bar
//   ^^^^^ expected indent = 1

Then there's the notion of configurability for this, which add more complexity.

The base rule has had ~5 years to grow via the community (though it was mostly a few dedicated contributors) - a community that actively uses the rule, and has motivation to use the rule because the problems cause issues for them.

A few years ago, I (like most of the maintainers) made the switch for all of my projects across to prettier. For me, this was spurred by my move to working at facebook, and learning to love the package and everything it does.
This means that I haven't used the rule since then, and I have no personal motivation as a volunteer maintainer to spend the many hours it will take to build this out, and as a maintainer there are many higher-priority issues (such as parsing perf) that need attention.
As such, the rule has languished, and many issues are open.

The Solution

The rule is in a broken state. Many users are working around it via ESLint disable comments, and configuring certain nodes as ignored; both of which are poor experiences.

We as maintainers have our hands full maintaining other core infra as well as triaging issues and reviewing PRs, so we don't have the bandwidth to take on this project.

We'd love it if some members of the community could help us out here by submitting some PRs to support TS nodes in the rule fork. Unfortunately, without some champions, the rule will not progress forward or be fixed.

Not to discourage anyone, but as a forewarning: there are some 2,100 lines of code already, and that just constitutes the typechecked fork of the base rule. The codebase contains some rather complex algorithms, and has a lot of moving parts. It will be no small undertaking to understand what it's doing, and how it's doing it.

[500-internal-server-error]

Hello, given that this page mentions the following:

Per ESLint's 2020 Changes to Rule Policies blog post, ESLint itself has moved away from stylistic rules, including formatting rules:

Stylistic rules are frozen - we won't be adding any more options to stylistic rules. We've learned that there's no way to satisfy everyone's personal preferences, and most of the rules already have a lot of difficult-to-understand options. Stylistic rules are those related to spacing, conventions, and generally anything that does not highlight an error or a better way to do something.

We support the ESLint team's decision and backing logic to move away from formatting and stylistic rules. With the exception of bug fixes, no new formatting- or stylistic-related pull requests will be accepted into typescript-eslint.

Is fixing this rule still being worked on / actively supported?

Thanks in advance.

[bradzacher]

Given this issue has been open for 3 years with no community member pitching in (which is understandable!) - it's clear that this rule is not going to be fixed here.

Following on from eslint/eslint#17522
ESLint is moving to deprecate and remove formatting rules - meaning rules like indent will be moved to the community domain. We will follow suit when they do as well and will similarly deprecate our formatting rules.

With those two signals - I am going to lock this issue to prevent any further comments, and we shall not be accepting any PRs to fix the rule. I'll leave this open so it shows up in search, but consider it functionally closed.

If you need further assistance with the rule - please consider posting on stackoverflow or similar.