-
-
Notifications
You must be signed in to change notification settings - Fork 2.8k
feat(eslint-plugin): [no-misused-object-like] add rule #9369
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): [no-misused-object-like] add rule #9369
Conversation
Thanks for the PR, @gibson! 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 failed.
|
☁️ Nx Cloud ReportCI is running/has finished running commands for commit 716096d. As they complete they will appear below. Click to see the status, the terminal output, and the build insights. 📂 See all runs for this CI Pipeline Execution ✅ Successfully ran 1 targetSent with 💌 from NxCloud. |
This is missing support for It may be worth-while to check if the subject of the check has any
Overall this is a good PR, it might also be good to integrate #5677 into this and generalize this rule as |
Uh oh! @SimonSchick, the image you shared is missing helpful alt text. Check #9369 (comment). Alt text is an invisible description that helps screen readers describe images to blind or low-vision users. If you are using markdown to display images, add your alt text inside the brackets of the markdown image. Learn more about alt text at Basic writing and formatting syntax: images on GitHub Docs.
|
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 would be extremely useful when migrating from object dictionary use to map/set use!
requiresTypeChecking: false, | ||
}, | ||
messages: { | ||
objectKeysForMap: "Don't use `Object.keys()` for Map objects", |
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 think this may be overly specific, granularity for SetLike
and MapLike
is likely sufficient since it would be weird to allow calling Object.values(
on a Map but banning Object.keys
docs: { | ||
description: | ||
'Enforce check `Object.values(...)`, `Object.keys(...)`, `Object.entries(...)` usage with Map/Set objects', | ||
requiresTypeChecking: false, |
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.
Pretty sure this is required?
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.
Yup, the services.getTypeAtLocation
below necessitates it.
} | ||
|
||
return { | ||
'CallExpression[callee.object.name=Object][callee.property.name=keys][arguments.length=1]': |
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 is missing various other ones such as Object.assign/groupBy/hasOwn?
, it might be better to move this check into the checkObjectMethodCall
function and have a list of banned methods there.
checkObjectValuesForSet?: boolean; | ||
checkObjectEntriesForSet?: boolean; | ||
}, | ||
]; |
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.
[Question] Why allow such a granular set of options? Is there a known use case where someone would want to skip, say, only Object.values
?
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.
A good start! There are some functional gaps that'll need to be filled in around more object support and resiliency to user shenanigans. Excited to see this - thanks for getting it started! 🙌
const callee = callExpression.callee as MemberExpression; | ||
const objectMethod = (callee.property as Identifier).name; | ||
|
||
if (argumentTypeName === 'Map') { |
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.
[Bug] If a user defines their own Map
class, this will falsely report:
class Map {
value = 1;
}
const map = new Map();
Object.values(map);
const callee = callExpression.callee as MemberExpression; | ||
const objectMethod = (callee.property as Identifier).name; |
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.
[Bug] Using an as
assertion on AST nodes is generally a sign of either:
- 🍎 The node is known to be a more specific type than what you've told the type system
- 🍌 The code isn't properly handling edge cases
The CallExpression[callee.object.name=Object][callee.property.name=keys][arguments.length=1]
below makes me think it's 🍎. Which means you'd want to use a type for the node.
type CallExpressionWithStuff = TSESTree.CallExpression & {
callee: {
object: {
name: 'Object';
// ...
} | ||
|
||
return { | ||
'CallExpression[callee.object.name=Object][callee.property.name=keys][arguments.length=1]': |
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.
object.name=Object
[Bug] False report case:
const Object = { keys: (value) => [value] };
export const keys = Object.keys(new Map());
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.
[Testing] Some missing test cases:
- Intersections and unions: with
Map
,Set
, and/or other types - Readonlies:
ReadonlyMap
,ReadonlySet
} | ||
} | ||
|
||
return { |
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.
[Bug] Looking at built-in global objects in https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects#keyed_collections, I think at least WeakMap
and WeakSet
should also be handled by this rule.
@gibson are you interested in continuing work on this? Otherwise I may be inclined to take a stab at this myself. |
@SimonSchick will continue in closes time |
👋 @gibson just checking in, do you still plan on working on this? |
Closing this PR as it's been stale for ~6 weeks without activity. Feel free to reopen @gibson 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 |
I might pick this up, I ran into some scenarious/migrations where this rule would've been incredibly valuable. |
PR Checklist
Object.values(...)
usage withMap
#6807Overview
This MR will close the problem with usage
Object.keys()
,Object.values()
andObject.entries()
for object like classesMap
andSet
. On this classes that methods always returns empty array instead of any meaningful data and doesn't cause and warnings or errors