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

Update: add ignoreComments option to indent rule (fixes #9018) #9752

Merged
merged 2 commits into from Dec 28, 2017

Conversation

platinumazure
Copy link
Member

What is the purpose of this pull request? (put an "X" next to item)

[ ] Documentation update
[ ] Bug fix (template)
[ ] New rule (template)
[x] Changes an existing rule (template)
[ ] Add autofixing to a rule
[ ] Add a CLI option
[ ] Add something to the core
[ ] Other, please explain:

See #9018.

What changes did you make? (Give an overview)

Added ignoreComments option (default: false) to indent rule.

Is there anything you'd like reviewers to focus on?

This seemed, um, simpler than I thought. Is there a more idiomatic way I should have done this? Any advice on how to test performance and make sure it's acceptable?

@platinumazure platinumazure added accepted There is consensus among the team that this change meets the criteria for inclusion enhancement This change enhances an existing feature of ESLint indent Relates to the `indent` rule rule Relates to ESLint's core rules labels Dec 22, 2017
Copy link
Member

@not-an-aardvark not-an-aardvark left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

Is there a more idiomatic way I should have done this?

Another option would have been to add an early return here. That would have the semantics of "just don't report this token if there would have been an error for it", whereas ignoreToken does something slightly more complex (described here). I don't think there is a difference in the case of comments (since no other tokens depend on the indentation of comments IIRC), but it seems like the ignoreToken approach is semantically closer to what we want, so I think your solution is better than that alternative.

Any advice on how to test performance and make sure it's acceptable?

You could use TIMING=1 npm run lint before and after to see if indent takes a substantially larger percentage of rule time with this change applied, when linting the ESLint codebase. I don't think this change would pose a problem, but I agree that it's a good idea to check.

Additional performance-measuring commands (probably not as useful for this case, but good to know in general):

  • npm run perf runs all rules on a large file, and times the process. (Unfortunately this benchmark has a significant amount of noise due to I/O time, and it reports significantly more errors than a typical workload -- see Improve performance benchmark #9184)
  • When refactoring Linter, I found that time npm run lint was also useful as a way to get a more realistic workload. (Since this lints the ESLint codebase itself, it could sometimes cause anomalies, e.g. if a change adds a large file, the linting time would increase because there is more text to lint, even if the change is performant. This could be avoided by ignoring the changed file.)

@@ -84,7 +84,8 @@ This rule has an object option:
* `"ObjectExpression"` (default: 1) enforces indentation level for properties in objects. It can be set to the string `"first"`, indicating that all properties in the object should be aligned with the first property. This can also be set to `"off"` to disable checking for object properties.
* `"ImportDeclaration"` (default: 1) enforces indentation level for import statements. It can be set to the string `"first"`, indicating that all imported members from a module should be aligned with the first member in the list. This can also be set to `"off"` to disable checking for imported module members.
* `"flatTernaryExpressions": true` (`false` by default) requires no indentation for ternary expressions which are nested in other ternary expressions.
* `ignoredNodes` accepts an array of [selectors](/docs/developer-guide/selectors.md). If an AST node is matched by any of the selectors, the indentation of tokens which are direct children of that node will be ignored. This can be used as an escape hatch to relax the rule if you disagree with the indentation that it enforces for a particular syntactic pattern.
* `"ignoredNodes"` accepts an array of [selectors](/docs/developer-guide/selectors.md). If an AST node is matched by any of the selectors, the indentation of tokens which are direct children of that node will be ignored. This can be used as an escape hatch to relax the rule if you disagree with the indentation that it enforces for a particular syntactic pattern.
* `"ignoreComments"` (default: false) can be used when comments do not need to be aligned with nodes on the previous or next line.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm wondering if we should document the existing comment behavior about allowing alignment with the previous/next line. It seems like this description hints at the idea, but I'm not sure if it's explained more thoroughly anywhere.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The word "comment" isn't even mentioned in the docs currently, so I would hazard a guess that there is no description of expected comment indentation. If you want me to add that to this pull request, feel free to Request Changes here.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

¯\_(ツ)_/¯ It's not a big problem, I'm fine with this being merged as-is.

@gyandeeps
Copy link
Member

what about block comments?

/* block-line comment */
    var a = 1;


/*
block comment
*/
    var a = 1;

@platinumazure
Copy link
Member Author

@gyandeeps I think this change should work for block comments too (and I think the rule currently does not check for alignment of text in later lines of the block comment, but I'll check). I'll add tests for block comments.

@not-an-aardvark Thanks, I'll do some performance tests after I make the suggested changes.

@platinumazure
Copy link
Member Author

Apologies for not leaving an update sooner. I've been doing Christmas shopping last-minute 😆

Block comments

I added basic tests for just checking the alignment of start of block comment. @gyandeeps Given you approved the PR, hopefully that looks good to you.

However, I wasn't sure if you asking about indentation/alignment of consecutive lines in a comment. If so, I haven't tested that. At the time, I was thinking multiline-comment-style should be responsible for those, but please let me know if you think differently.

That said, I don't think indent currently handles those continuing lines in block comments, so I don't particularly want to add a lot of extra logic in this PR.

Performance

I didn't capture the metrics, but I did follow @not-an-aardvark's suggestions and saw that performance was unchanged. I even tried changing our lint settings to use ignoreComments: true (and otherwise identical settings) and saw no significant change in performance.

Let me know if I should run any more tests or show some metrics.

@platinumazure
Copy link
Member Author

@eslint/eslint-team Anyone else want to review this?

Copy link
Member

@kaicataldo kaicataldo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

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

Successfully merging this pull request may close these issues.

None yet

4 participants