Skip to content
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(eslint):- Turned no-implicit-coercion rule to error and fixed all the occurrences #12476

Closed
wants to merge 0 commits into from
Closed

Conversation

Biki-das
Copy link
Contributor

first of all, sorry @SimenB, I messed up my last PR and it's my fault and I know how much annoying this becomes, I will try my best not to repeat this mistake

this PR is extended of #12457, and the rule of no-implicit-coercion was already added , i turned it to error and fixed the occurrences

@SimenB
Copy link
Member

SimenB commented Feb 23, 2022

first of all, sorry @SimenB, I messed up my last PR and it's my fault and I know how much annoying this becomes, I will try my best not to repeat this mistake

It's not a huge deal, don't sweat it! 😀


Ah, you found a lint rule! Sweet. It seems there are still errors reported by it 🙂

@@ -16,7 +16,7 @@ const objs = [
null,
[0, true, '2', [3.14, {}, null]],
{key1: 'foo', key2: 'bar', key3: {array: [null, {}]}},
{minusInf: -Infinity, nan: NaN, plusInf: +Infinity},
{minusInf: Number(Infinity), nan: NaN, plusInf: +Infinity},
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

negative infinity is a valid thing
you could put here Number.NEGATIVE_INFINITY

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

and Number.POSITIVE_INFINITY for plusInf

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sure

@@ -81,7 +81,9 @@ export default function shouldInstrument(
}

if (
config.coveragePathIgnorePatterns.some(pattern => !!filename.match(pattern))
config.coveragePathIgnorePatterns.some(pattern =>
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is something putting stuff onto the next line maybe?
these changes do not seem related to the rule itself
I don't mind it, but am wondering if you are using some autofix for this

@@ -64,7 +64,7 @@ function createProcessEnv(): NodeJS.ProcessEnv {
get: isWin32 ? getPropertyWin32 : getProperty,

set(_target, key, value) {
const strValue = '' + value;
const strValue = '' + String(value);
Copy link

@Smrtnyk Smrtnyk Feb 23, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this seems weird
'' + will end up as string anyway
maybe just leave String(value)

@@ -128,7 +128,7 @@ function printBasicValue(
escapeString: boolean,
): string | null {
if (val === true || val === false) {
return '' + val;
return '' + String(val);
Copy link

@Smrtnyk Smrtnyk Feb 23, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same here, I think you should drop the '' + part

@Biki-das
Copy link
Contributor Author

first of all, sorry @SimenB, I messed up my last PR and it's my fault and I know how much annoying this becomes, I will try my best not to repeat this mistake

It's not a huge deal, don't sweat it! 😀


Ah, you found a lint rule! Sweet. It seems there are still errors reported by it 🙂

Yeah i am working on it

@SimenB
Copy link
Member

SimenB commented Feb 23, 2022

Lots of these !!thing -> Boolean(thing) changes should instead be thing != null

@Biki-das
Copy link
Contributor Author

Lots of these !!thing -> Boolean(thing) changes should instead be thing != null

thanks for that

@Biki-das
Copy link
Contributor Author

@SimenB getting partial errors with Ci anything you can suggest?😐😐

@SimenB
Copy link
Member

SimenB commented Feb 24, 2022

It means some behaviour changed I guess

@Biki-das
Copy link
Contributor Author

@SimenB this is good to go , finally was able to made it work :-)

@Biki-das Biki-das requested a review from SimenB February 26, 2022 15:17
@@ -137,7 +137,7 @@ export const getObjectSubset = (
const IteratorSymbol = Symbol.iterator;

const hasIterator = (object: any) =>
!!(object != null && object[IteratorSymbol]);
Boolean(object != null && object[IteratorSymbol]);
Copy link

@Smrtnyk Smrtnyk Feb 26, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

object != null already yields boolean, so it is wrong
you want something like object != null && Boolean(object[IteratorSymbol]);

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ok sure

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we should do object != null && object[IteratorSymbol] != null

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah i am sort of confused but this looks good

@@ -109,7 +109,7 @@ it('exposes an equality function to custom matchers', () => {
jestExpect.extend({
toBeOne() {
expect(this.equals).toBe(equals);
return {pass: !!this.equals(1, 1)};
return {pass: Boolean(this.equals(1, 1))};
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would expect from something that is named like equals to already return boolean :)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

then what should i do here?

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

that was just a comment that naming of the function is ambiguous, but if it does not return a boolean you did then what you had to

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this.equals does return a boolean, so just remove the !!

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sure

@@ -27,7 +27,7 @@ const activeFilters = (

const messages = ['\n' + chalk.bold('Active Filters: ') + filters];

return messages.filter(message => !!message).join(delimiter);
return messages.filter(message => Boolean(message)).join(delimiter);
Copy link

@Smrtnyk Smrtnyk Feb 26, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

you could have this shorter and receiveBoolean wrapper as a reference
something like
return messages.filter(Boolean).join(delimiter);
but I guess ts will complain because signatures do not match?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes i tried to do that 😀

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think a return messages.filter(message => message.length > 0).join(delimiter); is better

EOL +
'' +
' */';
String(
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this looks like a pure mess :)

I think what you need here is to just wrap EOL in String wrapper
like String(EOL) and leave the rest as is

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ok sure 😀

'' +
' */';
String(
String(String('/**' + EOL) + ' * @team foo' + EOL) +
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

same here, from readability perspective this is not good
try to wrap just EOL instances like String(EOL)

@@ -98,10 +98,10 @@ export default class Spec {
static pendingSpecExceptionMessage: string;

static isPendingSpecException(e: Error) {
return !!(
return Boolean(
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

there is one eslint rule which imho would help with code blocks with lots of operators
https://eslint.org/docs/rules/operator-linebreak
so it would look like

e
&& e.toString
&& e.toString()...

having stuff at the start of the line is usually easier to keep cognitive complexity on the brain in place.
You can negotiate it with Simen if he wants it, it would be a good issue if you want to tackle it

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah sure let me just clear this one and then discuss with simen 😀

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

e.toString?.().includes(Spec.pendingSpecExceptionMessage) or something probably, but just disable the rule in this (and other packages/jest-jasmine2/src/jasmine/*.ts files) - they're forked from jasmine and can remain a bit messy 🙂

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@SimenB disable no-implicit-coercion rule?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes, in this and the other jasmine files

@SimenB
Copy link
Member

SimenB commented Feb 26, 2022

I don't like Boolean even if the lint rule suggests it 🙂 almost every place it should be != null or if it's a string, we should check the strings length

@Smrtnyk
Copy link

Smrtnyk commented Feb 26, 2022

I don't like Boolean even if the lint rule suggests it slightly_smiling_face almost every place it should be != null or if it's a string, we should check the strings length

I personally find this rule more noisy than useful :)

@SimenB
Copy link
Member

SimenB commented Feb 26, 2022

I'm a fan of getting rid of double bangs (they're quite unreadable and very JS specific) in favour of more explicit checks

@Biki-das
Copy link
Contributor Author

@SimenB done :-) with the suggested changes

@Biki-das Biki-das requested a review from SimenB February 26, 2022 18:52
@@ -5,4 +5,4 @@
* LICENSE file in the root directory of this source tree.
*/

globalThis.describeDefined = !!globalThis.describe;
globalThis.describeDefined = Boolean(globalThis.describe);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this, and other Boolean should be != null as mentioned

@github-actions
Copy link

This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.
Please note this issue tracker is not a help forum. We recommend using StackOverflow or our discord channel for questions.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Mar 31, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants