chore: lint using putout#3341
chore: lint using putout#3341Tyriar merged 7 commits intoxtermjs:masterfrom coderaiser:feature/lint-with-putout
Conversation
|
Just disabled rules: And fixed: And updated |
src/browser/TestUtils.test.ts
Outdated
| return true; | ||
| } | ||
| public getJoinedCharacters(row: number): [number, number][] { | ||
| public getJoinedCharacters(row: number): Array<[number, number]> { |
There was a problem hiding this comment.
We prefer [] to Array<>, I think this is an eslint rule but not sure if we use it
There was a problem hiding this comment.
Looks like it's related to 8c65fca, maybe I had old master 🤔 . I'm also prefer shorthand, and there is a rule convert-generic-to-shorthand.
There was a problem hiding this comment.
That was a weirdo before - we had an array rule in place, but the older eslint version did not care much about it. After upgrading I got several linting warnings, and had to change the rule in 8c65fca to pass without warnings.
| for (let i = 0; i < array.length; i++) { | ||
| if (typeof initial === 'function') { | ||
| array[i] = (<(index: number) => T>initial)(i); | ||
| array[i] = (initial as (index: number) => T)(i); |
There was a problem hiding this comment.
@Tyriar Do we have a preference here? Could/should this be an eslint rule?
I admit, that I like the xy as Z more than <Z>xy, its imho easier to grasp with less syntax overhead (makes me less thinking). But thats just me.
There was a problem hiding this comment.
The thing is Babel can’t parse code that have both react and typescript enabled, for xterm.js it’s not a thing, but new construction is preferable.
There was a problem hiding this comment.
I prefer as too, more readable and a little easier to type. Looks like there is an eslint rule #3359
There was a problem hiding this comment.
Yes, this is the same rule, with the only difference: it cannot fix :). Anyways it will keep codebase in a clean state warning developers about assertions type used, so I think it is useful.
There was a problem hiding this comment.
Yeah I noticed that when I did the PR
| // from bg. This is needed since the inverse fg color should be based on the original bg | ||
| // color, not on the selection color | ||
| fg = (fg & ~(Attributes.CM_MASK | Attributes.RGB_MASK | FgFlags.INVERSE)); | ||
| fg &= ~(Attributes.CM_MASK | Attributes.RGB_MASK | FgFlags.INVERSE); |
There was a problem hiding this comment.
👍 for shorthand notation where possible.
Minor sidenote - in some older engines those were actually slower than the explicit long versions.
src/browser/Linkifier.test.ts
Outdated
| linkifier.registerLinkMatcher(/test/, () => assert.fail(), { | ||
| validationCallback: (url, cb) => { | ||
| count += 1; | ||
| ++count; |
There was a problem hiding this comment.
@coderaiser Is there a reason for ++count instead of count++? In C I kinda always use the latter, if I dont bind the result, which leads to same ASM code, but always use the first in loops (which used to make a difference in old compilers, not anymore though). Is there a difference in JS?
There was a problem hiding this comment.
I always prefer the postfix as well, with the only exception being if I actually need the updated value
There was a problem hiding this comment.
There is only one reason: you see what’s going on the variable in the first place, so you can understand it faster:
aVeryLongVariable++
Or like in vim dw - remove a word. So when you see ++ at the beginning you already know what's going on next, in other case you read all the variable and just after you see what to do.
Anyways, it’s not a problem, I’ll add an option or change to postfix and disable a rule.
| bufferService.reset(); | ||
| }); | ||
| it('SL (scrollLeft)', async () => { | ||
| it('SL (scrollLeft)', () => { |
There was a problem hiding this comment.
Eww, guess I created a code smell here:
Your tool correctly found the asyncs to be stripped. The code smell happens at those parseP calls, those should have await in front to be consistent on code level. Created #3347 for that. (You can keep the rule as it is, gonna re-add the async keywords over there.)
After successfully merged linting sessions part1, part2 and part3, the time is come for part 4 :).
As usual, any rule can be disabled.
Command used:
putout {src,addons}/**/*.ts --fixApplied rules:
Current config for putout v17:
{ "rules": { "apply-shorthand-properties": "on", "apply-destructuring": "off", "apply-numeric-separators": "off", "convert-assignment-to-comparison": "off", "convert-apply-to-spread": "off", "convert-math-pow": "off", "convert-for-to-for-of": "off", "convert-template-to-string": "off", "strict-mode": "off", "remove-useless-spread/object": "off", "remove-useless-array-constructor": "off", "remove-boolean-from-assertions": "off", "remove-iife": "off", "remove-console": "off", "remove-unused-variables": "off", "remove-useless-variables": "off", "merge-if-statements": "off", "promises/add-missing-await": "off" }, "match": { "SerializeAddon.benchmark.ts": { "remove-unused-expressions": "off" } }, "plugins": [ "apply-shorthand-properties" ] }