-
-
Notifications
You must be signed in to change notification settings - Fork 2.8k
chore: enabled stylistic-type-checked internally #7138
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
chore: enabled stylistic-type-checked internally #7138
Conversation
Thanks for the PR, @JoshuaKGoldberg! 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 configuration. |
2a5e9f2
to
6718c2f
Compare
@@ -397,7 +402,7 @@ export default createRule<Options, MessageIds>({ | |||
.join('\n') | |||
: formatted; | |||
|
|||
return context.report({ |
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.
which rule suggested this?
TBH I prefer the return report
style here as it's easier to see that the report is terminal.
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.
no-confusing-void-expression
. I'm feeling more and more 👎 on including that one in stylistic-type-checked
.
@@ -17,26 +17,26 @@ https://gist.github.com/mathiasbynens/6334847 | |||
function isPascalCase(name: string): boolean { | |||
return ( | |||
name.length === 0 || | |||
(name[0] === name[0].toUpperCase() && !name.includes('_')) |
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 actually think that the previous form is clearer for this specifica case.
It's also substantially faster (not that it matters at the this speed... but it is twice as fast - ~1.2B ops/s vs ~2.4B ops/s).
I wonder if we should add an option to skip this case from 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.
Agreed. The main 👎 on this change in my head was that the rule is suggesting longer code... #7140
ConditionalExpression: (node): void => { | ||
checkNode(node.test); | ||
}, |
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.
TBH I personally don't think that multilining arrows is necessarily clearer.
Is there a reason the stylistic set is pushing for this style?
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.
Isn’t this https://typescript-eslint.io/rules/no-confusing-void-expression ? You probably already know but posting for other readers :D
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 it is! +1 to the visibility @rubiesonthesky 😄.
I wonder if it should be moved to the strict-type-checked
config instead... #7130 (comment)
@@ -56,7 +56,7 @@ export function forEachReturnStatement<T>( | |||
function traverse(node: ts.Node): T | undefined { | |||
switch (node.kind) { | |||
case ts.SyntaxKind.ReturnStatement: | |||
return visitor(<ts.ReturnStatement>node); |
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.
const defs = (schema.$defs ?? schema.definitions) as | ||
| Record<string, JSONSchema4> | ||
| undefined; |
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.
IIRC I did this intentionally because both of the keys were not techincally undefined
- is that not the case any more?
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! no-unnecessary-type-assertion
is complaining on them. Both schema.$defs
and schema.definitions
are Record<string, JSONSchema4> | undefined
.
export interface DependencyConstraint { | ||
/** | ||
* Passing a string for the value is shorthand for a '>=' constraint | ||
*/ | ||
readonly [packageName: string]: VersionConstraint; | ||
} |
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.
Making this a record is actually less clear due to the lost comment
@@ -232,7 +232,7 @@ abstract class ScopeBase< | |||
block: TBlock, | |||
isMethodDefinition: boolean, | |||
) { | |||
const upperScopeAsScopeBase = upperScope as Scope; |
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'm surprised TS allowed this - the reason this cast was there was because upperScope
is typed as TUpper
- and there was a lot of weird behaviour that stemmed from it being a generic instead of the concrete type.
I think there was also some weirdness due to the cyclic nature of the files? I don't fully remmeber though
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.
🤷
@@ -21,73 +21,77 @@ describe('convert', () => { | |||
); | |||
} | |||
|
|||
it('deeplyCopy should convert node correctly', () => { | |||
const ast = convertCode('type foo = ?foo<T> | ?(() => void)?'); | |||
/* eslint-disable @typescript-eslint/dot-notation */ |
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.
why is this disabled?
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.
deeplyCopy
is a private member. ['deeplyCopy']
bypasses that.
expect(() => { | ||
parseFile('foo', PROJECT_DIR); | ||
}).not.toThrow(); | ||
// bar should throw because it doesn't exist yet | ||
expect(() => parseFile(bazSlashBar, PROJECT_DIR)).toThrow(); | ||
expect(() => { | ||
parseFile(bazSlashBar, PROJECT_DIR); | ||
}).toThrow(); |
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 the sort of reason I think that the concise arrow function style is better - satisfying this lint rule just added some 160 lines to this file and (IMO) made the code harder to read
export interface GlobalsConfig { | ||
[name: string]: GlobalVariableOption; | ||
} | ||
export interface EnvironmentConfig { | ||
[name: string]: 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.
I believe that these should stay as interfaces to allow for global augmentation from consumers.
export interface VisitorKeys { | ||
[nodeType: string]: string[]; | ||
} |
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 do like the Record
style more in general, but you can lose some nice implicit documentation sometimes (eg the variable name here).
I'm so torn about using a disable comment for this though because it's so minor.
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.
It could use comment to say same if this style is kept :)
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.
Yeah this is an interesting discussion. I'll undo the changes from consistent-indexed-object-style
and file them as a todo to look at later, similar to prefer-nullish-coalescing
.
@@ -84,8 +84,7 @@ export default createRule({ | |||
return ( | |||
evaluated != null && | |||
typeof evaluated.value === 'string' && | |||
// checks if the string is a character long | |||
evaluated.value[0] === evaluated.value | |||
evaluated.value.length === 1 |
This comment was marked as off-topic.
This comment was marked as off-topic.
Sorry, something went wrong.
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.
(accidentally started a review, but getting pulled out for something - will continue commenting soon)
@@ -397,7 +402,7 @@ export default createRule<Options, MessageIds>({ | |||
.join('\n') | |||
: formatted; | |||
|
|||
return context.report({ |
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.
no-confusing-void-expression
. I'm feeling more and more 👎 on including that one in stylistic-type-checked
.
@@ -17,26 +17,26 @@ https://gist.github.com/mathiasbynens/6334847 | |||
function isPascalCase(name: string): boolean { | |||
return ( | |||
name.length === 0 || | |||
(name[0] === name[0].toUpperCase() && !name.includes('_')) |
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.
Agreed. The main 👎 on this change in my head was that the rule is suggesting longer code... #7140
ConditionalExpression: (node): void => { | ||
checkNode(node.test); | ||
}, |
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 it is! +1 to the visibility @rubiesonthesky 😄.
I wonder if it should be moved to the strict-type-checked
config instead... #7130 (comment)
Codecov Report
Additional details and impacted files@@ Coverage Diff @@
## v6 #7138 +/- ##
=======================================
Coverage 87.43% 87.43%
=======================================
Files 372 372
Lines 12849 12849
Branches 3813 3813
=======================================
Hits 11235 11235
Misses 1237 1237
Partials 377 377
Flags with carried forward coverage won't be shown. Click here to find out more.
|
Co-authored-by: rubiesonthesky <2591240+rubiesonthesky@users.noreply.github.com>
PR Checklist
Overview
Adds
stylistic-type-checked
to the list ofextends
configs and removes manual enables of rules contained in it. Most of the changes seem to be fromno-confusing-void-expression
, followed byconsistent-indexed-object-style
.A couple rules received special treatment:
prefer-nullish-coalescing
yet, as there were a lot of complaints from it and I'll look into it separatelyno-empty-function
seemed to be popular for tests, so I moved it to the tests overrides