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

prefer-math-min-max: Ignore BigInt #2467

Merged

Conversation

chirokas
Copy link
Contributor

@chirokas chirokas commented Oct 4, 2024

Close #2465

@fisker
Copy link
Collaborator

fisker commented Oct 5, 2024

Maybe we should only report when there is a number, since strings, Dates can also be compared.

@fisker
Copy link
Collaborator

fisker commented Oct 5, 2024

@axetroy What do you think?

@chirokas
Copy link
Contributor Author

chirokas commented Oct 7, 2024

You mean like this?

const isNumber = require("./utils/is-number.js");

// ...

const { sourceCode } = context;
const scope = sourceCode.getScope(conditionalExpression);
const isInvalidExpression = [left, right, alternate, consequent].some(
  (node) => !isNumber(node, scope),
);

if (isInvalidExpression) {
  return;
}

Ensure that everything, be it an Identifier, Literal, or any other expression, is a Number.

@axetroy
Copy link
Contributor

axetroy commented Oct 8, 2024

Maybe we should only report when there is a number, since strings, Dates can also be compared.

Make sense.

Ensure that everything, be it an Identifier, Literal, or any other expression, is a Number.

But I think we should only need to determine whether one of the left or right is a number (Identifier/Literal/Expression). And ignore bigInt

const isNumber = require("./utils/is-number.js");

// ...

const { sourceCode } = context;
const scope = sourceCode.getScope(conditionalExpression);
const isValidExpression = [left, right].some((node) => isNumber(node, scope));

if (!isValidExpression) {
  return;
}

const isBigIntInResult = [alternate, consequent].some((node) => isBigIntLiteral(node)
				|| isCallExpression(node, {
					name: 'BigInt',
					argumentsLength: 1,
					optional: false,
				}))

if (isBigIntInResult) {
  return;
}

@fisker
Copy link
Collaborator

fisker commented Oct 9, 2024

The logic is good, but it makes this rule almost useless.. since it's rare that both left and right matches isNumber.

@fisker
Copy link
Collaborator

fisker commented Oct 9, 2024

Maybe we can skip this check with strictTypes: false (default: true) option? So this rule can be useful sometimes.

TypeTracker from eslint-plugin-regexp can be useful, but it's quit big.

@sindresorhus Not sure what we should do here.

@sindresorhus
Copy link
Owner

The logic is good, but it makes this rule almost useless.. since it's rare that both left and right matches isNumber.

Not sure I understand. We only need to check if one of the sides is a number, right?

@sindresorhus
Copy link
Owner

TypeTracker from eslint-plugin-regexp can be useful, but it's quit big.

If we were to do that, it would be better to use TypeScrip as its type inference is much more reliable.

@axetroy
Copy link
Contributor

axetroy commented Oct 12, 2024

But I think we should only need to determine whether one of the left or right is a number
We only need to check if one of the sides is a number, right?

Just check one of them to make sure it is a comparison of numbers, not strings.

@sindresorhus
Copy link
Owner

Just check one of them to make sure it is a comparison of numbers, not strings.

Yes

@fisker
Copy link
Collaborator

fisker commented Oct 12, 2024

We only need to check if one of the sides is a number, right?

I thought the same, #2467 (comment)

Turns out I was wrong

10n > 0 ? 10n : 0
10n
Math.max(0, 10n)
VM762:1 Uncaught TypeError: Cannot convert a BigInt value to a number

typeof (new Date > 0 ? new Date : 0)
'object'
typeof (Math.max(0, new Date))
'number'

typeof ('100' > 0 ? '100' : 0)
'string'
typeof (Math.max(0, '100'))
'number'

@sindresorhus
Copy link
Owner

Turns out I was wrong

That is awful code and not something we should care about. We should be pragmatic.

@sindresorhus sindresorhus merged commit 8b7c5fc into sindresorhus:main Nov 19, 2024
17 checks passed
@sindresorhus sindresorhus changed the title prefer-math-min-max: ignore BigInt prefer-math-min-max: Ignore BigInt Nov 19, 2024
@chirokas chirokas deleted the fix/prefer-math-min-max-bigint branch November 19, 2024 11:40
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Bug: prefer-math-min-max reports false-positive for bigint
4 participants