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

Enforces getter/setter pairs in classes (accessor-pairs) #1415

Closed
feross opened this issue Sep 14, 2019 · 3 comments
Closed

Enforces getter/setter pairs in classes (accessor-pairs) #1415

feross opened this issue Sep 14, 2019 · 3 comments

Comments

@feross
Copy link
Member

feross commented Sep 14, 2019

https://eslint.org/docs/rules/accessor-pairs

Add the enforceForClassMembers option to the accessor-pairs rule.

Current rule:

    "accessor-pairs": "error",

Proposed rule:

"accessor-pairs": ["error", { "setWithoutGet": true, "enforceForClassMembers": true }],

enforceForClassMembers

By default, this rule does not enforce getter/setter pairs in class declarations and class expressions,
as the default value for enforceForClassMembers is false.

When enforceForClassMembers is set to true:

  • "setWithoutGet": true will also warn for setters without getters in classes.

Examples of incorrect code for { "setWithoutGet": true, "enforceForClassMembers": true }:

/*eslint accessor-pairs: ["error", { "setWithoutGet": true, "enforceForClassMembers": true }]*/

class Foo {
    set a(value) {
        this.val = value;
    }
}

const Bar = class {
    static set a(value) {
        this.val = value;
    }
}
@feross feross added this to the standard 15 milestone Sep 14, 2019
@mightyiam
Copy link
Member

I can think of at least one legit use case of using setters without getters. For example, in a test, where you pass a test object into some API that mutates it by assigning to its properties. If what you cared about is the order and perhaps timing of the mutations, then you could use setters to receive the values and make the assertions on that. You would not read from those properties, so there's no need for getters on those same properties. Does that sound like a legit use case?

@feross feross modified the milestones: standard 15, standard 16 Oct 22, 2020
@feross
Copy link
Member Author

feross commented Oct 29, 2020

I agree that there seem to be valid use cases that this rule would prevent, but in practice it seems that it hasn't been an issue even though it's been enabled since this rule has been present ("setWithoutGet": true is the default).

So, let's also enforce it in classes to be consistent.

@feross
Copy link
Member Author

feross commented Oct 29, 2020

0% ecosystem impact. This will ship in standard 16.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Oct 30, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
Archived in project
Development

No branches or pull requests

2 participants