fisker Cheung

Add `prefer-destructuring-in-parameters` rule

5

Questions: 1. Should we allow rename, maybe under an option ```diff - const foo = (bar, x) => bar.x === x + const foo = ({x: xOfBar}, x) => xOfBar...

Add `prefer-await` rule

2

Part of #652 The original plan is to add fix for many cases, but it's hard. The reason I start to implement this rule is that [`promise/eslint-plugin-promise`](https://github.com/xjamundx/eslint-plugin-promise/blob/development/docs/rules/prefer-await-to-then.md) can't check `.then`...

Add `prefer-nullish-coalescing` rule

6

Fixes #471

`prefer-ternary`: Check `if + return/throw`

6

Fixes #1116

Add `class-reference-in-static-methods` rule

6

Fixes #1050

Rule proposal: `no-unnecessary-rename`

4

Sometimes, when we import a module or destructuring an object, the property name are not available, we have to rename it. But during refactor, the property name is available again,...

Rule proposal: `no-negated-some-every`

7

### Description I believe all negative `Array.every()` can write in positive `Array.some()` ```js [ ![].every(() => true) === [].some(() => !true), ![0].every(() => true) === [0].some(() => !true), ![1].every(() =>...

More powerful `new-for-builtins`

5

Currently, [`new-for-builtins`](https://github.com/sindresorhus/eslint-plugin-unicorn/blob/main/docs/rules/new-for-builtins.md) enforce builtins used either `call` or `new`. My idea is to extend this rule to check all builtins. - Objects like `JSON`/`Math`/`Reflect`/`Temporal` should be neither `call` nor `new`...

Rule proposal: `proper-object-iterable-methods`

12

## Fail ```js // Should use `Object.values` for (const key of Object.keys(foo)) { bar(foo[key]); } ``` ```js // Should use `Object.entries` for (const key of Object.keys(foo)) { bar(foo[key], key); }...