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.

Sign up for GitHub

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

Jump to bottom

Update: support class fields in the complexity rule (refs #14857) #14957

Merged
merged 3 commits into from
Sep 10, 2021
Merged

Update: support class fields in the complexity rule (refs #14857) #14957

merged 3 commits into from
Sep 10, 2021

Conversation

mdjermanovic
Copy link
Member

Prerequisites checklist

What is the purpose of this pull request? (put an "X" next to an 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:

refs #14857, fixes #14591 (comment)

What changes did you make? (Give an overview)

Update the complexity rule to supports class fields, in a way that the rule now treats them as functions:

  • Code in class field initializers doesn't contribute to the complexity of the enclosing code (this is a bug fix).
  • Code in class field initializers itself is checked and reported if its complexity is above the threshold (this is an enhancement).

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

  • Does everyone agree that it makes sense to report initializers?
  • Initializers are reported as just "Class field initializer", without referring to the property name. We could add a utility function similar to getFunctionNameWithKind later as an enhancement.

@mdjermanovic mdjermanovic added bug ESLint is working incorrectly enhancement This change enhances an existing feature of ESLint rule Relates to ESLint's core rules accepted There is consensus among the team that this change meets the criteria for inclusion labels Aug 21, 2021
@mdjermanovic mdjermanovic mentioned this pull request Aug 21, 2021
Closed
32 tasks
@mdjermanovic
Copy link
Member Author

I believe this can be done better with onCodePathStart()/onCodePathEnd(), so I'll try to refactor the code after we merge #14886.

It's also quite possible that the rule could be entirely refactored to use only the code path analysis info when calculating the complexity as well, but that would require extensive testing.

@mdjermanovic mdjermanovic marked this pull request as draft August 22, 2021 13:57
@mdjermanovic mdjermanovic force-pushed the complexity-classfields branch from b851e2b to 7f86df8 Compare August 27, 2021 12:40
@mdjermanovic mdjermanovic marked this pull request as ready for review August 27, 2021 13:02
@mdjermanovic
Copy link
Member Author

Updated the code to use the new code path analysis, and I think this looks better now.

@mdjermanovic mdjermanovic mentioned this pull request Sep 2, 2021
Closed
@nzakas
Copy link
Member

nzakas commented Sep 10, 2021

Does everyone agree that it makes sense to report initializers?

Agree

nzakas
nzakas approved these changes Sep 10, 2021
View reviewed changes
Copy link
Member

@nzakas nzakas left a comment

Choose a reason for hiding this comment

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

LGTM. I think adding the class field name would be a great enhancement but not necessary for this first pass.

lib/rules/complexity.js
* to the enclosing function's complexity, but their own complexity should be evaluated.
*/
if (
codePath.origin !== "function" &&
Copy link
Member

Choose a reason for hiding this comment

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

This came in handy! 🎉

Copy link
Member Author

Choose a reason for hiding this comment

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

Very! This could have been done in other ways, but it wouldn't look as nice and simple - it would be always difficult to trace what's happening when the initializer is a function.

@mdjermanovic
Copy link
Member Author

closing-reopening to see if that will fix the EasyCLA check.

@mdjermanovic mdjermanovic reopened this Sep 10, 2021
@mdjermanovic
Copy link
Member Author

All checks are green now, so merging.

@mdjermanovic mdjermanovic merged commit 88a3952 into master Sep 10, 2021
@mdjermanovic mdjermanovic deleted the complexity-classfields branch September 10, 2021 10:59
@eslint-github-bot eslint-github-bot bot locked and limited conversation to collaborators Mar 10, 2022
@eslint-github-bot eslint-github-bot bot added the archived due to age This issue has been archived; please open a new issue for any further discussion label Mar 10, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Reviewers

@nzakas nzakas nzakas approved these changes

Assignees
No one assigned
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 bug ESLint is working incorrectly enhancement This change enhances an existing feature of ESLint rule Relates to ESLint's core rules
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
2 participants
@mdjermanovic @nzakas