Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow arbitrary nodes to be ignored in the indent rule #8594

Closed
not-an-aardvark opened this issue May 14, 2017 · 0 comments
Closed

Allow arbitrary nodes to be ignored in the indent rule #8594

not-an-aardvark opened this issue May 14, 2017 · 0 comments
Assignees
Labels
accepted There is consensus among the team that this change meets the criteria for inclusion archived due to age This issue has been archived; please open a new issue for any further discussion enhancement This change enhances an existing feature of ESLint indent Relates to the `indent` rule rule Relates to ESLint's core rules

Comments

@not-an-aardvark
Copy link
Member

Problem

People have lots of different indentation preferences, and the indent rule can't realistically support all of them. With other rules, we generally encourage people to make a plugin if they want to enforce their specific preferences, which implies disabling the core rule and using the rule from the plugin instead.

However, the indent rule is big and complicated, and if a user wants to disable it in favor of their plugin, then the plugin needs to reimplement the entire rule. This adds a very large maintenance burden.

Proposal

What rule do you want to change?

indent

Does this change cause the rule to produce more or fewer warnings?

By default, it produces the same amount.

How will the change be implemented? (New option, new default behavior, etc.)?

This change adds an ignoredNodes option to the rule, which is an array of AST selectors. Any nodes matching those selectors will be treated the same way as unknown node types -- the indentation of their direct children will be ignored, but the indentation of nested children will still be enforced relative to each other.

Please provide some example code that this change will affect:

/* eslint indent: [
    error,
    4,
    {
        ignoredNodes: ["VariableDeclarator[kind='const']"]
    }
] */

const foo = 1,
      bar = 2,
      baz = 3,
      qux = function() {
          return;
      };

What does the rule currently do for this code?

The rule reports an error because it enforces a style where bar, baz, and qux are indented incorrectly. (We have gotten several feature requests to allow a style like this.)

What will the rule do after it's changed?

The rule will ignore the indentation of bar, baz, and qux, but it will still enforce the alignment of the return statement with qux. This would allow someone to write a plugin that just checks the indentation of bar, baz, and qux, without reimplementing the indentation logic for anything else.

@not-an-aardvark not-an-aardvark added enhancement This change enhances an existing feature of ESLint evaluating The team will evaluate this issue to decide whether it meets the criteria for inclusion indent Relates to the `indent` rule rule Relates to ESLint's core rules labels May 14, 2017
@not-an-aardvark not-an-aardvark added this to Needs Discussion in v4.0.0 May 14, 2017
@not-an-aardvark not-an-aardvark self-assigned this May 14, 2017
@not-an-aardvark not-an-aardvark added accepted There is consensus among the team that this change meets the criteria for inclusion and removed evaluating The team will evaluate this issue to decide whether it meets the criteria for inclusion labels May 15, 2017
@not-an-aardvark not-an-aardvark moved this from Needs Discussion to Accepted & In Progress in v4.0.0 May 15, 2017
@not-an-aardvark not-an-aardvark removed this from Accepted & In Progress in v4.0.0 Jun 4, 2017
tophf added a commit to openstyles/stylus that referenced this issue Jul 3, 2017
Until eslint/eslint#8594 is sorted out, we're switching to the old indent behavior (indent-legacy).
tophf added a commit to openstyles/stylus that referenced this issue Jul 6, 2017
Until eslint/eslint#8594 is sorted out, we're switching to the old indent behavior (indent-legacy).
tophf added a commit to openstyles/stylus that referenced this issue Jul 9, 2017
Until eslint/eslint#8594 is sorted out, we're switching to the old indent behavior (indent-legacy).
not-an-aardvark added a commit that referenced this issue Aug 14, 2017
This adds an option to the `indent` rule to allow the indentation checking for an arbitrary node type to be ignored, as described in #8594. This should make it easier for users to use the `indent` rule even if they think a different indentation should be enforced for a particular node type.
not-an-aardvark added a commit that referenced this issue Aug 14, 2017
This adds an option to the `indent` rule to allow the indentation checking for an arbitrary node type to be ignored, as described in #8594. This should make it easier for users to use the `indent` rule even if they think a different indentation should be enforced for a particular node type.
futagoza added a commit to futagoza/eslint-config-futagozaryuu that referenced this issue Aug 24, 2017
@eslint-deprecated eslint-deprecated bot locked and limited conversation to collaborators Feb 18, 2018
@eslint-deprecated eslint-deprecated bot added the archived due to age This issue has been archived; please open a new issue for any further discussion label Feb 18, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
accepted There is consensus among the team that this change meets the criteria for inclusion archived due to age This issue has been archived; please open a new issue for any further discussion enhancement This change enhances an existing feature of ESLint indent Relates to the `indent` rule rule Relates to ESLint's core rules
Projects
None yet
Development

No branches or pull requests

1 participant