Uh oh!
There was an error while loading.Please reload this page.
- Notifications
You must be signed in to change notification settings - Fork2.8k
fix(eslint-plugin): [consistent-generic-constructors] ignore when constructor is typed array#10477
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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
base:main
Are you sure you want to change the base?
Uh oh!
There was an error while loading.Please reload this page.
Conversation
Thanks for the PR,@mdm317! 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 onhttps://opencollective.com/typescript-eslint. |
nx-cloudbot commentedDec 9, 2024 • edited
Loading Uh oh!
There was an error while loading.Please reload this page.
edited
Uh oh!
There was an error while loading.Please reload this page.
View yourCI Pipeline Execution ↗ for commit91b65ae.
☁️Nx Cloud last updated this comment at |
netlifybot commentedDec 9, 2024 • edited
Loading Uh oh!
There was an error while loading.Please reload this page.
edited
Uh oh!
There was an error while loading.Please reload this page.
✅ Deploy Preview fortypescript-eslint ready!
To edit notification comments on pull requests, go to yourNetlify site configuration. |
codecovbot commentedDec 9, 2024 • edited
Loading Uh oh!
There was an error while loading.Please reload this page.
edited
Uh oh!
There was an error while loading.Please reload this page.
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@## main #10477 +/- ##======================================= Coverage 87.58% 87.58% ======================================= Files 470 470 Lines 16095 16096 +1 Branches 4668 4669 +1 =======================================+ Hits 14097 14098 +1 Misses 1642 1642 Partials 356 356
Flags with carried forward coverage won't be shown.Click here to find out more.
🚀 New features to boost your workflow:
|
return true; | ||
} | ||
return false; | ||
}; |
JoshuaKGoldbergDec 14, 2024 • edited
Loading Uh oh!
There was an error while loading.Please reload this page.
edited
Uh oh!
There was an error while loading.Please reload this page.
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] It's not enough to just look at the name. If someone happens to redeclare their own class, such asclass Uint8Array<T>
, the rule should know to check that:
classUint8Array<T>{// ...}leta:Uint8Array<ArrayBufferLike>=newUint8Array();export{}
You'll want to use the scope manager to see whether the identifier is referencing something declared or imported in the file vs. a global. Searching oncontext.sourceCode.getScope
should get you some good starting points.
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! 🚀
packages/eslint-plugin/src/rules/consistent-generic-constructors.ts OutdatedShow resolvedHide resolved
Uh oh!
There was an error while loading.Please reload this page.
FWIW, my personal preference is still "we should not special case built-ins". These types of declarations can legitimately happen with user-defined types, so we should just create a generic allowlist of types. |
mdm317 commentedDec 17, 2024 • edited
Loading Uh oh!
There was an error while loading.Please reload this page.
edited
Uh oh!
There was an error while loading.Please reload this page.
Should we avoid dealing specifically with the built-in array-likes? |
@Josh-Cena just confirming, what do you suggest we do here? |
This:
Like a new option called |
I added an allow option to ignore consistency checks. Should I add TypedArray to the default option? |
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.
Sorry for the back-and-forth on this rule's option(s)! It looks like we have a bit of design/discussion work to do before we're settled?
@@ -77,7 +96,8 @@ export default createRule<Options, MessageIds>({ | |||
lhs && | |||
(lhs.type !== AST_NODE_TYPES.TSTypeReference || | |||
lhs.typeName.type !== AST_NODE_TYPES.Identifier || | |||
lhs.typeName.name !== rhs.callee.name) | |||
lhs.typeName.name !== rhs.callee.name || | |||
options?.ignore?.includes(lhs.typeName.name)) |
JoshuaKGoldbergMar 31, 2025 • edited
Loading Uh oh!
There was an error while loading.Please reload this page.
edited
Uh oh!
There was an error while loading.Please reload this page.
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.
Threading#10477 (comment):
Should I add TypedArray to the default option?
It looks like we don't have consensus on this yet?
- 👍 vote:Bug: [consistent-generic-constructors] improper fix into
new Uint8Array<ArrayBufferLike>()
#10445 (comment). - 👎 vote:fix(eslint-plugin): [consistent-generic-constructors] ignore when constructor is typed array #10477 (comment)
One concern with having default values in the default list is that it gets inconvenient to add to the list rather than replace it. If the default type includes, say,Proxy
and all theUint*Array
s, then that's a lot of manual re-typing for folks to write if they want to keep ignoring them.
We're previously had options likeban-types
>extendDefaults
to get around this, but they're kind of clunky.
@Josh-Cena I think what's confusing me here is:
- What benefit is there to reporting on
Uint8Array
and similar? I.e.: in what situations would one want the rule to report on them? - If there are none, why not hardcode the rule to always ignore them?
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.
- What benefit is there to reporting on
Uint8Array
and similar? I.e.: in what situations would one want the rule to report on them?
There's none; I would expect them to be ignored by default.
If there are none, why not hardcode the rule to always ignore them?
Therule should be generic. Any library-specific logic (even those related to native objects) should be injected via options. Built-in objects should not be distinguishable from user-defined 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.
Ok great I think we're aligned? Just confirming, I'm of the opinion that:
- The rule should not report those things by default
- The list should be empty (
[]
) by default
...so the rule should not provide a way to now report on those built-ins?
ignore: { | ||
type: 'array', | ||
description: | ||
'A list of constructor names to ignore when enforcing the rule.', |
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.
IMO if we do go with a list then we'd want to useTypeOrValueSpecifier. Otherwise it'll have the same issue as#10477 (comment) with coincidentally matching names.
But, I'm not sure this is the right step. I started a thread later in this file about it.
PR Checklist
new Uint8Array<ArrayBufferLike>()
#10445Overview
Hard-code the typed arrays and added code to skip check if the type is a typed array.