Update dependency eslint-plugin-unicorn to v19

[renovate]

This PR contains the following updates:

Package	Type	Update	Change
eslint-plugin-unicorn	dependencies	major	^18.0.0 -> ^19.0.0

---

Release Notes

sindresorhus/eslint-plugin-unicorn

v19.0.1

Compare Source

• no-fn-reference-in-iterator: Ignore this. and Vue.filter (#​699) b02a9c6
• no-fn-reference-in-iterator: Ignore cases obviously not a function reference (#​697) dae5107

v19.0.0

Compare Source

New rules

• Add no-null rule (#​636) c773c16

Breaking

• string-content: Make it have no default patterns (#​637) 08fad55
• catch-error-name: Replace caughtErrorsIgnorePattern option with an ignore option (#​661) 5a27f04

Improvements

• custom-error-definition: Support class properties (#​673) 9cc8d60
• catch-error-name: Support Promise#then (#​660) edcf73c
• prefer-set-has: Supports more types of array (#​641) 29f3c9c

Fixes

• escape-case: Fix missing characters (#​678) d986427
• no-nested-ternary: Fix incorrect result with TypeScript parser (#​664) cb08ed0
• custom-error-definition: Fix duplicated reports on this.message assign (#​669) aa00647
• custom-error-definition: Fix crash on @typescript-eslint/parser (#​659) e8cb921
• catch-error-name: Improve error message (#​665) 8ac9a90
• catch-error-name: Fix error renaming (#​654) cc2d1b1
• catch-error-name: Only allow _ when it's not used (#​650) 0c31a0b
• catch-error-name: Ignore destructuring (#​649) b2838fd

---

Renovate configuration

📅 Schedule: At any time (no schedule defined).

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻️ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

---

• If you want to rebase/retry this PR, check this box

---

This PR has been generated by WhiteSource Renovate. View repository job log here.

[renovate]

PR has been edited

👷 This PR has received other commits, so Renovate will stop updating it to avoid conflicts or other problems. If you wish to abandon your changes and have Renovate start over you may click the "rebase" checkbox in the PR body/description.

[spaceninja]

@calebeby this update required a lint fix for this rule: https://github.com/sindresorhus/eslint-plugin-unicorn/blob/v19.0.0/docs/rules/prefer-set-has.md

Would you mind reviewing the lint fix?

[calebeby]

@spaceninja the no-null rule seems very problematic, it breaks linting on a lot of code (unsurprisingly). Can we disable that rule?

[calebeby]

Can we disable no-fn-reference-in-iterator as well? That is a pattern that I like to use. In the docs for that rule it explains a scenario where that pattern has the potential to mess things up, but that seems very edge-case-y

[gerardo-rodriguez]

I agree with both suggestions from @calebeby. 😉

[calebeby]

I wonder if we should disable prefer-set-has as well.

This rule changes all arrays (that it can detect) to sets if you call .includes() on it. While it is true that array.includes is O(n) and set.has is O(1), the conversion from array to set has a cost as well, it is probably O(n).

In the use case that was auto-fixed here it makes sense to use set, because the conversion from array to set only has to happen once, while .includes/.has happens in a loop, so this change is theoretically more performant.

I think we should disable this rule and let the humans decide when to use set vs array. The decision is more nuanced than "if you call .includes on it, you should be using set instead of array"

[gerardo-rodriguez]

I wonder if we should disable prefer-set-has as well.

This rule changes all arrays (that it can detect) to sets if you call .includes() on it. While it is true that array.includes is O(n) and set.has is O(1), the conversion from array to set has a cost as well, it is probably O(n).

In the use case that was auto-fixed here it makes sense to use set, because the conversion from array to set only has to happen once, while .includes/.has happens in a loop, so this change is theoretically more performant.

I think we should disable this rule and let the humans decide when to use set vs array. The decision is more nuanced than "if you call .includes on it, you should be using set instead of array"

I think this is fair as well. Feels a bit heavy-handed of a change. 👍

[spaceninja]

Null is ok, even though Sindre Sorhus doesn't like it

LOLOLOL @calebeby nice

[spaceninja]

+1 to all the changes proposed.

[calebeby]

@spaceninja I mean Sindre definitely has a lot of good points here but having a lint rule for this becomes really really annoying

[Josh68]

Seems like there was consensus here. If you need my opinion, I can try to provide one, but I trust you guys have considered it fully.

EDIT: FWIW, I quickly scanned both references and agree on both decisions you've made.