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

New rule proposal: compact-accessor #12277

Closed
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 feature This change adds a new feature to ESLint rule Relates to ESLint's core rules

Comments

@mdjermanovic
Copy link
Member

Please describe what the rule should do:

If an accessor property has both getter and setter functions, this rule requires their definitions to be one after another in object literals/class definitions.

Optionally, the rule can require their order (get before set, or set before get).

What category of rule is this? (place an "X" next to just one item)

[X] Enforces code style (layout)

Provide 2-3 code examples that this rule will warn about:

/* eslint compact-accessor:error*/
var foo = {
    get a(){},
    bar: 5,
    set a(val){}
};

var foo = {
    get a(){},
    ...bar,
    set a(val){}
}

class foo {
    get a(){}
    bar(){}
    set a(val){}
}
/* eslint compact-accessor:["error", "getBeforeSet"]*/
var foo = {
    set a(val){},
    get a(){}
}

class foo {
    set a(val){}
    get a(){}
}

Why should this rule be included in ESLint (instead of a plugin)?

While it is allowed, I don't think there is a real use case for non-consecutive definitions of accessor functions for the same property, and it should be a best practice to avoid this feature. Also, the additional option can enforce a consistent style (e.g., get before set).

I'm not sure about the rule's name, there could be a better word than compact for this.

Notes:

  • The rule does not enforce the existence of the pair for a getter/setter (that's accessor-pairs).
  • The rule does not require grouping of all accessor properties at the same place, it works with each individually.
  • If a property has a duplicate getter or setter, such property will be ignored by this rule and caught by other rules (no-dupe-keys and no-dupe-class-members)

Problem: This rule is overlapping with sort-keys. But, one might want to enforce this without sorting. Also, sort-keys doesn't work with classes and doesn't enforce get/set order.

Are you willing to submit a pull request to implement this rule?

Yes.

@mdjermanovic mdjermanovic added rule Relates to ESLint's core rules feature This change adds a new feature to ESLint evaluating The team will evaluate this issue to decide whether it meets the criteria for inclusion labels Sep 17, 2019
@mdjermanovic mdjermanovic self-assigned this Sep 17, 2019
@ilyavolodin
Copy link
Member

I think it's a reasonable rule to add. But would need a different name, compact-accessors doesn't really describe it well. Maybe paired-accessors?

@kaicataldo
Copy link
Member

I like paired-accessors!

@ilyavolodin ilyavolodin 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 Sep 25, 2019
@ljharb
Copy link
Sponsor Contributor

ljharb commented Sep 25, 2019

They're already paired because they have the same property name; this seems more like grouped-accessors.

@mdjermanovic
Copy link
Member Author

I don't like compact-accessors name much, too.

paired-accessors looks good, though it might imply enforcing the existence of the pair? Also, there is already the accessor-pairs rule, so two similar names could be confusing?

grouped-accessors also looks good, but it could be interpreted as enforcing all accessor properties (different names) to be defined at the same place?

Maybe connected-accessor-functions?

@ljharb
Copy link
Sponsor Contributor

ljharb commented Sep 25, 2019

grouped-accessor-pairs?

@mdjermanovic
Copy link
Member Author

grouped-accessor-pairs?

This sounds to me like a very good name for this purpose. If its apparent similarity with the existing name accessor-pairs isn't a problem.

@mdjermanovic
Copy link
Member Author

I'll work on this over the weekend, should be ready for review soon.

@ljharb
Copy link
Sponsor Contributor

ljharb commented Sep 28, 2019

#12331

@eslint-deprecated eslint-deprecated bot locked and limited conversation to collaborators May 22, 2020
@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 May 22, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.