-
-
Notifications
You must be signed in to change notification settings - Fork 2.8k
fix(eslint-plugin): [class-literal-property-style] correct handling of override cases #5983
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
Conversation
Thanks for the PR, @sviat9440! 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. |
✅ Deploy Preview for typescript-eslint ready!
To edit notification comments on pull requests, go to your Netlify site settings. |
|
9674865
to
0e63dd7
Compare
Codecov Report
Additional details and impacted files@@ Coverage Diff @@
## main #5983 +/- ##
==========================================
- Coverage 91.52% 91.51% -0.02%
==========================================
Files 371 371
Lines 12649 12643 -6
Branches 3714 3714
==========================================
- Hits 11577 11570 -7
Misses 755 755
- Partials 317 318 +1
Flags with carried forward coverage won't be shown. Click here to find out more.
|
Strongly disagree with this change. It's not worth locking the rule into type information and restricting many people from using it just to prevent a really, really rare false-positive. As per the comments on #5962 - the change we would accept is making the fixer a suggestion fixer so that the rule cannot automatically fix and break code.
Making rules conditionally dependent on type information is not something we really like doing in this project. Most users struggle with understanding config as it is, and adding extra forks to rules dependent on certain configs that are separate to the rule's configs further complicates things. |
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.
Blocked on #5961 passing triage. Also what Brad said. 😄
Edit: now just what Brad said.
Ping @sviat9440 - is this something you have the time to work on? No worries if not, just checking in - thanks! |
@JoshuaKGoldberg I'll take a look this weekend |
aca7b04
to
f719f93
Compare
f719f93
to
ea4fdcc
Compare
[prefer-optional-chain] A literal getter with a setter does not pass lint, and incorrectly auto-fix (typescript-eslint#5961) [prefer-optional-chain] The overridden literal getter does not pass lint and incorrectly auto-fix (typescript-eslint#5962)
ea4fdcc
to
3be9f6e
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! I'll defer to @bradzacher since Brad was active in the comments, and this is a tricky edge case kind of scenario.
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.
Whoops, meant to request changes on the test coverage dipping...
@JoshuaKGoldberg ready to go |
case AST_NODE_TYPES.Identifier: | ||
return key.name; | ||
case AST_NODE_TYPES.Literal: | ||
return key.raw; |
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.
You can't use .raw
here because:
- For strings it encodes in the quotes and backslashes.
- For numbers it encodes the
_
separators, decimal points, and differentiates between binary/octal/hex/decimal notation - For bigints it encodes the
_
separators
EG this would mean that these cases are not matched:
class Foo {
get 'a\"'() { return 1; }
set 'a"'(v) { }
get 'a'() { return 1; }
set "a"(v) {}
get 11() { return 1; }
set 1_1(v) { }
get 1.0() { return 1; }
set 1(v) { }
get 0b10() { return 1; }
set 2(v) { }
get 0o10() { return 1; }
set 8(v) { }
get 0x10() { return 1; }
set 16(v) { }
}
Cases case to be careful of:
RegExp
literals are not primitives, so.value === .value
will not work.BigInt
literals can technically be.value = null
, but shouldn't really ever be.
item.kind === 'set' && | ||
isEqualPropertyKey(node.key, item.key), |
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.
this also needs to check .computed
or else you will false negative on this case:
const key = 'not key lol';
class Foo {
get key() { return 'a' }
set [key](arg) {}
}
Though worth noting that right now your logic correctly handles this case:
class Foo {
get 'key'() { return 'a' }
set ['key'](arg) {}
}
If we want to keep handling this case then the logic change will need to be more sophisticated than just checking .computed
const setter = classBody.body.find( | ||
item => | ||
item.type === AST_NODE_TYPES.MethodDefinition && | ||
item.kind === 'set' && | ||
isEqualPropertyKey(node.key, item.key), | ||
); |
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.
This logic also does not respect static
and thus will false negative on this case:
class Foo {
get key() { return 'a' }
static set key(arg) {}
}
👋 ping @sviat9440, is this still something you have time for? No worries if not - I just don't want to leave it hanging. |
Closing this PR as it's been stale for ~6 weeks without activity. Feel free to reopen @sviat9440 if you have time - but no worries if not! If anybody wants to drive it forward, please do post your own PR - and if you use this as a start, consider adding |
[prefer-optional-chain] A literal getter with a setter does not pass lint, and incorrectly auto-fix (#5961)
[prefer-optional-chain] The overridden literal getter does not pass lint and incorrectly auto-fix (#5962)
PR Checklist
Overview
get [a + b](): string {}
, because we cannot be sure that the computed names are not overrides.In this case, visually, the accessors keys are no different, and can be taken as an override. But in fact, this is a completely different key.
So, the supported nodes are now:
Identifier
,PrivateIdentifier
,Literal
parserOptions.project
is not defined, rule will cause an error. (BREAKING CHANGE!)