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

feat(eslint-plugin): [explicit-member-accessibility] suggest adding explicit accessibility specifiers #5492

Conversation

jtbandes
Copy link
Contributor

PR Checklist

Overview

This PR adds auto-fix support to explicit-member-accessibility's default mode (explicit) by automatically adding public to declarations without an existing accessibility level.

Re #4647 (comment):

If we simply autofixed every case to public then it would defeat the purpose of the rule.

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: foxglove/studio#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?

@nx-cloud
Copy link

nx-cloud bot commented Aug 17, 2022

☁️ Nx Cloud Report

CI is running/has finished running commands for commit 5471380. As they complete they will appear below. Click to see the status, the terminal output, and the build insights.

📂 See all runs for this branch


✅ Successfully ran 47 targets

Sent with 💌 from NxCloud.

@typescript-eslint
Copy link
Contributor

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.

@netlify
Copy link

netlify bot commented Aug 17, 2022

Deploy Preview for typescript-eslint ready!

Name Link
🔨 Latest commit 5471380
🔍 Latest deploy log https://app.netlify.com/sites/typescript-eslint/deploys/630635be8118fb000822c849
😎 Deploy Preview https://deploy-preview-5492--typescript-eslint.netlify.app
📱 Preview on mobile
Toggle QR Code...

QR Code

Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify site settings.

@jtbandes jtbandes changed the title feat(eslint-plugin): [explicit-member-accessibility] autofix missing accessibility feat(eslint-plugin): [explicit-member-accessibility] autofix missing accessibility by adding public Aug 17, 2022
@codecov
Copy link

codecov bot commented Aug 17, 2022

Codecov Report

Merging #5492 (6395b8f) into main (1b2601a) will increase coverage by 2.34%.
The diff coverage is 100.00%.

❗ Current head 6395b8f differs from pull request most recent head 5471380. Consider uploading reports for the commit 5471380 to get more accurate results

@@            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     
Flag Coverage Δ
unittest 93.92% <100.00%> (+2.34%) ⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files Coverage Δ
...-plugin/src/rules/explicit-member-accessibility.ts 97.43% <100.00%> (ø)
...src/configs/recommended-requiring-type-checking.ts 100.00% <0.00%> (ø)
...nt-plugin/src/rules/consistent-type-definitions.ts 97.29% <0.00%> (ø)
packages/eslint-plugin/src/rules/indent.ts 92.85% <0.00%> (ø)
packages/eslint-plugin/src/rules/unbound-method.ts 92.13% <0.00%> (ø)
...ackages/eslint-plugin/src/util/getWrappingFixer.ts 100.00% <0.00%> (ø)
...eslint-plugin/src/rules/consistent-type-exports.ts 97.70% <0.00%> (ø)
...plugin/src/rules/explicit-module-boundary-types.ts 91.04% <0.00%> (ø)
packages/eslint-plugin/src/rules/array-type.ts 97.14% <0.00%> (ø)
...ackages/eslint-plugin/src/rules/no-var-requires.ts 90.00% <0.00%> (ø)
... and 149 more

@bradzacher
Copy link
Member

bradzacher commented Aug 17, 2022

Thanks for the PR.
As per the issue - we will not be accepting autofix support for this 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.

The issue is that once you autofix to add public, then the rule no longer reports at all.
This is why I say that it defeats the purpose of the rule! If the rule doesn't report then you won't be prompted to think about the accessibility!

So if someone is paying little attention and just runs --fix then they won't ever see the lint report on the member.
Similarly if the user has autofix-on-save turned on then they will add a new member, save the file and public is auto-added - again they never see the lint report to prompt them to consider which modifier is right!

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.
That would allow people to quickly choose and add the relevant modifier with a single click.

@bradzacher bradzacher added enhancement New feature or request awaiting response Issues waiting for a reply from the OP or another party labels Aug 17, 2022
@jtbandes
Copy link
Contributor Author

jtbandes commented Aug 18, 2022

Updated to suggest 3 fixes for each error, adding public, private, and protected.

Screen.Recording.2022-08-17.at.6.41.16.PM.mov

@jtbandes
Copy link
Contributor Author

And although it's no longer relevant since I've changed them to suggestions, I just want to give my perspective on:

The issue is that once you autofix to add public, then the rule no longer reports at all.
This is why I say that it defeats the purpose of the rule! If the rule doesn't report then you won't be prompted to think about the accessibility!

There's a step where you do still notice the change: code review :)

@bradzacher bradzacher removed the awaiting response Issues waiting for a reply from the OP or another party label Aug 18, 2022
Copy link
Member

@JoshuaKGoldberg JoshuaKGoldberg left a 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! ✨

const lastDecorator = node.decorators[node.decorators.length - 1];
const nextToken = sourceCode.getTokenAfter(lastDecorator);
if (!nextToken) {
return null;
Copy link
Member

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 the nextToken does always exist

Copy link
Contributor Author

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?

Copy link
Member

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.

@JoshuaKGoldberg JoshuaKGoldberg added the awaiting response Issues waiting for a reply from the OP or another party label Aug 18, 2022
@jtbandes
Copy link
Contributor Author

Not sure what's going on with the website tests – could that be related to my changes? Seems unlikely?

@jtbandes jtbandes changed the title feat(eslint-plugin): [explicit-member-accessibility] autofix missing accessibility by adding public feat(eslint-plugin): [explicit-member-accessibility] suggest adding explicit accessibility specifiers Aug 19, 2022
@jtbandes
Copy link
Contributor Author

@JoshuaKGoldberg @bradzacher friendly ping, anything else you'd like me to change here?

@JoshuaKGoldberg
Copy link
Member

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.

Copy link
Member

@JoshuaKGoldberg JoshuaKGoldberg left a comment

Choose a reason for hiding this comment

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

@JoshuaKGoldberg JoshuaKGoldberg enabled auto-merge (squash) August 24, 2022 14:35
@JoshuaKGoldberg JoshuaKGoldberg merged commit 0edb94a into typescript-eslint:main Aug 24, 2022
@jtbandes jtbandes deleted the fix-explicit-member-accessibility branch August 24, 2022 14:48
@jtbandes
Copy link
Contributor Author

Thanks for all the review!

@bradzacher
Copy link
Member

lgtm15.jpg

crapStone pushed a commit to Calciumdibromid/CaBr2 that referenced this pull request Sep 1, 2022
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 (@&#8203;typescript-eslint/eslint-plugin)</summary>

### [`v5.35.1`](https://github.com/typescript-eslint/typescript-eslint/blob/HEAD/packages/eslint-plugin/CHANGELOG.md#&#8203;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 ([#&#8203;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#&#8203;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 ([#&#8203;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#&#8203;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 ([#&#8203;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 ([#&#8203;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) ([#&#8203;5453](typescript-eslint/typescript-eslint#5453)) ([d023910](typescript-eslint/typescript-eslint@d023910))

</details>

<details>
<summary>typescript-eslint/typescript-eslint (@&#8203;typescript-eslint/parser)</summary>

### [`v5.35.1`](https://github.com/typescript-eslint/typescript-eslint/blob/HEAD/packages/parser/CHANGELOG.md#&#8203;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 [@&#8203;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#&#8203;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 [@&#8203;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#&#8203;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 [@&#8203;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 [@&#8203;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>
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Sep 24, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
awaiting response Issues waiting for a reply from the OP or another party enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants