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

explicit-length-check: Remove greater-than-or-equal option #957

Closed
fisker opened this issue Dec 23, 2020 · 2 comments · Fixed by #1397
Closed

explicit-length-check: Remove greater-than-or-equal option #957

fisker opened this issue Dec 23, 2020 · 2 comments · Fixed by #1397

Comments

@fisker
Copy link
Collaborator

fisker commented Dec 23, 2020

This option force use foo.length >= 1 when checking non-zero length, highly doubt someone prefer this.

Let's keep this open for a while to see if someone object.

Ref: #952 (comment)

@zalanlevai
Copy link

I have just come across this issue / breaking change today, while upgrading from 34.0.1 to 36.0.0 and was unaware of the discussion around it. As you may have guessed, we were actually using this length-check style in our codebases. 😅 I was aware that not many projects were using this style, but I am still surprised by its removal.

Personally, I find this style of length-checking the most explicit and, more importantly, the most logically sound out of all available options, considering the mess that is the JavaScript number type. I would rather not assume any JavaScript number value to be an integer (array.length > 0), much less a positive integer (array.length !== 0), even if it comes from a builtin, like an array's length accessor. Of course, these are all just opinions and no one style is correct. But I was very glad this (admittedly niche) option existed.

Looking at the corresponding code change, I am having a hard time figuring out why it was made, as it did not seem to simplify the rule's code significantly. Was there any technical reason for its removal, or was it simply due to the assumption that it was not used by anyone? If not, is there any chance that the removal could be reverted in a future release? I would rather not have to turn off this rule to keep using this previously supported style of length-checking.

Regardless, thank you for the great work you have put into this project!

zalanlevai added a commit to rinfeldev/jskit that referenced this issue Sep 14, 2021
`eslint-plugin-unicorn` has been held back to version `34.0.1`, since version `35.0.0` removed the `greater-than-or-equal` option for `unicorn/explicit-length-check` which "enabled a style that no one actually uses". See sindresorhus/eslint-plugin-unicorn#957 for the discussion around potentially reintroducing this option.
zalanlevai added a commit to rinfeldev/jskit that referenced this issue Sep 14, 2021
`eslint-plugin-unicorn` has been held back to version `34.0.1`, since version `35.0.0` removed the `greater-than-or-equal` option for `unicorn/explicit-length-check` due to it being a rarely used length-check style. See sindresorhus/eslint-plugin-unicorn#957 for the discussion around potentially reintroducing this option.
@sindresorhus
Copy link
Owner

I would rather not assume any JavaScript number value to be an integer

The .length property from a built-in is always a non-negative number.

or was it simply due to the assumption that it was not used by anyone

Not assumption. I have done open source for 10 years, I read new open source code every day, and I have never encountered this style of length checking.

is there any chance that the removal could be reverted in a future release?

Unlikely. It's not enough that you need it. It's simply not a common enough style to warrant supporting. I also think the logical arguments behind using this style doesn't hold up.

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 a pull request may close this issue.

3 participants