fix(eslint-plugin): [consistent-generic-constructors] ignore when constructor is typed array #10477
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 on https://opencollective.com/typescript-eslint. |
|
View your CI Pipeline Execution ↗ for commit 91b65ae.
☁️ Nx Cloud last updated this comment at |
✅ Deploy Preview for typescript-eslint ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
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; | ||
| }; |
There was a problem hiding this comment.
[Bug] It's not enough to just look at the name. If someone happens to redeclare their own class, such as class Uint8Array<T>, the rule should know to check that:
class Uint8Array<T> {
// ...
}
let a: Uint8Array<ArrayBufferLike> = new Uint8Array();
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 on context.sourceCode.getScope should get you some good starting points.
packages/eslint-plugin/src/rules/consistent-generic-constructors.ts
Outdated
Show resolved
Hide resolved
|
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. |
|
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? |
| @@ -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)) | |||
There was a problem hiding this comment.
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 the Uint*Arrays, 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 like ban-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
Uint8Arrayand 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?
| ignore: { | ||
| type: 'array', | ||
| description: | ||
| 'A list of constructor names to ignore when enforcing the rule.', |
There was a problem hiding this comment.
IMO if we do go with a list then we'd want to use TypeOrValueSpecifier. 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.