-
-
Notifications
You must be signed in to change notification settings - Fork 2.8k
feat(eslint-plugin): [explicit-member-accessibility] suggest adding explicit accessibility specifiers #5492
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
feat(eslint-plugin): [explicit-member-accessibility] suggest adding explicit accessibility specifiers #5492
Conversation
Thanks for the PR, @jtbandes! typescript-eslint is a 100% community driven project, and we are incredibly grateful that you are contributing to that community. The core maintainers work on this in their personal time, so please understand that it may not be possible for them to review your work immediately. Thanks again! 🙏 Please, if you or your company is finding typescript-eslint valuable, help us sustain the project by sponsoring it transparently on https://opencollective.com/typescript-eslint. As a thank you, your profile/company logo will be added to our main README which receives thousands of unique visitors per day. |
✅ Deploy Preview for typescript-eslint ready!
To edit notification comments on pull requests, go to your Netlify site settings. |
public
Codecov Report
@@ Coverage Diff @@
## main #5492 +/- ##
==========================================
+ Coverage 91.57% 93.92% +2.34%
==========================================
Files 132 290 +158
Lines 1496 10024 +8528
Branches 226 3016 +2790
==========================================
+ Hits 1370 9415 +8045
- Misses 62 330 +268
- Partials 64 279 +215
Flags with carried forward coverage won't be shown. Click here to find out more.
|
Thanks for the PR.
The issue is that once you autofix to add So if someone is paying little attention and just runs We don't want this rule to have a fixer that people use to codemod their codebase (like you did in your linked PR) - lint features last forever and need to support the normal, non-codemod usecase. If you'd like to make this a suggestion fixer - I'm happy to accept that. We could have a suggestion fixer for each of the accessibility modifiers. |
Updated to suggest 3 fixes for each error, adding Screen.Recording.2022-08-17.at.6.41.16.PM.mov |
And although it's no longer relevant since I've changed them to suggestions, I just want to give my perspective on:
There's a step where you do still notice the change: code review :) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Started reviewing and found blockers in the codecov report and unifying the message IDs. Left a few other questions too 🙂 . I'll review in more detail (so many new lines of test code! yay!) once those are answered. Thanks for sending this in! ✨
packages/eslint-plugin/src/rules/explicit-member-accessibility.ts
Outdated
Show resolved
Hide resolved
const lastDecorator = node.decorators[node.decorators.length - 1]; | ||
const nextToken = sourceCode.getTokenAfter(lastDecorator); | ||
if (!nextToken) { | ||
return null; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We generally expect most new code -and ideally all new rule code- to be covered by tests. Codecov is rightfully showing here that this isn't. One of two cases is true:
- This case can be tested and should be
- This case is impossible and the type system is wrong
- Meaning: use a
!
to show that thenextToken
does always exist
- Meaning: use a
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I expect it is probably impossible, because I can't think of any situation where there wouldn't be any tokens after the last decorator, but it feels wrong to simply !
the output of getTokenAfter
just because I believe that (perhaps erroneously), so I was trying to code defensively. But that also means I can't think of any test cases to add test coverage here. What would you recommend doing?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I say !
it. If there are decorators they must be decorating something for this to be valid syntax.
In an ideal world, sourceCode.getTokenAfter
would know that if it's given a node that must have an after, the returned token is defined. If we eventually get rich enough types the !
will be linted as unnecessary.
packages/eslint-plugin/src/rules/explicit-member-accessibility.ts
Outdated
Show resolved
Hide resolved
packages/eslint-plugin/tests/rules/explicit-member-accessibility.test.ts
Outdated
Show resolved
Hide resolved
Co-authored-by: Josh Goldberg <git@joshuakgoldberg.com>
…y' into fix-explicit-member-accessibility
Not sure what's going on with the website tests – could that be related to my changes? Seems unlikely? |
public
@JoshuaKGoldberg @bradzacher friendly ping, anything else you'd like me to change here? |
Nope this looks great, thanks! Re the website tests: 🤷 I have given up on them. They do what they want to do. We have no power here. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
✨
Thanks for all the review! |
This PR contains the following updates: | Package | Type | Update | Change | |---|---|---|---| | [@typescript-eslint/eslint-plugin](https://github.com/typescript-eslint/typescript-eslint) | devDependencies | minor | [`5.33.1` -> `5.35.1`](https://renovatebot.com/diffs/npm/@typescript-eslint%2feslint-plugin/5.33.1/5.35.1) | | [@typescript-eslint/parser](https://github.com/typescript-eslint/typescript-eslint) | devDependencies | minor | [`5.33.1` -> `5.35.1`](https://renovatebot.com/diffs/npm/@typescript-eslint%2fparser/5.33.1/5.35.1) | --- ### Release Notes <details> <summary>typescript-eslint/typescript-eslint (@​typescript-eslint/eslint-plugin)</summary> ### [`v5.35.1`](https://github.com/typescript-eslint/typescript-eslint/blob/HEAD/packages/eslint-plugin/CHANGELOG.md#​5351-httpsgithubcomtypescript-eslinttypescript-eslintcomparev5350v5351-2022-08-24) [Compare Source](typescript-eslint/typescript-eslint@v5.35.0...v5.35.1) ##### Bug Fixes - **eslint-plugin:** correct rule schemas to pass ajv validation ([#​5531](typescript-eslint/typescript-eslint#5531)) ([dbf8b56](typescript-eslint/typescript-eslint@dbf8b56)) ### [`v5.35.0`](https://github.com/typescript-eslint/typescript-eslint/blob/HEAD/packages/eslint-plugin/CHANGELOG.md#​5350-httpsgithubcomtypescript-eslinttypescript-eslintcomparev5340v5350-2022-08-24) [Compare Source](typescript-eslint/typescript-eslint@v5.34.0...v5.35.0) ##### Features - **eslint-plugin:** \[explicit-member-accessibility] suggest adding explicit accessibility specifiers ([#​5492](typescript-eslint/typescript-eslint#5492)) ([0edb94a](typescript-eslint/typescript-eslint@0edb94a)) ### [`v5.34.0`](https://github.com/typescript-eslint/typescript-eslint/blob/HEAD/packages/eslint-plugin/CHANGELOG.md#​5340-httpsgithubcomtypescript-eslinttypescript-eslintcomparev5331v5340-2022-08-22) [Compare Source](typescript-eslint/typescript-eslint@v5.33.1...v5.34.0) ##### Bug Fixes - **eslint-plugin:** \[no-useless-constructor] handle parameter decorator ([#​5450](typescript-eslint/typescript-eslint#5450)) ([864dbcf](typescript-eslint/typescript-eslint@864dbcf)) ##### Features - **eslint-plugin:** \[prefer-optional-chain] support suggesting `!foo || !foo.bar` as a valid match for the rule ([#​5266](typescript-eslint/typescript-eslint#5266)) ([aca935c](typescript-eslint/typescript-eslint@aca935c)) #### [5.33.1](typescript-eslint/typescript-eslint@v5.33.0...v5.33.1) (2022-08-15) ##### Bug Fixes - missing placeholders in violation messages for `no-unnecessary-type-constraint` and `no-unsafe-argument` (and enable `eslint-plugin/recommended` rules internally) ([#​5453](typescript-eslint/typescript-eslint#5453)) ([d023910](typescript-eslint/typescript-eslint@d023910)) </details> <details> <summary>typescript-eslint/typescript-eslint (@​typescript-eslint/parser)</summary> ### [`v5.35.1`](https://github.com/typescript-eslint/typescript-eslint/blob/HEAD/packages/parser/CHANGELOG.md#​5351-httpsgithubcomtypescript-eslinttypescript-eslintcomparev5350v5351-2022-08-24) [Compare Source](typescript-eslint/typescript-eslint@v5.35.0...v5.35.1) **Note:** Version bump only for package [@​typescript-eslint/parser](https://github.com/typescript-eslint/parser) ### [`v5.35.0`](https://github.com/typescript-eslint/typescript-eslint/blob/HEAD/packages/parser/CHANGELOG.md#​5350-httpsgithubcomtypescript-eslinttypescript-eslintcomparev5340v5350-2022-08-24) [Compare Source](typescript-eslint/typescript-eslint@v5.34.0...v5.35.0) **Note:** Version bump only for package [@​typescript-eslint/parser](https://github.com/typescript-eslint/parser) ### [`v5.34.0`](https://github.com/typescript-eslint/typescript-eslint/blob/HEAD/packages/parser/CHANGELOG.md#​5340-httpsgithubcomtypescript-eslinttypescript-eslintcomparev5331v5340-2022-08-22) [Compare Source](typescript-eslint/typescript-eslint@v5.33.1...v5.34.0) **Note:** Version bump only for package [@​typescript-eslint/parser](https://github.com/typescript-eslint/parser) #### [5.33.1](typescript-eslint/typescript-eslint@v5.33.0...v5.33.1) (2022-08-15) **Note:** Version bump only for package [@​typescript-eslint/parser](https://github.com/typescript-eslint/parser) </details> --- ### Configuration 📅 **Schedule**: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined). 🚦 **Automerge**: Disabled by config. Please merge this manually once you are satisfied. ♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox. 🔕 **Ignore**: Close this PR and you won't be reminded about these updates again. --- - [x] <!-- rebase-check -->If you want to rebase/retry this PR, click this checkbox. --- This PR has been generated by [Renovate Bot](https://github.com/renovatebot/renovate). <!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiIzMi4xNjkuMSIsInVwZGF0ZWRJblZlciI6IjMyLjE3My4wIn0=--> Co-authored-by: cabr2-bot <cabr2.help@gmail.com> Co-authored-by: Epsilon_02 <epsilon_02@noreply.codeberg.org> Reviewed-on: https://codeberg.org/Calciumdibromid/CaBr2/pulls/1519 Reviewed-by: Epsilon_02 <epsilon_02@noreply.codeberg.org> Co-authored-by: Calciumdibromid Bot <cabr2_bot@noreply.codeberg.org> Co-committed-by: Calciumdibromid Bot <cabr2_bot@noreply.codeberg.org>
PR Checklist
openissue: This PR addresses [explicit-member-accessibility] "explicit" option suggestions #4647 (cc @alumni), but the issue was closed.Overview
This PR adds auto-fix support to
explicit-member-accessibility
's default mode (explicit
) by automatically addingpublic
to declarations without an existing accessibility level.Re #4647 (comment):
I disagree that it defeats the purpose of the rule: the purpose is to make developers think explicitly about accessibility levels, and auto-adding
public
makes it obvious that the default accessibility is public.I tested out this change on a large TS codebase: https://github.com/foxglove/studio/pull/4164
Another option, if you find this auto-fix undesirable, would be to make it a suggestion instead of a fix. What do you think?