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

Release 0.9.10 #213

Closed
wants to merge 1 commit into from
Closed
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
14 changes: 9 additions & 5 deletions src/docs/guide/usage/linter/generated-rules.md
Original file line number Diff line number Diff line change
Expand Up @@ -2,10 +2,10 @@

The progress of all rule implementations is tracked [here](https://github.com/oxc-project/oxc/issues/481).

- Total number of rules: 432
- Rules turned on by default: 96
- Total number of rules: 436
- Rules turned on by default: 97

## Correctness (170):
## Correctness (171):

Code that is outright wrong or useless.
| Rule name | Source | Default | Fixable? |
Expand Down Expand Up @@ -45,6 +45,7 @@ Code that is outright wrong or useless.
| [no-shadow-restricted-names](/docs/guide/usage/linter/rules/eslint/no-shadow-restricted-names.html) | eslint | ✅ | |
| [no-sparse-arrays](/docs/guide/usage/linter/rules/eslint/no-sparse-arrays.html) | eslint | ✅ | |
| [no-this-before-super](/docs/guide/usage/linter/rules/eslint/no-this-before-super.html) | eslint | ✅ | |
| [no-throw-literal](/docs/guide/usage/linter/rules/eslint/no-throw-literal.html) | eslint | ✅ | 💡 |
| [no-unsafe-finally](/docs/guide/usage/linter/rules/eslint/no-unsafe-finally.html) | eslint | ✅ | |
| [no-unsafe-negation](/docs/guide/usage/linter/rules/eslint/no-unsafe-negation.html) | eslint | ✅ | 🛠️ |
| [no-unused-labels](/docs/guide/usage/linter/rules/eslint/no-unused-labels.html) | eslint | ✅ | 🛠️ |
Expand Down Expand Up @@ -256,11 +257,12 @@ Lints which prevent the use of language and library features. Must not be enable
| [prefer-node-protocol](/docs/guide/usage/linter/rules/unicorn/prefer-node-protocol.html) | unicorn | | 🛠️ |
| [prefer-number-properties](/docs/guide/usage/linter/rules/unicorn/prefer-number-properties.html) | unicorn | | 🚧 |

## Suspicious (20):
## Suspicious (21):

code that is most likely wrong or useless.
| Rule name | Source | Default | Fixable? |
| ------------------------------- | ---------- | ------- | -------- |
| [no-else-return](/docs/guide/usage/linter/rules/eslint/no-else-return.html) | eslint | | 🛠️ |
| [no-extend-native](/docs/guide/usage/linter/rules/eslint/no-extend-native.html) | eslint | | |
| [no-new](/docs/guide/usage/linter/rules/eslint/no-new.html) | eslint | | |
| [no-unexpected-multiline](/docs/guide/usage/linter/rules/eslint/no-unexpected-multiline.html) | eslint | | ⚠️🛠️️ |
Expand Down Expand Up @@ -357,7 +359,7 @@ Lints which are rather strict or have occasional false positives.
| [prefer-type-error](/docs/guide/usage/linter/rules/unicorn/prefer-type-error.html) | unicorn | | 🛠️ |
| [require-number-to-fixed-digits-argument](/docs/guide/usage/linter/rules/unicorn/require-number-to-fixed-digits-argument.html) | unicorn | | 🛠️ |

## Style (100):
## Style (102):

Code that should be written in a more idiomatic way.
| Rule name | Source | Default | Fixable? |
Expand All @@ -372,6 +374,7 @@ Code that should be written in a more idiomatic way.
| [no-magic-numbers](/docs/guide/usage/linter/rules/eslint/no-magic-numbers.html) | eslint | | 🚧 |
| [no-multi-str](/docs/guide/usage/linter/rules/eslint/no-multi-str.html) | eslint | | |
| [no-new-func](/docs/guide/usage/linter/rules/eslint/no-new-func.html) | eslint | | |
| [no-return-assign](/docs/guide/usage/linter/rules/eslint/no-return-assign.html) | eslint | | 🚧 |
| [no-script-url](/docs/guide/usage/linter/rules/eslint/no-script-url.html) | eslint | | |
| [no-template-curly-in-string](/docs/guide/usage/linter/rules/eslint/no-template-curly-in-string.html) | eslint | | 🚧 |
| [no-ternary](/docs/guide/usage/linter/rules/eslint/no-ternary.html) | eslint | | |
Expand Down Expand Up @@ -417,6 +420,7 @@ Code that should be written in a more idiomatic way.
| [no-exports-assign](/docs/guide/usage/linter/rules/node/no-exports-assign.html) | node | | 🛠️ |
| [avoid-new](/docs/guide/usage/linter/rules/promise/avoid-new.html) | promise | | |
| [param-names](/docs/guide/usage/linter/rules/promise/param-names.html) | promise | | |
| [prefer-await-to-callbacks](/docs/guide/usage/linter/rules/promise/prefer-await-to-callbacks.html) | promise | | |
| [prefer-await-to-then](/docs/guide/usage/linter/rules/promise/prefer-await-to-then.html) | promise | | |
| [jsx-boolean-value](/docs/guide/usage/linter/rules/react/jsx-boolean-value.html) | react | | 🛠️ |
| [jsx-curly-brace-presence](/docs/guide/usage/linter/rules/react/jsx-curly-brace-presence.html) | react | | |
Expand Down
23 changes: 22 additions & 1 deletion src/docs/guide/usage/linter/rules/eslint/getter-return.md
Original file line number Diff line number Diff line change
Expand Up @@ -7,20 +7,41 @@

### What it does

Requires all getters to have a return statement
Requires all getters to have a `return` statement.

### Why is this bad?

Getters should always return a value. If they don't, it's probably a mistake.

This rule does not run on TypeScript files, since type checking will
catch getters that do not return a value.

### Example

Examples of **incorrect** code for this rule:

```javascript
class Person {
get name() {
// no return
}
}

const obj = {
get foo() {
// object getter are also checked
},
};
```

Examples of **correct** code for this rule:

```javascript
class Person {
get name() {
return this._name;
}
}
```

## References
Expand Down
170 changes: 170 additions & 0 deletions src/docs/guide/usage/linter/rules/eslint/no-else-return.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,170 @@
<!-- This file is auto-generated by tasks/website/src/linter/rules/doc_page.rs. Do not edit it manually. -->

# eslint/no-else-return <Badge type="info" text="Suspicious" />

<div class="rule-meta">
<Alert class="fix" type="info">
<span class="emoji">🛠️</span> An auto-fix is available for this rule.
</Alert>
</div>

### What it does

Disallow `else` blocks after `return` statements in `if` statements

### Why is this bad?

If an `if` block contains a `return` statement, the `else` block becomes
unnecessary. Its contents can be placed outside of the block.

```javascript
function foo() {
if (x) {
return y;
} else {
return z;
}
}
```

This rule is aimed at highlighting an unnecessary block of code
following an `if` containing a return statement. As such, it will warn
when it encounters an `else` following a chain of `if`s, all of them
containing a `return` statement.

Options
This rule has an object option:

- `allowElseIf`: `true` _(default)_ allows `else if` blocks after a return
- `allowElseIf`: `false` disallows `else if` blocks after a return

### Examples

#### `allowElseIf: true`

Examples of **incorrect** code for this rule:

```javascript
function foo1() {
if (x) {
return y;
} else {
return z;
}
}

function foo2() {
if (x) {
return y;
} else if (z) {
return w;
} else {
return t;
}
}

function foo3() {
if (x) {
return y;
} else {
var t = "foo";
}

return t;
}

function foo4() {
if (error) {
return "It failed";
} else {
if (loading) {
return "It's still loading";
}
}
}

// Two warnings for nested occurrences
function foo5() {
if (x) {
if (y) {
return y;
} else {
return x;
}
} else {
return z;
}
}
```

Examples of **correct** code for this rule:

```javascript
function foo1() {
if (x) {
return y;
}

return z;
}

function foo2() {
if (x) {
return y;
} else if (z) {
var t = "foo";
} else {
return w;
}
}

function foo3() {
if (x) {
if (z) {
return y;
}
} else {
return z;
}
}

function foo4() {
if (error) {
return "It failed";
} else if (loading) {
return "It's still loading";
}
}
```

#### `allowElseIf: false`

Examples of **incorrect** code for this rule:

```javascript
function foo() {
if (error) {
return "It failed";
} else if (loading) {
return "It's still loading";
}
}
```

Examples of **correct** code for this rule:

```javascript
function foo() {
if (error) {
return "It failed";
}

if (loading) {
return "It's still loading";
}
}
```

## References

- [Rule Source](https://github.com/oxc-project/oxc/blob/main/crates/oxc_linter/src/rules/eslint/no_else_return.rs)
44 changes: 44 additions & 0 deletions src/docs/guide/usage/linter/rules/eslint/no-return-assign.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,44 @@
<!-- This file is auto-generated by tasks/website/src/linter/rules/doc_page.rs. Do not edit it manually. -->

# eslint/no-return-assign <Badge type="info" text="Style" />

<div class="rule-meta">
<Alert class="fix" type="info">
<span class="emoji">🚧</span> An auto-fix is still under development.
</Alert>
</div>

### What it does

Disallows assignment operators in return statements

### Why is this bad?

Assignment is allowed by js in return expressions, but usually, an expression with only one equal sign is intended to be a comparison.
However, because of the missing equal sign, this turns to assignment, which is valid js code
Because of this ambiguity, it’s considered a best practice to not use assignment in return statements.

### Examples

Examples of **incorrect** code for this rule:

```js
() => (a = b);
function x() {
return (a = b);
}
```

Examples of **correct** code for this rule:

```js
() => (a = b);
function x() {
var result = (a = b);
return result;
}
```

## References

- [Rule Source](https://github.com/oxc-project/oxc/blob/main/crates/oxc_linter/src/rules/eslint/no_return_assign.rs)
64 changes: 64 additions & 0 deletions src/docs/guide/usage/linter/rules/eslint/no-throw-literal.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,64 @@
<!-- This file is auto-generated by tasks/website/src/linter/rules/doc_page.rs. Do not edit it manually. -->

# eslint/no-throw-literal <Badge type="info" text="Correctness" />

<div class="rule-meta">
<Alert class="default-on" type="success">
<span class="emoji">✅</span> This rule is turned on by default.
</Alert>
<Alert class="fix" type="info">
<span class="emoji">💡</span> A suggestion is available for this rule for some violations.
</Alert>
</div>

### What it does

Disallows throwing literals or non-Error objects as exceptions.

### Why is this bad?

It is considered good practice to only throw the Error object itself or an object using
the Error object as base objects for user-defined exceptions. The fundamental benefit of
Error objects is that they automatically keep track of where they were built and originated.

### Examples

Examples of **incorrect** code for this rule:

```js
throw "error";

throw 0;

throw undefined;

throw null;

var err = new Error();
throw "an " + err;
// err is recast to a string literal

var err = new Error();
throw `${err}`;
```

Examples of **correct** code for this rule:

```js
throw new Error();

throw new Error("error");

var e = new Error("error");
throw e;

try {
throw new Error("error");
} catch (e) {
throw e;
}
```

## References

- [Rule Source](https://github.com/oxc-project/oxc/blob/main/crates/oxc_linter/src/rules/eslint/no_throw_literal.rs)
Loading