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
docs: Add private class features info to no-underscore-dangle #17386
docs: Add private class features info to no-underscore-dangle #17386
Conversation
✅ Deploy Preview for docs-eslint ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
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 looking at this. I've left some notes to clean this up a bit but I like the direction.
14071a0
to
cec536d
Compare
Put the history back in, but tried to tighten it up a bit. Put the Private class features notice in an |
8582d83
to
49e273a
Compare
49e273a
to
f126324
Compare
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.
LGTM. Thanks.
Prerequisites checklist
What is the purpose of this pull request? (put an "X" next to an item)
[X] Documentation update
[ ] Bug fix (template)
[ ] New rule (template)
[ ] Changes an existing rule (template)
[ ] Add autofix to a rule
[ ] Add a CLI option
[ ] Add something to the core
[ ] Other, please explain:
What changes did you make? (Give an overview)
no-underscore-dangle
docs currently state that 'JavaScript doesn’t have truly private members' and go into detail around the history of underscored identifiers.Since ES2022/ES13 brought in truly private members, I've slimmed down the historical context and added info about private members and a recommendation to use them instead of underscored identifiers.
Is there anything you'd like reviewers to focus on?
I removed the historical context because it seems less relevant now that actual private fields can be recommended, but I can restore it if you think it still provides useful context.
As a follow-up, would a proposal for a new rule that highlights leading-underscore members and suggests they be refactored as private members be reasonable? Or should that perhaps be rolled into this rule to prevent any overlap?