diff --git a/.github/renovate.json b/.github/renovate.json index b11047b03f8..75d2144bcbe 100644 --- a/.github/renovate.json +++ b/.github/renovate.json @@ -1,4 +1,5 @@ { "$schema": "https://docs.renovatebot.com/renovate-schema.json", - "extends": ["github>Boshen/renovate", "helpers:pinGitHubActionDigestsToSemver"] + "extends": ["github>Boshen/renovate", "helpers:pinGitHubActionDigests"], + "updateNotScheduled": true } diff --git a/.github/workflows/ci.yml b/.github/workflows/ci.yml index 65bb24799ed..e2a415b3622 100644 --- a/.github/workflows/ci.yml +++ b/.github/workflows/ci.yml @@ -1,7 +1,5 @@ name: CI -permissions: {} - on: pull_request: types: @@ -12,6 +10,7 @@ on: push: branches: - main + - "renovate/**" paths-ignore: - README.md @@ -20,18 +19,29 @@ concurrency: cancel-in-progress: ${{ github.ref_name != 'main' }} jobs: + check-typos: + name: Check typos + runs-on: ubuntu-latest + steps: + - uses: taiki-e/checkout-action@b13d20b7cda4e2f325ef19895128f7ff735c0b3d # v1 + - uses: crate-ci/typos@master + with: + files: . + lint: name: Lint + needs: check-typos runs-on: ubuntu-latest steps: - - uses: taiki-e/checkout-action@b13d20b7cda4e2f325ef19895128f7ff735c0b3d # v1.3.1 - - uses: oxc-project/setup-node@fdbf0dfd334c4e6d56ceeb77d91c76339c2a0885 # v1.0.4 - - run: pnpm run lint --format github - - run: pnpm run fmt - - run: git diff --exit-code # Must commit everything - - uses: crate-ci/typos@80c8a4945eec0f6d464eaf9e65ed98ef085283d1 # v1.38.1 + - uses: taiki-e/checkout-action@b13d20b7cda4e2f325ef19895128f7ff735c0b3d # v1 + - uses: pnpm/action-setup@v4 + - uses: actions/setup-node@39370e3970a6d050c480ffad4ff0ed4d3fdee5af # v4 with: - files: . + node-version-file: .node-version + cache: pnpm + - run: pnpm install --frozen-lockfile + - name: Oxlint + run: pnpm run lint --format github build-and-deploy: name: Build and Deploy @@ -40,8 +50,13 @@ jobs: permissions: contents: write steps: - - uses: taiki-e/checkout-action@b13d20b7cda4e2f325ef19895128f7ff735c0b3d # v1.3.1 - - uses: oxc-project/setup-node@fdbf0dfd334c4e6d56ceeb77d91c76339c2a0885 # v1.0.4 + - uses: taiki-e/checkout-action@b13d20b7cda4e2f325ef19895128f7ff735c0b3d # v1 + - uses: pnpm/action-setup@v4 + - uses: actions/setup-node@39370e3970a6d050c480ffad4ff0ed4d3fdee5af # v4 + with: + node-version-file: .node-version + cache: pnpm + - run: pnpm install --frozen-lockfile - run: pnpm run build env: REDIRECT: true diff --git a/.github/workflows/dprint.yml b/.github/workflows/dprint.yml deleted file mode 100644 index ef55555d099..00000000000 --- a/.github/workflows/dprint.yml +++ /dev/null @@ -1,30 +0,0 @@ -name: Save dprint plugin cache - -permissions: {} - -on: - workflow_dispatch: - push: - branches: - - main - paths: - - "dprint.json" - - ".github/workflows/dprint.yml" - -jobs: - cache: - runs-on: ubuntu-latest - steps: - - uses: taiki-e/checkout-action@b13d20b7cda4e2f325ef19895128f7ff735c0b3d # v1.3.1 - - - uses: taiki-e/install-action@e43a5023a747770bfcb71ae048541a681714b951 # v2.62.33 - with: - tool: dprint - - - run: dprint check - - - name: Save dprint plugin cache - uses: actions/cache/save@0057852bfaa89a56745cba8c7296529d2fc39830 # v4.3.0 - with: - key: dprint-${{ hashFiles('dprint.json') }} - path: ~/.cache/dprint diff --git a/.github/workflows/release.yml b/.github/workflows/release.yml index 9fb0f0a8e85..7ab5ec89f81 100644 --- a/.github/workflows/release.yml +++ b/.github/workflows/release.yml @@ -1,7 +1,5 @@ name: Release -permissions: {} - on: push: branches: @@ -24,27 +22,31 @@ jobs: name: Build runs-on: ubuntu-latest steps: - - uses: taiki-e/checkout-action@b13d20b7cda4e2f325ef19895128f7ff735c0b3d # v1.3.1 + - uses: taiki-e/checkout-action@b13d20b7cda4e2f325ef19895128f7ff735c0b3d # v1 - - uses: actions/checkout@08c6903cd8c0fde910a37f88322edcfb5dd907a8 # v5.0.0 + - uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4 with: repository: oxc-project/oxc ref: main path: oxc - persist-credentials: false - name: Install Tools - uses: taiki-e/install-action@e43a5023a747770bfcb71ae048541a681714b951 # v2.62.33 + uses: taiki-e/install-action@e523301c9af289ba196edd3ab08abdece06107d2 # v2 with: tool: just - run: cd oxc && just website .. - run: rm -rf oxc - - uses: oxc-project/setup-node@fdbf0dfd334c4e6d56ceeb77d91c76339c2a0885 # v1.0.4 - - run: pnpm run fmt "./src/docs/guide/usage/linter/**" + - uses: pnpm/action-setup@v4 + - uses: actions/setup-node@39370e3970a6d050c480ffad4ff0ed4d3fdee5af # v4 + with: + node-version-file: .node-version + cache: pnpm + - run: pnpm install --frozen-lockfile + - run: pnpm run fmt --write ./src/docs/guide/usage/linter - - uses: peter-evans/create-pull-request@271a8d0340265f705b14b6d32b9829c1cb33d45e # v7.0.8 + - uses: peter-evans/create-pull-request@5e914681df9dc83aa4e4905692ca88beb2f9e91f # v7 with: token: ${{ secrets.OXC_BOT_PAT }} commit-message: Release ${{ inputs.version }} @@ -52,5 +54,5 @@ jobs: branch-suffix: timestamp title: Release ${{ inputs.version }} body: From https://github.com/oxc-project/oxc/pull/${{ inputs.issue-number }} - assignees: camc314 + assignees: Boshen base: main diff --git a/.github/workflows/zizmor.yml b/.github/workflows/zizmor.yml deleted file mode 100644 index 90387584f98..00000000000 --- a/.github/workflows/zizmor.yml +++ /dev/null @@ -1,39 +0,0 @@ -name: GitHub Actions Security Analysis - -permissions: {} - -on: - workflow_dispatch: - pull_request: - types: [opened, synchronize] - paths: - - ".github/workflows/**" - push: - branches: - - main - paths: - - ".github/workflows/**" - -jobs: - zizmor: - name: zizmor - runs-on: ubuntu-latest - permissions: - security-events: write - steps: - - uses: actions/checkout@08c6903cd8c0fde910a37f88322edcfb5dd907a8 # v5.0.0 - with: - persist-credentials: false - - - uses: taiki-e/install-action@e43a5023a747770bfcb71ae048541a681714b951 # v2.62.33 - with: - tool: zizmor - - - run: zizmor --format sarif . > results.sarif - env: - GH_TOKEN: ${{ secrets.GITHUB_TOKEN }} - - - uses: github/codeql-action/upload-sarif@16140ae1a102900babc80a33c44059580f687047 # v4.30.9 - with: - sarif_file: results.sarif - category: zizmor diff --git a/.husky/pre-commit b/.husky/pre-commit index 5ee7abd87c6..cb2c84d5c3c 100755 --- a/.husky/pre-commit +++ b/.husky/pre-commit @@ -1 +1 @@ -pnpm exec lint-staged +pnpm lint-staged diff --git a/.node-version b/.node-version index 517f38666b4..7af24b7ddbd 100644 --- a/.node-version +++ b/.node-version @@ -1 +1 @@ -v22.14.0 +22.11.0 diff --git a/.textlintrc.json b/.textlintrc.json new file mode 100644 index 00000000000..1437e349748 --- /dev/null +++ b/.textlintrc.json @@ -0,0 +1,9 @@ +{ + "plugins": {}, + "filters": { + "comments": true + }, + "rules": { + "doubled-spaces": true + } +} diff --git a/.typos.toml b/.typos.toml index 29e4c3a52b8..9d50f863cb7 100644 --- a/.typos.toml +++ b/.typos.toml @@ -3,10 +3,9 @@ # typos [default.extend-words] -strager = "strager" trivias = "trivias" trivia = "trivia" inferrable = "inferrable" [files] -extend-exclude = ["src/docs/guide/usage/linter/rules", "pnpm-lock.yaml", "public/sponsors.svg"] +extend-exclude = ["src/docs/guide/usage/linter/rules", "pnpm-lock.yaml"] diff --git a/.vitepress/config/en.ts b/.vitepress/config/en.ts index 412b1b3cfc7..c01fbceb939 100644 --- a/.vitepress/config/en.ts +++ b/.vitepress/config/en.ts @@ -1,5 +1,5 @@ -import BLOG_SIDEBAR from "../sidebar.blog.json"; import { defineLocaleConfig } from "./utils"; +import BLOG_SIDEBAR from "../sidebar.blog.json"; const TITLE = "The JavaScript Oxidation Compiler"; const DESCRIPTION = "A collection of high-performance JavaScript tools written in Rust"; @@ -23,7 +23,7 @@ export const enConfig = defineLocaleConfig("root", { { text: "Resources", items: [ - { text: "Blog", link: "/blog/2025-10-09-oxlint-js-plugins" }, + { text: "Blog", link: "/blog/2024-10-18-oxlint-v0.10-release" }, { text: "Team", link: "/team" }, { text: "Branding", link: "/branding" }, { text: "Website GitHub", link: "https://github.com/oxc-project/oxc-project.github.io" }, @@ -45,16 +45,12 @@ export const enConfig = defineLocaleConfig("root", { link: "/docs/guide/usage/linter", items: [ { - text: "Configuring Oxlint", - link: "/docs/guide/usage/linter/config", - }, - { - text: "Type-Aware Linting", - link: "/docs/guide/usage/linter/type-aware", + text: "Command-line Interface", + link: "/docs/guide/usage/linter/cli", }, { - text: "Nested Configs", - link: "/docs/guide/usage/linter/nested-config", + text: "Configuration File", + link: "/docs/guide/usage/linter/config", }, { text: "Rules", @@ -64,57 +60,14 @@ export const enConfig = defineLocaleConfig("root", { text: "Plugins", link: "/docs/guide/usage/linter/plugins", }, - { - text: "JS Plugins", - link: "/docs/guide/usage/linter/js-plugins", - }, { text: "Automatic Fixes", link: "/docs/guide/usage/linter/automatic-fixes", }, - { - text: "CLI reference", - link: "/docs/guide/usage/linter/cli", - }, - { - text: "Configuration file reference", - link: "/docs/guide/usage/linter/config-file-reference", - }, - { - text: "Versioning", - link: "/docs/guide/usage/linter/versioning", - }, ], }, { text: "Parser", link: "/docs/guide/usage/parser" }, - { - text: "Transformer", - link: "/docs/guide/usage/transformer", - items: [ - { - text: "Lowering", - link: "/docs/guide/usage/transformer/lowering", - }, - { - text: "TypeScript", - link: "/docs/guide/usage/transformer/typescript", - }, - { - text: "JSX", - link: "/docs/guide/usage/transformer/jsx", - }, - { - text: "Plugins", - link: "/docs/guide/usage/transformer/plugins", - }, - { - text: "Isolated Declarations", - link: "/docs/guide/usage/transformer/isolated-declarations", - }, - ], - }, - { text: "Formatter", link: "/docs/guide/usage/formatter" }, - { text: "Minifier", link: "/docs/guide/usage/minifier" }, + { text: "Transformer", link: "/docs/guide/usage/transformer" }, { text: "Resolver", link: "/docs/guide/usage/resolver" }, ], }, @@ -122,33 +75,41 @@ export const enConfig = defineLocaleConfig("root", { items: [ { text: "All benchmarks", link: "/docs/guide/benchmarks" }, { text: "Projects using Oxc", link: "/docs/guide/projects" }, - { text: "On media", link: "/docs/guide/media" }, ], }, ], "/docs/learn/": [ - { - text: "JavaScript Parser in Rust", - items: [ - { text: "Introduction", link: "/docs/learn/parser_in_rust/intro" }, - { text: "Lexer", link: "/docs/learn/parser_in_rust/lexer" }, - { text: "AST", link: "/docs/learn/parser_in_rust/ast" }, - { text: "Parser", link: "/docs/learn/parser_in_rust/parser" }, - { text: "Errors", link: "/docs/learn/parser_in_rust/errors" }, - { text: "Semantic Analysis", link: "/docs/learn/parser_in_rust/semantic_analysis" }, - ], - }, { text: "Architecture", items: [ - { - text: "Parser", - link: "/docs/learn/architecture/parser", - }, + // { + // text: "Introduction", + // link: "/docs/learn/architecture/introduction", + // }, + // { + // text: "Parser", + // link: "/docs/learn/architecture/parser", + // }, { text: "Linter", link: "/docs/learn/architecture/linter", }, + // { + // text: "Resolver", + // link: "/docs/learn/architecture/resolver", + // }, + // { + // text: "Transformer", + // link: "/docs/learn/architecture/transformer", + // }, + // { + // text: "Formatter", + // link: "/docs/learn/architecture/formatter", + // }, + // { + // text: "Minifier", + // link: "/docs/learn/architecture/minifier", + // }, { text: "Test Infrastructure", link: "/docs/learn/architecture/test", @@ -159,6 +120,17 @@ export const enConfig = defineLocaleConfig("root", { }, ], }, + { + text: "JavaScript Parser in Rust", + items: [ + { text: "Introduction", link: "/docs/learn/parser_in_rust/intro" }, + { text: "Lexer", link: "/docs/learn/parser_in_rust/lexer" }, + { text: "AST", link: "/docs/learn/parser_in_rust/ast" }, + { text: "Parser", link: "/docs/learn/parser_in_rust/parser" }, + { text: "Errors", link: "/docs/learn/parser_in_rust/errors" }, + { text: "Semantic Analysis", link: "/docs/learn/parser_in_rust/semantic_analysis" }, + ], + }, { text: "ECMAScript", items: [ @@ -205,6 +177,7 @@ export const enConfig = defineLocaleConfig("root", { text: "Transformer", link: "/docs/contribute/transformer", }, + // { text: "Codegen", link: "/docs/contribute/codegen" }, { text: "Minifier", link: "/docs/contribute/minifier" }, { text: "VSCode", link: "/docs/contribute/vscode" }, ], diff --git a/.vitepress/config/index.ts b/.vitepress/config/index.ts index 2f80541a780..fb19321877d 100644 --- a/.vitepress/config/index.ts +++ b/.vitepress/config/index.ts @@ -1,8 +1,8 @@ import { defineConfig } from "vitepress"; -import { enConfig } from "./en"; -import { rssConfig } from "./rss"; import { sharedConfig } from "./shared"; +import { rssConfig } from "./rss"; +import { enConfig } from "./en"; export default defineConfig({ ...sharedConfig, diff --git a/.vitepress/config/inlined-scripts/banner.js b/.vitepress/config/inlined-scripts/banner.js deleted file mode 100644 index f5779dd3b2a..00000000000 --- a/.vitepress/config/inlined-scripts/banner.js +++ /dev/null @@ -1,11 +0,0 @@ -(() => { - const restore = (key, cls, def = false) => { - const saved = localStorage.getItem(key); - if (saved ? saved !== "false" : def) { - document.documentElement.classList.add(cls); - } - }; - - window.__OXC_BANNER_ID__ = "/blog/2025-10-09-oxlint-js-plugins"; - restore(`oxc-banner-dismissed-${__OXC_BANNER_ID__}`, "banner-dismissed"); -})(); diff --git a/.vitepress/config/rss.ts b/.vitepress/config/rss.ts index 0a3e688d51f..f46773fbdb2 100644 --- a/.vitepress/config/rss.ts +++ b/.vitepress/config/rss.ts @@ -1,9 +1,9 @@ -import { Author, Feed } from "feed"; -import { mkdirSync, writeFileSync } from "node:fs"; import path from "node:path"; -import { createContentLoader, defineConfig, type SiteConfig } from "vitepress"; -import { TEAM_MEMBERS_MAP } from "../theme/constants/team"; +import { mkdirSync, writeFileSync } from "node:fs"; +import { defineConfig, createContentLoader, type SiteConfig } from "vitepress"; +import { Author, Feed } from "feed"; import { sharedConfig } from "./shared"; +import { TEAM_MEMBERS_MAP } from "../theme/constants/team"; // Thanks to https://laros.io/generating-an-rss-feed-with-vitepress export const rssConfig = defineConfig({ diff --git a/.vitepress/config/shared.ts b/.vitepress/config/shared.ts index 0062181a75d..8ed051a04b7 100644 --- a/.vitepress/config/shared.ts +++ b/.vitepress/config/shared.ts @@ -1,17 +1,8 @@ -import { readFileSync } from "node:fs"; import { dirname, resolve } from "node:path"; import { fileURLToPath } from "node:url"; -import { defineConfig, HeadConfig } from "vitepress"; +import { HeadConfig, defineConfig } from "vitepress"; import { groupIconMdPlugin, groupIconVitePlugin } from "vitepress-plugin-group-icons"; -function inlineScript(file: string): HeadConfig { - return [ - "script", - {}, - readFileSync(resolve(__dirname, `./inlined-scripts/${file}`), "utf-8"), - ]; -} - const head: HeadConfig[] = [ [ "link", @@ -22,6 +13,7 @@ const head: HeadConfig[] = [ ], // Open Graph ["meta", { property: "og:site_name", content: "Oxc" }], + ["meta", { property: "og:url", content: "https://github.com/oxc-project" }], [ "meta", { @@ -39,8 +31,6 @@ const head: HeadConfig[] = [ content: "https://cdn.jsdelivr.net/gh/oxc-project/oxc-assets/preview-universal.png", }, ], - // banner - inlineScript("banner.js"), // Google Analytics ["script", { async: "", src: "https://www.googletagmanager.com/gtag/js?id=G-X7WQ091KL7" }], [ @@ -51,6 +41,7 @@ const head: HeadConfig[] = [ gtag('js', new Date()); gtag('config', 'G-X7WQ091KL7');`, ], + ["link", { rel: "canonical", href: 'href="https://oxc.rs/"' }], ]; if (process.env.NODE_ENV === "production" && process.env.REDIRECT) { @@ -64,45 +55,6 @@ export const sharedConfig = defineConfig({ base: "/", head, lastUpdated: false, - transformPageData(pageData) { - pageData.frontmatter.head ??= []; - - if (pageData.frontmatter.canonical) { - pageData.frontmatter.head.push([ - "link", - { - rel: "canonical", - href: pageData.frontmatter.canonical, - }, - ]); - } - - // Add page-specific Open Graph and Twitter meta tags - const title = pageData.frontmatter.title || pageData.title; - const description = pageData.frontmatter.description || pageData.description - || "A collection of high-performance JavaScript tools written in Rust"; - - // Construct the canonical URL for the page - let url = "https://oxc.rs/"; - if (pageData.relativePath !== "index.md") { - const path = pageData.relativePath.replace(/\.md$/, ".html").replace(/\/index\.html$/, "/"); - if (path !== "index.html") { - url += "/" + path.replace(/^\/+/, ""); - } - } - - if (title) { - pageData.frontmatter.head.push(["meta", { property: "og:title", content: title }]); - pageData.frontmatter.head.push(["meta", { name: "twitter:title", content: title }]); - } - - if (description) { - pageData.frontmatter.head.push(["meta", { property: "og:description", content: description }]); - pageData.frontmatter.head.push(["meta", { name: "twitter:description", content: description }]); - } - - pageData.frontmatter.head.push(["meta", { property: "og:url", content: url }]); - }, themeConfig: { siteTitle: "Oxc", logo: "https://cdn.jsdelivr.net/gh/oxc-project/oxc-assets/round.svg", @@ -121,7 +73,7 @@ export const sharedConfig = defineConfig({ }, footer: { message: `Released under the MIT License.`, - copyright: "Copyright Β© 2023-present VoidZero Inc.", + copyright: "Copyright Β© 2023-present Boshen & Oxc Contributors", }, }, markdown: { diff --git a/.vitepress/config/utils.ts b/.vitepress/config/utils.ts index d7fcbf2799f..8a7c1c3d599 100644 --- a/.vitepress/config/utils.ts +++ b/.vitepress/config/utils.ts @@ -29,9 +29,9 @@ export function defineLocaleConfig(key: string, config: Config): LocaleConfig -import { useData } from "vitepress"; import { computed } from "vue"; +import { useData } from "vitepress"; interface Badge { src: string; diff --git a/.vitepress/theme/components/AppBlogPostHeader.vue b/.vitepress/theme/components/AppBlogPostHeader.vue index d3f494780e8..4f824b2fe9c 100644 --- a/.vitepress/theme/components/AppBlogPostHeader.vue +++ b/.vitepress/theme/components/AppBlogPostHeader.vue @@ -1,8 +1,8 @@ - # eslint/array-callback-return
@@ -21,68 +16,15 @@ If we forget to write return statement in a callback of those, it’s probably a If you don’t want to use a return or don’t need the returned results, consider using .forEach instead. -### Examples - -Examples of **incorrect** code for this rule: - -```javascript -let foo = [1, 2, 3, 4]; -foo.map((a) => { - console.log(a); -}); -``` - -Examples of **correct** code for this rule: +### Example ```javascript let foo = [1, 2, 3, 4]; foo.map((a) => { console.log(a); - return a; }); ``` -## Configuration - -This rule accepts a configuration object with the following properties: - -### allowImplicitReturn - -type: `boolean` - -default: `false` - -When set to true, allows callbacks of methods that require a return value to -implicitly return undefined with a return statement containing no expression. - -### checkForEach - -type: `boolean` - -default: `false` - -When set to true, rule will also report forEach callbacks that return a value. - -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny array-callback-return -``` - -```json [Config (.oxlintrc.json)] -{ - "rules": { - "array-callback-return": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/eslint/array_callback_return/mod.rs) diff --git a/src/docs/guide/usage/linter/rules/eslint/arrow-body-style.md b/src/docs/guide/usage/linter/rules/eslint/arrow-body-style.md deleted file mode 100644 index 5a0ea1a42e2..00000000000 --- a/src/docs/guide/usage/linter/rules/eslint/arrow-body-style.md +++ /dev/null @@ -1,183 +0,0 @@ - - - - -# eslint/arrow-body-style - -
- -🚧 An auto-fix is still under development. - -
- -### What it does - -This rule can enforce or disallow the use of braces around arrow function body. -Arrow functions can use either: - -- a block body `() => { ... }` -- or a concise body `() => expression` with an implicit return. - -### Why is this bad? - -Inconsistent use of block vs. concise bodies makes code harder to read. -Concise bodies are limited to a single expression, whose value is implicitly returned. - -### Options - -First option: - -- Type: `string` -- Enum: `"always"`, `"as-needed"`, `"never"` -- Default: `"never"` - -Possible values: - -- `never` enforces no braces where they can be omitted (default) -- `always` enforces braces around the function body -- `as-needed` enforces no braces around the function body (constrains arrow functions to the role of returning an expression) - -Second option: - -- Type: `object` -- Properties: - - `requireReturnForObjectLiteral`: `boolean` (default: `false`) - requires braces and an explicit return for object literals. - -Note: This option only applies when the first option is `"as-needed"`. - -Example configuration: - -```json -{ - "arrow-body-style": ["error", "as-needed", { "requireReturnForObjectLiteral": true }] -} -``` - -### Examples - -#### `"never"` (default) - -Examples of **incorrect** code for this rule with the `never` option: - -```js -/* arrow-body-style: ["error", "never"] */ - -/* ✘ Bad: */ -const foo = () => { - return 0; -}; -``` - -Examples of **correct** code for this rule with the `never` option: - -```js -/* arrow-body-style: ["error", "never"] */ - -/* βœ” Good: */ -const foo = () => 0; -const bar = () => ({ foo: 0 }); -``` - -#### `"always"` - -Examples of **incorrect** code for this rule with the `always` option: - -```js -/* arrow-body-style: ["error", "always"] */ - -/* ✘ Bad: */ -const foo = () => 0; -``` - -Examples of **correct** code for this rule with the `always` option: - -```js -/* arrow-body-style: ["error", "always"] */ - -/* βœ” Good: */ -const foo = () => { - return 0; -}; -``` - -#### `"as-needed"` - -Examples of **incorrect** code for this rule with the `as-needed` option: - -```js -/* arrow-body-style: ["error", "as-needed"] */ - -/* ✘ Bad: */ -const foo = () => { - return 0; -}; -``` - -Examples of **correct** code for this rule with the `as-needed` option: - -```js -/* arrow-body-style: ["error", "as-needed"] */ - -/* βœ” Good: */ -const foo1 = () => 0; - -const foo2 = (retv, name) => { - retv[name] = true; - return retv; -}; - -const foo3 = () => { - bar(); -}; -``` - -#### `"as-needed"` with `requireReturnForObjectLiteral` - -Examples of **incorrect** code for this rule with the `{ "requireReturnForObjectLiteral": true }` option: - -```js -/* arrow-body-style: ["error", "as-needed", { "requireReturnForObjectLiteral": true }]*/ - -/* ✘ Bad: */ -const foo = () => ({}); -const bar = () => ({ bar: 0 }); -``` - -Examples of **correct** code for this rule with the `{ "requireReturnForObjectLiteral": true }` option: - -```js -/* arrow-body-style: ["error", "as-needed", { "requireReturnForObjectLiteral": true }]*/ - -/* βœ” Good: */ -const foo = () => {}; -const bar = () => { - return { bar: 0 }; -}; -``` - -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny arrow-body-style -``` - -```json [Config (.oxlintrc.json)] -{ - "rules": { - "arrow-body-style": "error" - } -} -``` - -::: - -## References - -- Rule Source diff --git a/src/docs/guide/usage/linter/rules/eslint/block-scoped-var.md b/src/docs/guide/usage/linter/rules/eslint/block-scoped-var.md deleted file mode 100644 index 9e2733c7ece..00000000000 --- a/src/docs/guide/usage/linter/rules/eslint/block-scoped-var.md +++ /dev/null @@ -1,130 +0,0 @@ - - - - -# eslint/block-scoped-var - -
-
- -### What it does - -Enforces that variables are both **declared** and **used** within the same block scope. -This rule prevents accidental use of variables outside their intended block, mimicking C-style block scoping in JavaScript. - -### Why is this bad? - -JavaScript’s `var` declarations are hoisted to the top of their enclosing function, which can cause variables declared in a block (e.g., inside an `if` or `for`) to be accessible outside of it. -This can lead to hard-to-find bugs. -By enforcing block scoping, this rule helps avoid hoisting issues and aligns more closely with how other languages treat block variables. - -### Options - -No options available for this rule. - -### Examples - -Examples of **incorrect** code for this rule: - -```js -/* block-scoped-var: "error" */ - -function doIf() { - if (true) { - var build = true; - } - console.log(build); -} - -function doLoop() { - for (var i = 0; i < 10; i++) { - // do something - } - console.log(i); // i is accessible here -} - -function doSomething() { - if (true) { - var foo = 1; - } - if (false) { - foo = 2; - } -} - -function doTry() { - try { - var foo = 1; - } catch (e) { - console.log(foo); - } -} -``` - -Examples of **correct** code for this rule: - -```js -/* block-scoped-var: "error" */ - -function doIf() { - var build; - if (true) { - build = true; - } - console.log(build); -} - -function doLoop() { - var i; - for (i = 0; i < 10; i++) { - // do something - } - console.log(i); -} - -function doSomething() { - var foo; - if (true) { - foo = 1; - } - if (false) { - foo = 2; - } -} - -function doTry() { - var foo; - try { - foo = 1; - } catch (e) { - console.log(foo); - } -} -``` - -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny block-scoped-var -``` - -```json [Config (.oxlintrc.json)] -{ - "rules": { - "block-scoped-var": "error" - } -} -``` - -::: - -## References - -- Rule Source diff --git a/src/docs/guide/usage/linter/rules/eslint/class-methods-use-this.md b/src/docs/guide/usage/linter/rules/eslint/class-methods-use-this.md deleted file mode 100644 index f055ca6d421..00000000000 --- a/src/docs/guide/usage/linter/rules/eslint/class-methods-use-this.md +++ /dev/null @@ -1,73 +0,0 @@ - - - - -# eslint/class-methods-use-this - -
-
- -### What it does - -Enforce that class methods utilize this. - -### Examples - -Examples of **incorrect** code for this rule: - -```js -class A { - foo() { - console.log("Hello World"); - } -} -``` - -Examples of **correct** code for this rule: - -```js -class A { - foo() { - this.bar = "Hello World"; // OK, this is used - } -} - -class B { - constructor() { - // OK. constructor is exempt - } -} - -class C { - static foo() { - // OK. static methods aren't expected to use this. - } -} -``` - -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny class-methods-use-this -``` - -```json [Config (.oxlintrc.json)] -{ - "rules": { - "class-methods-use-this": "error" - } -} -``` - -::: - -## References - -- Rule Source diff --git a/src/docs/guide/usage/linter/rules/eslint/constructor-super.md b/src/docs/guide/usage/linter/rules/eslint/constructor-super.md index f42bbe2b5dd..ce0d783414d 100644 --- a/src/docs/guide/usage/linter/rules/eslint/constructor-super.md +++ b/src/docs/guide/usage/linter/rules/eslint/constructor-super.md @@ -1,10 +1,5 @@ - - # eslint/constructor-super
@@ -12,89 +7,18 @@ const source = `https://github.com/oxc-project/oxc/blob/${ data }/crates/oxc_lin ### What it does -Requires `super()` calls in constructors of derived classes and disallows `super()` calls -in constructors of non-derived classes. +Require 'super()' calls in constructors. ### Why is this bad? -In JavaScript, calling `super()` in the constructor of a derived class (a class that extends -another class) is required. Failing to do so will result in a ReferenceError at runtime. -Conversely, calling `super()` in a non-derived class is a syntax error. - -### Examples - -Examples of **incorrect** code for this rule: - -```js -// Missing super() call -class A extends B { - constructor() {} -} - -// super() in non-derived class -class A { - constructor() { - super(); - } -} - -// super() only in some code paths -class C extends D { - constructor() { - if (condition) { - super(); - } - } -} -``` - -Examples of **correct** code for this rule: +### Example -```js -// Proper super() call in derived class +```javascript class A extends B { - constructor() { - super(); - } -} - -// No super() in non-derived class -class A { constructor() {} } - -// super() in all code paths -class C extends D { - constructor() { - if (condition) { - super(); - } else { - super(); - } - } -} ``` -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny constructor-super -``` - -```json [Config (.oxlintrc.json)] -{ - "rules": { - "constructor-super": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/eslint/constructor_super.rs) diff --git a/src/docs/guide/usage/linter/rules/eslint/curly.md b/src/docs/guide/usage/linter/rules/eslint/curly.md deleted file mode 100644 index 1e4626892f6..00000000000 --- a/src/docs/guide/usage/linter/rules/eslint/curly.md +++ /dev/null @@ -1,279 +0,0 @@ - - - - -# eslint/curly - -
- -πŸ› οΈ An auto-fix is available for this rule. - -
- -### What it does - -This rule enforces the use of curly braces `{}` for all control statements -(`if`, `else`, `for`, `while`, `do`, `with`). -It ensures that all blocks are enclosed in curly braces to improve code clarity and maintainability. - -### Why is this bad? - -Omitting curly braces can reduce code readability and increase the likelihood of errors, especially in deeply nested or indented code. -It can also lead to bugs if additional statements are added later without properly enclosing them in braces. -Using curly braces consistently makes the code safer and easier to modify. - -### Options - -First option: - -- Type: `string` -- Default: `"all"` -- Possible values: - - `"all"`: require braces in all cases - - `"multi"`: require braces only for multi-statement blocks - - `"multi-line"`: require braces only for multi-line blocks - - `"multi-or-nest"`: require braces for multi-line blocks or when nested - -Second option: - -- Type: `string` -- Default: `undefined` -- Possible values: -- `"consistent"`: require braces if any other branch in the `if-else` chain has braces - -Note : The second option can only be used in conjunction with the first option. - -Example configuration: - -```json -{ - "curly": ["error", "multi-or-nest", "consistent"] -} -``` - -### Examples - -#### `"all"` (default) - -Examples of **incorrect** code for this rule: - -```js -/* curly: ["error", "all"] */ - -if (foo) foo++; -while (bar) bar--; -do foo(); while (bar); -``` - -Examples of **correct** code for this rule: - -```js -/* curly: ["error", "all"] */ - -if (foo) foo++; -while (bar) bar--; -do { - foo(); -} while (bar); -``` - -#### `"multi"` - -Examples of **incorrect** code for this rule with the `"multi"` option: - -```js -/* curly: ["error", "multi"] */ - -if (foo) foo(); -else { - bar(); - baz(); -} -``` - -Examples of **correct** code for this rule with the `"multi"` option: - -```js -/* curly: ["error", "multi"] */ - -if (foo) foo(); -else bar(); -``` - -#### `"multi-line"` - -Examples of **incorrect** code for this rule with the `"multi-line"` option: - -```js -/* curly: ["error", "multi-line"] */ - -if (foo) foo(); -else { - bar(); -} - -while (foo) { - foo(); -} -``` - -Examples of **correct** code for this rule with the `"multi-line"` option: - -```js -/* curly: ["error", "multi-line"] */ - -if (foo) foo(); -else bar(); - -while (foo) foo(); - -while (true) { - doSomething(); - doSomethingElse(); -} -``` - -#### `"multi-or-nest"` - -Examples of **incorrect** code for this rule with the `"multi-or-nest"` option: - -```js -/* curly: ["error", "multi-or-nest"] */ - -if (foo) { - if (bar) bar(); -} - -while (foo) { - while (bar) bar(); -} -``` - -Examples of **correct** code for this rule with the `"multi-or-nest"` option: - -```js -/* curly: ["error", "multi-or-nest"] */ - -if (foo) { - if (bar) bar(); -} - -while (foo) { - while (bar) bar(); -} -``` - -#### `{ "consistent": true }` - -When enabled, `consistent: true` enforces consistent use of braces within an `if-else` chain. -If one branch of the chain uses braces, then all branches must use braces, even if not strictly required by the first option. - -Examples of **incorrect** code with `"multi"` and `consistent: true`: - -```js -/* curly: ["error", "multi", "consistent"] */ - -if (foo) { - bar(); - baz(); -} else qux(); - -if (foo) bar(); -else { - baz(); - qux(); -} -``` - -Examples of **correct** code with `"multi"` and `consistent: true`: - -```js -/* curly: ["error", "multi", "consistent"] */ - -if (foo) { - bar(); - baz(); -} else { - qux(); -} - -if (foo) { - bar(); -} else { - baz(); - qux(); -} -``` - -Examples of **incorrect** code with `"multi-line"` and `consistent: true`: - -```js -/* curly: ["error", "multi-line", "consistent"] */ - -if (foo) { - bar(); -} else { - baz(); -} -``` - -Examples of **correct** code with `"multi-line"` and `consistent: true`: - -```js -/* curly: ["error", "multi-line", "consistent"] */ - -if (foo) { - bar(); -} else { - baz(); -} -``` - -Examples of **incorrect** code with `"multi-or-nest"` and `consistent: true`: - -```js -/* curly: ["error", "multi-or-nest", "consistent"] */ - -if (foo) { - if (bar) baz(); -} else qux(); -``` - -Examples of **correct** code with `"multi-or-nest"` and `consistent: true`: - -```js -/* curly: ["error", "multi-or-nest", "consistent"] */ - -if (foo) { - if (bar) baz(); -} else { - qux(); -} -``` - -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny curly -``` - -```json [Config (.oxlintrc.json)] -{ - "rules": { - "curly": "error" - } -} -``` - -::: - -## References - -- Rule Source diff --git a/src/docs/guide/usage/linter/rules/eslint/default-case-last.md b/src/docs/guide/usage/linter/rules/eslint/default-case-last.md index a99a35e8c0e..0af112a49d0 100644 --- a/src/docs/guide/usage/linter/rules/eslint/default-case-last.md +++ b/src/docs/guide/usage/linter/rules/eslint/default-case-last.md @@ -1,10 +1,5 @@ - - # eslint/default-case-last
@@ -12,25 +7,18 @@ const source = `https://github.com/oxc-project/oxc/blob/${ data }/crates/oxc_lin ### What it does -Requires the `default` clause in `switch` statements to be the last one. +Enforce default clauses in switch statements to be last ### Why is this bad? -By convention and for readability, the `default` clause should be the last one in a `switch`. -While it is legal to place it before or between `case` clauses, doing so is confusing and may -lead to unexpected "fall-through" behavior. - -### Options - -No options available for this rule - -### Examples - -Examples of **incorrect** code for this rule: +A switch statement can optionally have a default clause. +If present, it’s usually the last clause, but it doesn’t need to be. It is also allowed to put the default clause before all case clauses, or anywhere between. The behavior is mostly the same as if it was the last clause. The default block will be still executed only if there is no match in the case clauses (including those defined after the default), but there is also the ability to β€œfall through” from the default clause to the following clause in the list. However, such flow is not common and it would be confusing to the readers. +Even if there is no β€œfall through” logic, it’s still unexpected to see the default clause before or between the case clauses. By convention, it is expected to be the last clause. +If a switch statement should have a default clause, it’s considered a best practice to define it as the last clause. -```js -/* default-case-last: "error" */ +### Example +```javascript switch (foo) { default: bar(); @@ -53,54 +41,6 @@ switch (foo) { } ``` -Examples of **correct** code for this rule: - -```js -/* default-case-last: "error" */ - -switch (foo) { - case 1: - bar(); - break; - case 2: - qux(); - break; - default: - baz(); - break; -} - -switch (foo) { - case "x": - bar(); - break; - case "y": - default: - baz(); - break; -} -``` - -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny default-case-last -``` - -```json [Config (.oxlintrc.json)] -{ - "rules": { - "default-case-last": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/eslint/default_case_last.rs) diff --git a/src/docs/guide/usage/linter/rules/eslint/default-case.md b/src/docs/guide/usage/linter/rules/eslint/default-case.md index dc848ad44c0..84175239d93 100644 --- a/src/docs/guide/usage/linter/rules/eslint/default-case.md +++ b/src/docs/guide/usage/linter/rules/eslint/default-case.md @@ -1,10 +1,5 @@ - - # eslint/default-case
@@ -12,110 +7,22 @@ const source = `https://github.com/oxc-project/oxc/blob/${ data }/crates/oxc_lin ### What it does -Enforces that all `switch` statements include a `default` case, -unless explicitly marked with a configured comment. +Require default cases in switch statements ### Why is this bad? -Without a `default` case, it is unclear whether the omission was -intentional or an oversight. Adding a `default` or a special comment -makes the code more explicit and reduces mistakes. - -You may optionally include a `// no default` after the last case if there is -no default case. The comment may be in any desired case, such as `// No Default`. - -### Options - -First option: - -- Type: `object` -- Properties: - - `commentPattern`: `string` (default: `/^no default$/i`) - A regex pattern used to detect comments that mark the absence of a `default` case as intentional. - -Example configuration: +Some code conventions require that all switch statements have a default case, even if the +default case is empty. -```json -{ - "default-case": ["error", { "commentPattern": "^skip\\sdefault" }] -} -``` - -Examples of **incorrect** code for this rule: - -```js -/* default-case: ["error"] */ +### Example +```javascript switch (foo) { case 1: break; } ``` -Examples of **correct** code for this rule: - -```js -/* default-case: ["error"] */ - -switch (a) { - case 1: - break; - default: - break; -} - -switch (a) { - case 1: - break; - // no default -} -``` - -#### `commentPattern` - -Examples of **incorrect** code for this rule with the `{ "commentPattern": "^skip\\sdefault" }` option: - -```js -/* default-case: ["error", { "commentPattern": "^skip\\sdefault" }] */ - -switch (a) { - case 1: - break; - // no default -} -``` - -Examples of **correct** code for this rule with the `{ "commentPattern": "^skip\\sdefault" }` option: - -```js -/* default-case: ["error", { "commentPattern": "^skip\\sdefault" }] */ - -switch (a) { - case 1: - break; - // skip default -} -``` - -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny default-case -``` - -```json [Config (.oxlintrc.json)] -{ - "rules": { - "default-case": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/eslint/default_case.rs) diff --git a/src/docs/guide/usage/linter/rules/eslint/default-param-last.md b/src/docs/guide/usage/linter/rules/eslint/default-param-last.md index bf961bc017e..0612e542fb8 100644 --- a/src/docs/guide/usage/linter/rules/eslint/default-param-last.md +++ b/src/docs/guide/usage/linter/rules/eslint/default-param-last.md @@ -1,10 +1,5 @@ - - # eslint/default-param-last
@@ -12,83 +7,24 @@ const source = `https://github.com/oxc-project/oxc/blob/${ data }/crates/oxc_lin ### What it does -Requires default parameters in functions to be the last ones. +Enforce default parameters to be last ### Why is this bad? -Placing default parameters last allows function calls to omit optional trailing arguments, -which improves readability and consistency. This rule applies equally to JavaScript and -TypeScript functions. - -### Options - -No options available for this rule - -### Examples - -Examples of **incorrect** code for this rule: - -```js -/* default-param-last: "error" */ - -function f(a = 0, b) {} -function f(a, b = 0, c) {} -function createUser(isAdmin = false, id) {} -createUser(undefined, "tabby"); -``` - -Examples of **correct** code for this rule: +Putting default parameter at last allows function calls to omit optional tail arguments. -```js -/* default-param-last: "error" */ +### Example -function f(a, b = 0) {} -function f(a = 0, b = 0) {} +```javascript +// Correct: optional argument can be omitted function createUser(id, isAdmin = false) {} createUser("tabby"); -``` - -Examples of **incorrect** TypeScript code for this rule: - -```ts -/* default-param-last: "error" */ -function greet(message: string = "Hello", name: string) {} -function combine(a: number = 1, b: number, c: number) {} -function combine(a: number, b: number = 2, c: number) {} -function combine(a: number = 1, b?: number, c: number) {} -``` - -Examples of **correct** TypeScript code for this rule: - -```ts -/* default-param-last: "error" */ - -function greet(name: string, message: string = "Hello") {} -function combine(a: number, b: number = 2, c: number = 3) {} -function combine(a: number, b?: number, c: number = 3) {} -``` - -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny default-param-last -``` - -```json [Config (.oxlintrc.json)] -{ - "rules": { - "default-param-last": "error" - } -} +// Incorrect: optional argument can **not** be omitted +function createUser(isAdmin = false, id) {} +createUser(undefined, "tabby"); ``` -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/eslint/default_param_last.rs) diff --git a/src/docs/guide/usage/linter/rules/eslint/eqeqeq.md b/src/docs/guide/usage/linter/rules/eslint/eqeqeq.md index 88540d6d6a3..3080172a8cc 100644 --- a/src/docs/guide/usage/linter/rules/eslint/eqeqeq.md +++ b/src/docs/guide/usage/linter/rules/eslint/eqeqeq.md @@ -1,197 +1,29 @@ - - # eslint/eqeqeq
-βš οΈπŸ› οΈοΈ A dangerous auto-fix is available for this rule for some violations. +πŸ› οΈ An auto-fix is available for this rule for some violations.
### What it does -Requires the use of the `===` and `!==` operators, disallowing the use of `==` and `!=`. +Requires the use of the === and !== operators ### Why is this bad? -Using non-strict equality operators leads to unexpected behavior due to type coercion, which can cause hard-to-find bugs. - -### Options - -First option: - -- Type: `string` -- Default: `"always"` - -Possible values: - -- `"always"` - always require `===`/`!==` -- `"smart"` - allow safe comparisons (`typeof`, literals, nullish) - -Second option (only used with `"always"`): - -- Type: `object` -- Properties: - - `null`: `string` (default: `"always"`) - `"ignore"` allows `== null` and `!= null`. - -Possible values for `null`: - -- `"always"` - always require `=== null`/`!== null` -- `"never"` - always require `== null`/`!= null` -- `"ignore"` - allow both `== null`/`!= null` and `=== null`/`!== null` - -Example JSON configuration: - -```json -{ - "eqeqeq": ["error", "always", { "null": "ignore" }] -} -``` - -### Examples - -#### `"always"` (default) - -Examples of **incorrect** code for this rule: - -```js -/* eslint eqeqeq: "error" */ - -if (x == 42) {} -if ("" == text) {} -if (obj.getStuff() != undefined) {} -``` - -Examples of **correct** code for this rule: - -```js -/* eslint eqeqeq: "error" */ - -if (x === 42) {} -if ("" === text) {} -if (obj.getStuff() !== undefined) {} -``` - -#### `"smart"` - -Examples of **incorrect** code for this rule with the `"smart"` option: - -```js -/* eslint eqeqeq: ["error", "smart"] */ - -if (x == 42) {} -if ("" == text) {} -``` - -Examples of **correct** code for this rule with the `"smart"` option: - -```js -/* eslint eqeqeq: ["error", "smart"] */ - -if (typeof foo == "undefined") {} -if (foo == null) {} -if (foo != null) {} -``` - -#### `{"null": "ignore"}` (with `"always"` first option) - -Examples of **incorrect** code for this rule with the `{ "null": "ignore" }` option: +Using non-strict equality operators leads to hard to track bugs due to type coercion. -```js -/* eslint eqeqeq: ["error", "always", { "null": "ignore" }] */ -if (x == 42) {} -if ("" == text) {} -``` - -Examples of **correct** code for this rule with the `{ "null": "ignore" }` option: - -```js -/* eslint eqeqeq: ["error", "always", { "null": "ignore" }] */ -if (foo == null) {} -if (foo != null) {} -``` - -#### `{"null": "always"}` (default - with `"always"` first option) - -Examples of **incorrect** code for this rule with the `{ "null": "always" }` option: - -```js -/* eslint eqeqeq: ["error", "always", { "null": "always" }] */ - -if (foo == null) {} -if (foo != null) {} -``` - -Examples of **correct** code for this rule with the `{ "null": "always" }` option: - -```js -/* eslint eqeqeq: ["error", "always", { "null": "always" }] */ - -if (foo === null) {} -if (foo !== null) {} -``` - -#### `{"null": "never"}` (with `"always"` first option) - -Examples of **incorrect** code for this rule with the `{ "null": "never" }` option: - -```js -/* eslint eqeqeq: ["error", "always", { "null": "never" }] */ - -if (x == 42) {} -if ("" == text) {} -if (foo === null) {} -if (foo !== null) {} -``` - -Examples of **correct** code for this rule with the `{ "null": "never" }` option: - -```js -/* eslint eqeqeq: ["error", "always", { "null": "never" }] */ +### Example -if (x === 42) {} -if ("" === text) {} -if (foo == null) {} -if (foo != null) {} +```javascript +let a = []; +let b = false; +a == b; ``` -## Configuration - -This rule accepts a configuration object with the following properties: - -### compareType - -type: `"always" | "smart"` - -### nullType - -type: `"always" | "never" | "ignore"` - -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny eqeqeq -``` - -```json [Config (.oxlintrc.json)] -{ - "rules": { - "eqeqeq": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/eslint/eqeqeq.rs) diff --git a/src/docs/guide/usage/linter/rules/eslint/for-direction.md b/src/docs/guide/usage/linter/rules/eslint/for-direction.md index 3484cad5d86..f895b4f9200 100644 --- a/src/docs/guide/usage/linter/rules/eslint/for-direction.md +++ b/src/docs/guide/usage/linter/rules/eslint/for-direction.md @@ -1,10 +1,5 @@ - - # eslint/for-direction
@@ -18,81 +13,57 @@ const source = `https://github.com/oxc-project/oxc/blob/${ data }/crates/oxc_lin ### What it does -Disallow `for` loops where the update clause moves the counter in the wrong -direction, preventing the loop from reaching its stop condition. +Disallow `for` loop update causing the counter to move in the wrong direction. ### Why is this bad? -A `for` loop with a stop condition that can never be reached will run -infinitely. While infinite loops can be intentional, they are usually written -as `while` loops. More often, an infinite `for` loop is a bug. - -### Options +A `for` loop with a stop condition that can never be reached, such as one +with a counter that moves in the wrong direction, will run infinitely. +While there are occasions when an infinite loop is intended, the +convention is to construct such loops as `while` loops. More typically, an +infinite `for` loop is a bug. -No options available for this rule. +This rule forbids `for` loops where the counter variable changes in such a +way that the stop condition will never be met. For example, if the +counter variable is increasing (i.e. `i++`) and the stop condition tests +that the counter is greater than zero (`i >= 0`) then the loop will never +exit. -### Examples +### Example Examples of **incorrect** code for this rule: ```js -/* eslint for-direction: "error" */ +for (var i = 0; i < 10; i--) {} -for (var i = 0; i < 10; i--) { -} - -for (var i = 10; i >= 0; i++) { -} +for (var i = 10; i >= 0; i++) {} -for (var i = 0; i > 10; i++) { -} +for (var i = 0; i > 10; i++) {} -for (var i = 0; 10 > i; i--) { -} +for (var i = 0; 10 > i; i--) {} const n = -2; -for (let i = 0; i < 10; i += n) { -} +for (let i = 0; i < 10; i += n) {} ``` Examples of **correct** code for this rule: ```js -/* eslint for-direction: "error" */ - -for (var i = 0; i < 10; i++) { -} +for (var i = 0; i < 10; i++) {} -for (var i = 0; 10 > i; i++) { // with counter "i" on the right +for (var i = 0; 10 > i; i++) { + // with counter "i" on the right } -for (let i = 10; i >= 0; i += this.step) { // direction unknown +for (let i = 10; i >= 0; i += this.step) { + // direction unknown } -for (let i = MIN; i <= MAX; i -= 0) { // not increasing or decreasing +for (let i = MIN; i <= MAX; i -= 0) { + // not increasing or decreasing } ``` -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny for-direction -``` - -```json [Config (.oxlintrc.json)] -{ - "rules": { - "for-direction": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/eslint/for_direction.rs) diff --git a/src/docs/guide/usage/linter/rules/eslint/func-names.md b/src/docs/guide/usage/linter/rules/eslint/func-names.md index a3784d970ed..ff652cfe659 100644 --- a/src/docs/guide/usage/linter/rules/eslint/func-names.md +++ b/src/docs/guide/usage/linter/rules/eslint/func-names.md @@ -1,10 +1,5 @@ - - # eslint/func-names
@@ -21,195 +16,68 @@ Require or disallow named function expressions. Leaving the name off a function will cause `` to appear in stack traces of errors thrown in it or any function called within it. -This makes it more difficult to find where an error is thrown. -Providing an explicit name also improves readability and consistency. - -### Options +This makes it more difficult to find where an error is thrown. If you +provide the optional name for a function expression then you will get +the name of the function expression in the stack trace. -First option: +## Configuration -- Type: `string` -- Default: `"always"` -- Possible values: - - `"always"` - requires all function expressions to have a name. - - `"as-needed"` - requires a name only if one is not automatically inferred. - - `"never"` - disallows names for function expressions. +This rule has a string option: -Second option: +- `"always"` requires a function expression to have a name under all + circumstances. +- `"as-needed"` requires a function expression to have a name only when + one will not be automatically inferred by the runtime. +- `"never"` requires a function expression to not have a name under any + circumstances. -- Type: `object` -- Properties: - - `generators`: `("always" | "as-needed" | "never")` (default: falls back to first option) - - `"always"` - require named generator function expressions. - - `"as-needed"` - require a name only when not inferred. - - `"never"` - disallow names for generator function expressions. - -Example configuration: - -```json -{ - "func-names": ["error", "as-needed", { "generators": "never" }] -} -``` - -### Examples +### Example Examples of **incorrect** code for this rule: -```js -/* func-names: ["error", "always"] */ - -Foo.prototype.bar = function() {}; -const cat = { meow: function() {} }; -(function() {/* ... */})(); -export default function() {} -``` - -Examples of **correct** code for this rule: - -```js -/* func-names: ["error", "always"] */ - -Foo.prototype.bar = function bar() {}; -const cat = { meow() {} }; -(function bar() {/* ... */})(); -export default function foo() {} -``` - -#### `as-needed` +```javascript +/*oxlint func-names: "error" */ -Examples of **incorrect** code for this rule with the `"as-needed"` option: +// default is "always" and there is an anonymous function +Foo.prototype.bar = function () {}; -```js -/* func-names: ["error", "as-needed"] */ +/*oxlint func-names: ["error", "always"] */ -Foo.prototype.bar = function() {}; -(function() {/* ... */})(); -export default function() {} -``` - -Examples of **correct** code for this rule with the `"as-needed"` option: +// there is an anonymous function +Foo.prototype.bar = function () {}; -```js -/* func-names: ["error", "as-needed"] */ - -const bar = function() {}; -const cat = { meow: function() {} }; -class C { - #bar = function() {}; - baz = function() {}; -} -quux ??= function() {}; -(function bar() {/* ... */})(); -export default function foo() {} -``` +/*oxlint func-names: ["error", "as-needed"] */ -#### `never` +// there is an anonymous function +// where the name isn’t assigned automatically per the ECMAScript specs +Foo.prototype.bar = function () {}; -Examples of **incorrect** code for this rule with the `"never"` option: - -```js -/* func-names: ["error", "never"] */ +/*oxlint func-names: ["error", "never"] */ +// there is a named function Foo.prototype.bar = function bar() {}; -(function bar() {/* ... */})(); -``` - -Examples of **correct** code for this rule with the `"never"` option: - -```js -/* func-names: ["error", "never"] */ - -Foo.prototype.bar = function() {}; -(function() {/* ... */})(); -``` - -#### `generators` - -Examples of **incorrect** code for this rule with the `"always", { "generators": "as-needed" }` options: - -```js -/* func-names: ["error", "always", { "generators": "as-needed" }] */ - -(function*() {/* ... */})(); ``` -Examples of **correct** code for this rule with the `"always", { "generators": "as-needed" }` options: +Examples of \*_correct_ code for this rule: -```js -/* func-names: ["error", "always", { "generators": "as-needed" }] */ +```javascript +/*oxlint func-names: "error" */ -const foo = function*() {}; -``` - -Examples of **incorrect** code for this rule with the `"always", { "generators": "never" }` options: - -```js -/* func-names: ["error", "always", { "generators": "never" }] */ - -const foo = bar(function* baz() {}); -``` - -Examples of **correct** code for this rule with the `"always", { "generators": "never" }` options: - -```js -/* func-names: ["error", "always", { "generators": "never" }] */ - -const foo = bar(function*() {}); -``` - -Examples of **incorrect** code for this rule with the `"as-needed", { "generators": "never" }` options: - -```js -/* func-names: ["error", "as-needed", { "generators": "never" }] */ - -const foo = bar(function* baz() {}); -``` - -Examples of **correct** code for this rule with the `"as-needed", { "generators": "never" }` options: - -```js -/* func-names: ["error", "as-needed", { "generators": "never" }] */ - -const foo = bar(function*() {}); -``` - -Examples of **incorrect** code for this rule with the `"never", { "generators": "always" }` options: - -```js -/* func-names: ["error", "never", { "generators": "always" }] */ - -const foo = bar(function*() {}); -``` - -Examples of **correct** code for this rule with the `"never", { "generators": "always" }` options: - -```js -/* func-names: ["error", "never", { "generators": "always" }] */ +Foo.prototype.bar = function bar() {}; -const foo = bar(function* baz() {}); -``` +/*oxlint func-names: ["error", "always"] */ -## How to use +Foo.prototype.bar = function bar() {}; -To **enable** this rule in the CLI or using the config file, you can use: +/*oxlint func-names: ["error", "as-needed"] */ -::: code-group +var foo = function () {}; -```bash [CLI] -oxlint --deny func-names -``` +/*oxlint func-names: ["error", "never"] */ -```json [Config (.oxlintrc.json)] -{ - "rules": { - "func-names": "error" - } -} +Foo.prototype.bar = function () {}; ``` -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/eslint/func_names.rs) diff --git a/src/docs/guide/usage/linter/rules/eslint/func-style.md b/src/docs/guide/usage/linter/rules/eslint/func-style.md deleted file mode 100644 index b5a4cf4ec2b..00000000000 --- a/src/docs/guide/usage/linter/rules/eslint/func-style.md +++ /dev/null @@ -1,197 +0,0 @@ - - - - -# eslint/func-style - -
- -🚧 An auto-fix is still under development. - -
- -### What it does - -Enforce the consistent use of either function declarations or expressions assigned to variables - -### Why is this bad? - -This rule enforces a particular type of function style, either function declarations or expressions assigned to variables. -You can specify which you prefer in the configuration. - -### Examples - -```js -// function declaration -function doSomething() { - // ... -} - -// arrow function expression assigned to a variable -const doSomethingElse = () => { - // ... -}; - -// function expression assigned to a variable -const doSomethingAgain = function() { - // ... -}; -``` - -Examples of incorrect code for this rule with the default "expression" option: - -```js -/*eslint func-style: ["error", "expression"]*/ - -function foo() { - // ... -} -``` - -Examples of incorrect code for this rule with the "declaration" option: - -```js -/*eslint func-style: ["error", "declaration"]*/ -var foo = function() { - // ... -}; - -var foo = () => {}; -``` - -Examples of incorrect code for this rule with the "declaration" and {"overrides": { "namedExports": "expression" }} option: - -```js -/*eslint func-style: ["error", "declaration", { "overrides": { "namedExports": "expression" } }]*/ -export function foo() { - // ... -} -``` - -Examples of incorrect code for this rule with the "expression" and {"overrides": { "namedExports": "declaration" }} option: - -```js -/*eslint func-style: ["error", "expression", { "overrides": { "namedExports": "declaration" } }]*/ -export var foo = function() { - // ... -}; - -export var bar = () => {}; -``` - -Examples of correct code for this rule with the default "expression" option: - -```js -/*eslint func-style: ["error", "expression"]*/ -var foo = function() { - // ... -}; -``` - -Examples of correct code for this rule with the "declaration" option: - -```js -/*eslint func-style: ["error", "declaration"]*/ -function foo() { - // ... -} -// Methods (functions assigned to objects) are not checked by this rule -SomeObject.foo = function() { - // ... -}; -``` - -Examples of additional correct code for this rule with the "declaration", { "allowArrowFunctions": true } options: - -```js -/*eslint func-style: ["error", "declaration", { "allowArrowFunctions": true }]*/ -var foo = () => {}; -``` - -Examples of correct code for this rule with the "declaration" and {"overrides": { "namedExports": "expression" }} option: - -```js -/*eslint func-style: ["error", "declaration", { "overrides": { "namedExports": "expression" } }]*/ -export var foo = function() { - // ... -}; -export var bar = () => {}; -``` - -Examples of correct code for this rule with the "expression" and {"overrides": { "namedExports": "declaration" }} option: - -```js -/*eslint func-style: ["error", "expression", { "overrides": { "namedExports": "declaration" } }]*/ -export function foo() { - // ... -} -``` - -Examples of correct code for this rule with the {"overrides": { "namedExports": "ignore" }} option: - -```js -/*eslint func-style: ["error", "expression", { "overrides": { "namedExports": "ignore" } }]*/ -export var foo = function() { - // ... -}; - -export var bar = () => {}; -export function baz() { - // ... -} -``` - -## Configuration - -This rule accepts a configuration object with the following properties: - -### allowArrowFunctions - -type: `boolean` - -default: `false` - -When true, arrow functions are allowed regardless of the style setting. - -### allowTypeAnnotation - -type: `boolean` - -default: `false` - -When true, functions with type annotations are allowed regardless of the style setting. - -### style - -type: `"expression" | "declaration"` - -default: `"expression"` - -The style to enforce. Either "expression" (default) or "declaration". - -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny func-style -``` - -```json [Config (.oxlintrc.json)] -{ - "rules": { - "func-style": "error" - } -} -``` - -::: - -## References - -- Rule Source diff --git a/src/docs/guide/usage/linter/rules/eslint/getter-return.md b/src/docs/guide/usage/linter/rules/eslint/getter-return.md index 4bfcdd4fc57..d9a0210e98f 100644 --- a/src/docs/guide/usage/linter/rules/eslint/getter-return.md +++ b/src/docs/guide/usage/linter/rules/eslint/getter-return.md @@ -1,10 +1,5 @@ - - # eslint/getter-return
@@ -21,7 +16,7 @@ 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. -### Examples +### Example Examples of **incorrect** code for this rule: @@ -49,26 +44,6 @@ class Person { } ``` -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny getter-return -``` - -```json [Config (.oxlintrc.json)] -{ - "rules": { - "getter-return": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/eslint/getter_return.rs) diff --git a/src/docs/guide/usage/linter/rules/eslint/grouped-accessor-pairs.md b/src/docs/guide/usage/linter/rules/eslint/grouped-accessor-pairs.md deleted file mode 100644 index dc5bf73dc2d..00000000000 --- a/src/docs/guide/usage/linter/rules/eslint/grouped-accessor-pairs.md +++ /dev/null @@ -1,176 +0,0 @@ - - - - -# eslint/grouped-accessor-pairs - -
- -🚧 An auto-fix is still under development. - -
- -### What it does - -Require grouped accessor pairs in object literals and classes - -### Why is this bad? - -While it is allowed to define the pair for a getter or a setter anywhere in an object or class definition, -it’s considered a best practice to group accessor functions for the same property. - -### Examples - -Examples of **incorrect** code for this rule: - -```js -const foo = { - get a() { - return this.val; - }, - b: 1, - set a(value) { - this.val = value; - }, -}; -``` - -Examples of **correct** code for this rule: - -```js -const foo = { - get a() { - return this.val; - }, - set a(value) { - this.val = value; - }, - b: 1, -}; -``` - -Examples of **incorrect** code for this rule with the `getBeforeSet` option: - -```js -const foo = { - set a(value) { - this.val = value; - }, - get a() { - return this.val; - }, -}; -``` - -Examples of **correct** code for this rule with the `getBeforeSet` option: - -```js -const foo = { - get a() { - return this.val; - }, - set a(value) { - this.val = value; - }, -}; -``` - -Examples of **incorrect** code for this rule with the `setBeforeGet` option: - -```js -const foo = { - get a() { - return this.val; - }, - set a(value) { - this.val = value; - }, -}; -``` - -Examples of **correct** code for this rule with the `setBeforeGet` option: - -```js -const foo = { - set a(value) { - this.val = value; - }, - get a() { - return this.val; - }, -}; -``` - -### Options - -This rule accepts two arguments: - -1. A string value to control the order of the getter/setter pairs: - - `"anyOrder"` (default): Accessors can be in any order - - `"getBeforeSet"`: Getters must come before setters - - `"setBeforeGet"`: Setters must come before getters -2. An object with the following option: - - `enforceForTSTypes` (boolean, default: false): When enabled, also checks TypeScript interfaces and type aliases for grouped accessor pairs - -### TypeScript - -When `enforceForTSTypes` is enabled, this rule also applies to TypeScript interfaces and type aliases: - -Examples of **incorrect** TypeScript code: - -```ts -interface Foo { - get a(): string; - someProperty: string; - set a(value: string); -} - -type Bar = { - get b(): string; - someProperty: string; - set b(value: string); -}; -``` - -Examples of **correct** TypeScript code: - -```ts -interface Foo { - get a(): string; - set a(value: string); - someProperty: string; -} - -type Bar = { - get b(): string; - set b(value: string); - someProperty: string; -}; -``` - -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny grouped-accessor-pairs -``` - -```json [Config (.oxlintrc.json)] -{ - "rules": { - "grouped-accessor-pairs": "error" - } -} -``` - -::: - -## References - -- Rule Source diff --git a/src/docs/guide/usage/linter/rules/eslint/guard-for-in.md b/src/docs/guide/usage/linter/rules/eslint/guard-for-in.md index 891fe7d77b9..a5b36bd4757 100644 --- a/src/docs/guide/usage/linter/rules/eslint/guard-for-in.md +++ b/src/docs/guide/usage/linter/rules/eslint/guard-for-in.md @@ -1,10 +1,5 @@ - - # eslint/guard-for-in
@@ -12,17 +7,11 @@ const source = `https://github.com/oxc-project/oxc/blob/${ data }/crates/oxc_lin ### What it does -Require for-in loops to include an if statement. +This rule is aimed at preventing unexpected behavior that could arise from using a for in loop without filtering the results in the loop. As such, it will warn when for in loops do not filter their results with an if statement. ### Why is this bad? -Looping over objects with a `for in` loop will include properties that are inherited through -the prototype chain. Using a `for in` loop without filtering the results in the loop can -lead to unexpected items in your for loop which can then lead to unexpected behaviour. - -### Examples - -Examples of **incorrect** code for this rule: +### Example ```javascript for (key in foo) { @@ -30,52 +19,6 @@ for (key in foo) { } ``` -Examples of **correct** code for this rule: - -```javascript -for (key in foo) { - if (Object.hasOwn(foo, key)) { - doSomething(key); - } -} -``` - -```javascript -for (key in foo) { - if (Object.prototype.hasOwnProperty.call(foo, key)) { - doSomething(key); - } -} -``` - -```javascript -for (key in foo) { - if ({}.hasOwnProperty.call(foo, key)) { - doSomething(key); - } -} -``` - -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny guard-for-in -``` - -```json [Config (.oxlintrc.json)] -{ - "rules": { - "guard-for-in": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/eslint/guard_for_in.rs) diff --git a/src/docs/guide/usage/linter/rules/eslint/id-length.md b/src/docs/guide/usage/linter/rules/eslint/id-length.md deleted file mode 100644 index 235ef4f49bb..00000000000 --- a/src/docs/guide/usage/linter/rules/eslint/id-length.md +++ /dev/null @@ -1,140 +0,0 @@ - - - - -# eslint/id-length - -
-
- -### What it does - -This rule enforces a minimum and/or maximum identifier length convention by counting the -graphemes for a given identifier. - -### Why is this bad? - -Very short identifier names like e, x, _t or very long ones like -hashGeneratorResultOutputContainerObject can make code harder to read and potentially less -maintainable. To prevent this, one may enforce a minimum and/or maximum identifier length. - -### Examples - -Examples of **incorrect** code for this rule: - -```js -/*eslint id-length: "error"*/ -// default is minimum 2-chars ({ "min": 2 }) - -const x = 5; -obj.e = document.body; -const foo = function(e) {}; -try { - dangerousStuff(); -} catch (e) { - // ignore as many do -} -const myObj = { a: 1 }; -((a) => { - a * a; -}); -class y {} -class Foo { - x() {} -} -class Bar { - #x() {} -} -class Baz { - x = 1; -} -class Qux { - #x = 1; -} -function bar(...x) {} -function baz([x]) {} -const [z] = arr; -const { prop: [i] } = {}; -function qux({ x }) {} -const { j } = {}; -const { prop: a } = {}; -({ prop: obj.x } = {}); -``` - -Examples of **correct** code for this rule: - -```js -/*eslint id-length: "error"*/ -// default is minimum 2-chars ({ "min": 2 }) - -const num = 5; -function _f() { - return 42; -} -function _func() { - return 42; -} -obj.el = document.body; -const foo = function(evt) {/* do stuff */}; -try { - dangerousStuff(); -} catch (error) { - // ignore as many do -} -const myObj = { apple: 1 }; -((num) => { - num * num; -}); -function bar(num = 0) {} -class MyClass {} -class Foo { - method() {} -} -class Bar { - #method() {} -} -class Baz { - field = 1; -} -class Qux { - #field = 1; -} -function baz(...args) {} -function qux([longName]) {} -const { prop } = {}; -const { prop: [name] } = {}; -const [longName] = arr; -function foobar({ prop }) {} -function foobaz({ a: prop }) {} -const { a: property } = {}; -({ prop: obj.longName } = {}); -const data = { "x": 1 }; // excused because of quotes -data["y"] = 3; // excused because of calculated property access -``` - -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny id-length -``` - -```json [Config (.oxlintrc.json)] -{ - "rules": { - "id-length": "error" - } -} -``` - -::: - -## References - -- Rule Source diff --git a/src/docs/guide/usage/linter/rules/eslint/init-declarations.md b/src/docs/guide/usage/linter/rules/eslint/init-declarations.md deleted file mode 100644 index ce9765ab742..00000000000 --- a/src/docs/guide/usage/linter/rules/eslint/init-declarations.md +++ /dev/null @@ -1,106 +0,0 @@ - - - - -# eslint/init-declarations - -
-
- -### What it does - -Require or disallow initialization in variable declarations - -### Why is this bad? - -In JavaScript, variables can be assigned during declaration, or at any point afterwards using an assignment statement. -For example, in the following code, foo is initialized during declaration, while bar is initialized later. - -### Examples - -var foo = 1; -var bar; -if (foo) { -bar = 1; -} else { -bar = 2; -} - -Examples of incorrect code for the default "always" option: - -```js -/*eslint init-declarations: ["error", "always"]*/ -function foo() { - var bar; - let baz; -} -``` - -Examples of incorrect code for the "never" option: - -```js -/*eslint init-declarations: ["error", "never"]*/ -function foo() { - var bar = 1; - let baz = 2; - for (var i = 0; i < 1; i++) {} -} -``` - -Examples of correct code for the default "always" option: - -```js -/*eslint init-declarations: ["error", "always"]*/ - -function foo() { - var bar = 1; - let baz = 2; - const qux = 3; -} -``` - -Examples of correct code for the "never" option: - -```js -/*eslint init-declarations: ["error", "never"]*/ - -function foo() { - var bar; - let baz; - const buzz = 1; -} -``` - -Examples of correct code for the "never", { "ignoreForLoopInit": true } options: - -```js -/*eslint init-declarations: ["error", "never", { "ignoreForLoopInit": true }]*/ -for (var i = 0; i < 1; i++) {} -``` - -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny init-declarations -``` - -```json [Config (.oxlintrc.json)] -{ - "rules": { - "init-declarations": "error" - } -} -``` - -::: - -## References - -- Rule Source diff --git a/src/docs/guide/usage/linter/rules/eslint/max-classes-per-file.md b/src/docs/guide/usage/linter/rules/eslint/max-classes-per-file.md index 90cd147bdd7..e2d1f1958e1 100644 --- a/src/docs/guide/usage/linter/rules/eslint/max-classes-per-file.md +++ b/src/docs/guide/usage/linter/rules/eslint/max-classes-per-file.md @@ -1,10 +1,5 @@ - - # eslint/max-classes-per-file
@@ -19,45 +14,13 @@ Enforce a maximum number of classes per file Files containing multiple classes can often result in a less navigable and poorly structured codebase. Best practice is to keep each file limited to a single responsibility. -### Examples - -Examples of **incorrect** code for this rule: +### Example ```javascript class Foo {} class Bar {} ``` -Examples of **correct** code for this rule: - -```js -function foo() { - var bar = 1; - let baz = 2; - const qux = 3; -} -``` - -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny max-classes-per-file -``` - -```json [Config (.oxlintrc.json)] -{ - "rules": { - "max-classes-per-file": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/eslint/max_classes_per_file.rs) diff --git a/src/docs/guide/usage/linter/rules/eslint/max-depth.md b/src/docs/guide/usage/linter/rules/eslint/max-depth.md deleted file mode 100644 index 85196913527..00000000000 --- a/src/docs/guide/usage/linter/rules/eslint/max-depth.md +++ /dev/null @@ -1,124 +0,0 @@ - - - - -# eslint/max-depth - -
-
- -### What it does - -Enforce a maximum depth that blocks can be nested. This rule helps to limit the complexity -of nested blocks, improving readability and maintainability by ensuring that code does not -become too deeply nested. - -### Why is this bad? - -Many developers consider code difficult to read if blocks are nested beyond a certain depth. -Excessive nesting can make it harder to follow the flow of the code, increasing cognitive load -and making maintenance more error-prone. By enforcing a maximum block depth, this rule encourages -cleaner, more readable code. - -### Examples - -Examples of **incorrect** code for this rule with the default `{ "max": 3 }` option: - -```js -function foo() { - for (;;) { // Nested 1 deep - while (true) { // Nested 2 deep - if (true) { // Nested 3 deep - if (true) { // Nested 4 deep } - } - } - } -} -``` - -Examples of **correct** code for this rule with the default `{ "max": 3 }` option: - -```js -function foo() { - for (;;) { // Nested 1 deep - while (true) { // Nested 2 deep - if (true) { // Nested 3 deep } - } - } -} -``` - -Note that class static blocks do not count as nested blocks, and that the depth in -them is calculated separately from the enclosing context. - -Example: - -```js -function foo() { - if (true) { // Nested 1 deep - class C { - static { - if (true) { // Nested 1 deep - if (true) { // Nested 2 deep } - } - } - } - } -} -``` - -### Options - -#### max - -`{ type: number, default: 4 }` - -The `max` enforces a maximum depth that blocks can be nested - -Example: - -```json -"eslint/max-depth": ["error", 4] - -"eslint/max-depth": [ - "error", - { - max: 4 - } -] -``` - -## Configuration - -This rule accepts a configuration object with the following properties: - -### max - -type: `integer` - -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny max-depth -``` - -```json [Config (.oxlintrc.json)] -{ - "rules": { - "max-depth": "error" - } -} -``` - -::: - -## References - -- Rule Source diff --git a/src/docs/guide/usage/linter/rules/eslint/max-lines-per-function.md b/src/docs/guide/usage/linter/rules/eslint/max-lines-per-function.md deleted file mode 100644 index 3bbaded2c82..00000000000 --- a/src/docs/guide/usage/linter/rules/eslint/max-lines-per-function.md +++ /dev/null @@ -1,124 +0,0 @@ - - - - -# eslint/max-lines-per-function - -
-
- -### What it does - -Enforce a maximum number of lines of code in a function. This rule ensures -that functions do not exceed a specified line count, promoting smaller, -more focused functions that are easier to maintain and understand. - -### Why is this bad? - -Some people consider large functions a code smell. Large functions tend to -do a lot of things and can make it hard to follow what’s going on. Many coding -style guides dictate a limit to the number of lines that a function can -comprise of. This rule can help enforce that style. - -### Examples - -Examples of **incorrect** code for this rule with a particular max value: - -```js -/* { "eslint/max-lines-per-function": ["error", 2] } */ -function foo() { - const x = 0; -} - -/* { "eslint/max-lines-per-function": ["error", 4] } */ -function foo() { - // a comment followed by a blank line - - const x = 0; -} -``` - -Examples of **correct** code for this rule with a particular max value: - -```js -/* { "eslint/max-lines-per-function": ["error", 3] } */ -function foo() { - const x = 0; -} - -/* { "eslint/max-lines-per-function": ["error", 5] } */ -function foo() { - // a comment followed by a blank line - - const x = 0; -} -``` - -### Options - -#### max - -{ type: number, default: 50 } - -The `max` enforces a maximum number of lines in a function. - -#### skipBlankLines - -{ type: boolean, default: false } - -The `skipBlankLines` ignore lines made up purely of whitespace. - -#### skipComments - -{ type: boolean, default: false } - -The `skipComments` ignore lines containing just comments. - -#### IIFEs - -{ type: boolean, default: false } - -The `IIFEs` option controls whether IIFEs are included in the line count. -By default, IIFEs are not considered, but when set to `true`, they will -be included in the line count for the function. - -Example: - -```json -"eslint/max-lines-per-function": [ - "error", - { - "max": 50, - "skipBlankLines": false, - "skipComments": false, - "IIFEs": false - } -] -``` - -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny max-lines-per-function -``` - -```json [Config (.oxlintrc.json)] -{ - "rules": { - "max-lines-per-function": "error" - } -} -``` - -::: - -## References - -- Rule Source diff --git a/src/docs/guide/usage/linter/rules/eslint/max-lines.md b/src/docs/guide/usage/linter/rules/eslint/max-lines.md index 957b66aefee..6c492e52ae6 100644 --- a/src/docs/guide/usage/linter/rules/eslint/max-lines.md +++ b/src/docs/guide/usage/linter/rules/eslint/max-lines.md @@ -1,10 +1,5 @@ - - # eslint/max-lines
@@ -22,26 +17,6 @@ is not an objective maximum number of lines considered acceptable in a file, most people would agree it should not be in the thousands. Recommendations usually range from 100 to 500 lines. -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny max-lines -``` - -```json [Config (.oxlintrc.json)] -{ - "rules": { - "max-lines": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/eslint/max_lines.rs) diff --git a/src/docs/guide/usage/linter/rules/eslint/max-nested-callbacks.md b/src/docs/guide/usage/linter/rules/eslint/max-nested-callbacks.md deleted file mode 100644 index c705813a6b7..00000000000 --- a/src/docs/guide/usage/linter/rules/eslint/max-nested-callbacks.md +++ /dev/null @@ -1,107 +0,0 @@ - - - - -# eslint/max-nested-callbacks - -
-
- -### What it does - -Enforce a maximum depth that callbacks can be nested. This rule helps to limit -the complexity of callback nesting, ensuring that callbacks do not become too -deeply nested, improving code readability and maintainability. - -### Why is this bad? - -Many JavaScript libraries use the callback pattern to manage asynchronous -operations. A program of any complexity will most likely need to manage several -asynchronous operations at various levels of concurrency. A common pitfall is -nesting callbacks excessively, making code harder to read and understand. - -### Examples - -Examples of **incorrect** code for this rule with the `{ "max": 3 }` option: - -```js -foo1(function() { - foo2(function() { - foo3(function() { - foo4(function() { - // ... - }); - }); - }); -}); -``` - -Examples of **correct** code for this rule with the `{ "max": 3 }` option: - -```js -foo1(handleFoo1); - -function handleFoo1() { - foo2(handleFoo2); -} - -function handleFoo2() { - foo3(handleFoo3); -} - -function handleFoo3() { - foo4(handleFoo4); -} - -function handleFoo4() { - foo5(); -} -``` - -### Options - -#### max - -`{ type: number, default: 10 }` - -The `max` enforces a maximum depth that callbacks can be nested. - -Example: - -```json -"eslint/max-nested-callbacks": ["error", 10] - -"eslint/max-nested-callbacks": [ - "error", - { - max: 10 - } -] -``` - -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny max-nested-callbacks -``` - -```json [Config (.oxlintrc.json)] -{ - "rules": { - "max-nested-callbacks": "error" - } -} -``` - -::: - -## References - -- Rule Source diff --git a/src/docs/guide/usage/linter/rules/eslint/max-params.md b/src/docs/guide/usage/linter/rules/eslint/max-params.md index bda03cad62a..89e8f3591a7 100644 --- a/src/docs/guide/usage/linter/rules/eslint/max-params.md +++ b/src/docs/guide/usage/linter/rules/eslint/max-params.md @@ -1,10 +1,5 @@ - - # eslint/max-params
@@ -12,20 +7,13 @@ const source = `https://github.com/oxc-project/oxc/blob/${ data }/crates/oxc_lin ### What it does -Enforce a maximum number of parameters in function definitions which by -default is three. +Enforce a maximum number of parameters in function definitions ### Why is this bad? -Functions that take numerous parameters can be difficult to read and -write because it requires the memorization of what each parameter is, -its type, and the order they should appear in. As a result, many coders -adhere to a convention that caps the number of parameters a function -can take. - -### Examples +Functions that take numerous parameters can be difficult to read and write because it requires the memorization of what each parameter is, its type, and the order they should appear in. As a result, many coders adhere to a convention that caps the number of parameters a function can take. -Examples of **incorrect** code for this rule: +### Example ```javascript function foo(bar, baz, qux, qxx) { @@ -33,66 +21,6 @@ function foo(bar, baz, qux, qxx) { } ``` -```javascript -let foo = (bar, baz, qux, qxx) => { - doSomething(); -}; -``` - -Examples of **correct** code for this rule: - -```javascript -function foo(bar, baz, qux) { - doSomething(); -} -``` - -```javascript -let foo = (bar, baz, qux) => { - doSomething(); -}; -``` - -### Options - -#### max - -`{ "max": number }` - -This option is for changing the maximum allowed number of function parameters. - -For example `{ "max": 4 }` would mean that having a function take four -parameters is allowed which overrides the default of three. - -#### countVoidThis - -`{ "countVoidThis": boolean }` - -This option is for counting the `this` parameter if it is of type `void`. - -For example `{ "countVoidThis": true }` would mean that having a function -take a `this` parameter of type `void` is counted towards the maximum number of parameters. - -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny max-params -``` - -```json [Config (.oxlintrc.json)] -{ - "rules": { - "max-params": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/eslint/max_params.rs) diff --git a/src/docs/guide/usage/linter/rules/eslint/new-cap.md b/src/docs/guide/usage/linter/rules/eslint/new-cap.md deleted file mode 100644 index abb5f4b2034..00000000000 --- a/src/docs/guide/usage/linter/rules/eslint/new-cap.md +++ /dev/null @@ -1,350 +0,0 @@ - - - - -# eslint/new-cap - -
- -🚧 An auto-fix is still under development. - -
- -### What it does - -This rule requires constructor names to begin with a capital letter. - -### Why is this bad? - -The new operator in JavaScript creates a new instance of a particular type of object. -That type of object is represented by a constructor function. -Since constructor functions are just regular functions, the only defining characteristic -is that new is being used as part of the call. -Native JavaScript functions begin with an uppercase letter to distinguish those functions -that are to be used as constructors from functions that are not. -Many style guides recommend following this pattern -to more easily determine which functions are to be used as constructors. - -**Warning**: -The option `newIsCapExceptionPattern` and `capIsNewExceptionPattern` are implemented with -the [rust regex syntax](https://docs.rs/regex/latest/regex/). Many JavaScript features -are not supported (Lookahead, Lookbehinds, ...). - -### Examples - -Examples of **incorrect** code for this rule: - -```js -function foo(arg) { - return Boolean(arg); -} -``` - -Examples of **incorrect** code for this rule with the default `{ "newIsCap": true }` option: - -```js -/*eslint new-cap: ["error", { "newIsCap": true }]*/ - -var friend = new person(); -``` - -Examples of **correct** code for this rule with the default `{ "newIsCap": true }` option: - -```js -/*eslint new-cap: ["error", { "newIsCap": true }]*/ - -var friend = new Person(); -``` - -Examples of **correct** code for this rule with the `{ "newIsCap": false }` option: - -```js -/*eslint new-cap: ["error", { "newIsCap": false }]*/ - -var friend = new person(); -``` - -Examples of **incorrect** code for this rule with the default `{ "capIsNew": true }` option: - -```js -/*eslint new-cap: ["error", { "capIsNew": true }]*/ - -var colleague = Person(); -``` - -Examples of **correct** code for this rule with the default `{ "capIsNew": true }` option: - -```js -/*eslint new-cap: ["error", { "capIsNew": true }]*/ - -var colleague = new Person(); -``` - -Examples of **correct** code for this rule with the `{ "capIsNew": false }` option: - -```js -/*eslint new-cap: ["error", { "capIsNew": false }]*/ - -var colleague = Person(); -``` - -Examples of additional **correct** code for this rule with the `{ "newIsCapExceptions": ["events"] }` option: - -```js -/*eslint new-cap: ["error", { "newIsCapExceptions": ["events"] }]*/ - -var events = require("events"); - -var emitter = new events(); -``` - -Examples of additional **correct** code for this rule with the `{ "newIsCapExceptionPattern": "^person\\.." }` option: - -```js -/*eslint new-cap: ["error", { "newIsCapExceptionPattern": "^person\\.." }]*/ - -var friend = new person.acquaintance(); - -var bestFriend = new person.friend(); -``` - -Examples of additional **correct** code for this rule with the `{ "newIsCapExceptionPattern": "\\.bar$" }` option: - -```js -/*eslint new-cap: ["error", { "newIsCapExceptionPattern": "\\.bar$" }]*/ - -var friend = new person.bar(); -``` - -Examples of additional **correct** code for this rule with the `{ "capIsNewExceptions": ["Person"] }` option: - -```js -/*eslint new-cap: ["error", { "capIsNewExceptions": ["Person"] }]*/ - -function foo(arg) { - return Person(arg); -} -``` - -Examples of additional **correct** code for this rule with the `{ "capIsNewExceptionPattern": "^person\\.." }` option: - -```js -/*eslint new-cap: ["error", { "capIsNewExceptionPattern": "^person\\.." }]*/ - -var friend = person.Acquaintance(); -var bestFriend = person.Friend(); -``` - -Examples of additional **correct** code for this rule with the `{ "capIsNewExceptionPattern": "\\.Bar$" }` option: - -```js -/*eslint new-cap: ["error", { "capIsNewExceptionPattern": "\\.Bar$" }]*/ - -foo.Bar(); -``` - -Examples of additional **correct** code for this rule with the `{ "capIsNewExceptionPattern": "^Foo" }` option: - -```js -/*eslint new-cap: ["error", { "capIsNewExceptionPattern": "^Foo" }]*/ - -var x = Foo(42); - -var y = Foobar(42); - -var z = Foo.Bar(42); -``` - -### properties - -Examples of **incorrect** code for this rule with the default `{ "properties": true }` option: - -```js -/*eslint new-cap: ["error", { "properties": true }]*/ - -var friend = new person.acquaintance(); -``` - -Examples of **correct** code for this rule with the default `{ "properties": true }` option: - -```js -/*eslint new-cap: ["error", { "properties": true }]*/ - -var friend = new person.Acquaintance(); -``` - -Examples of **correct** code for this rule with the `{ "properties": false }` option: - -```js -/*eslint new-cap: ["error", { "properties": false }]*/ - -var friend = new person.acquaintance(); -``` - -Examples of **incorrect** code for this rule with the default `{ "newIsCap": true }` option: - -```js -/*eslint new-cap: ["error", { "newIsCap": true }]*/ - -var friend = new person(); -``` - -Examples of **correct** code for this rule with the default `{ "newIsCap": true }` option: - -```js -/*eslint new-cap: ["error", { "newIsCap": true }]*/ - -var friend = new Person(); -``` - -Examples of **correct** code for this rule with the `{ "newIsCap": false }` option: - -```js -/*eslint new-cap: ["error", { "newIsCap": false }]*/ - -var friend = new person(); -``` - -Examples of **incorrect** code for this rule with the default `{ "capIsNew": true }` option: - -```js -/*eslint new-cap: ["error", { "capIsNew": true }]*/ - -var colleague = Person(); -``` - -Examples of **correct** code for this rule with the default `{ "capIsNew": true }` option: - -```js -/*eslint new-cap: ["error", { "capIsNew": true }]*/ - -var colleague = new Person(); -``` - -Examples of **correct** code for this rule with the `{ "capIsNew": false }` option: - -```js -/*eslint new-cap: ["error", { "capIsNew": false }]*/ - -var colleague = Person(); -``` - -Examples of additional **correct** code for this rule with the `{ "newIsCapExceptions": ["events"] }` option: - -```js -/*eslint new-cap: ["error", { "newIsCapExceptions": ["events"] }]*/ - -var events = require("events"); - -var emitter = new events(); -``` - -Examples of additional **correct** code for this rule with the `{ "newIsCapExceptionPattern": "^person\\.." }` option: - -```js -/*eslint new-cap: ["error", { "newIsCapExceptionPattern": "^person\\.." }]*/ - -var friend = new person.acquaintance(); - -var bestFriend = new person.friend(); -``` - -Examples of additional **correct** code for this rule with the `{ "newIsCapExceptionPattern": "\\.bar$" }` option: - -```js -/*eslint new-cap: ["error", { "newIsCapExceptionPattern": "\\.bar$" }]*/ - -var friend = new person.bar(); -``` - -Examples of additional **correct** code for this rule with the `{ "capIsNewExceptions": ["Person"] }` option: - -::: correct - -```js -/*eslint new-cap: ["error", { "capIsNewExceptions": ["Person"] }]*/ - -function foo(arg) { - return Person(arg); -} -``` - -Examples of additional **correct** code for this rule with the `{ "capIsNewExceptionPattern": "^person\\.." }` option: - -```js -/*eslint new-cap: ["error", { "capIsNewExceptionPattern": "^person\\.." }]*/ - -var friend = person.Acquaintance(); -var bestFriend = person.Friend(); -``` - -Examples of additional **correct** code for this rule with the `{ "capIsNewExceptionPattern": "\\.Bar$" }` option: - -```js -/*eslint new-cap: ["error", { "capIsNewExceptionPattern": "\\.Bar$" }]*/ - -foo.Bar(); -``` - -Examples of additional **correct** code for this rule with the `{ "capIsNewExceptionPattern": "^Foo" }` option: - -```js -/*eslint new-cap: ["error", { "capIsNewExceptionPattern": "^Foo" }]*/ - -var x = Foo(42); - -var y = Foobar(42); - -var z = Foo.Bar(42); -``` - -Examples of **incorrect** code for this rule with the default `{ "properties": true }` option: - -```js -/*eslint new-cap: ["error", { "properties": true }]*/ - -var friend = new person.acquaintance(); -``` - -Examples of **correct** code for this rule with the default `{ "properties": true }` option: - -```js -/*eslint new-cap: ["error", { "properties": true }]*/ - -var friend = new person.Acquaintance(); -``` - -Examples of **correct** code for this rule with the `{ "properties": false }` option: - -```js -/*eslint new-cap: ["error", { "properties": false }]*/ - -var friend = new person.acquaintance(); -``` - -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny new-cap -``` - -```json [Config (.oxlintrc.json)] -{ - "rules": { - "new-cap": "error" - } -} -``` - -::: - -## References - -- Rule Source diff --git a/src/docs/guide/usage/linter/rules/eslint/no-alert.md b/src/docs/guide/usage/linter/rules/eslint/no-alert.md index 83ce940c6b3..9f0d23ca6d4 100644 --- a/src/docs/guide/usage/linter/rules/eslint/no-alert.md +++ b/src/docs/guide/usage/linter/rules/eslint/no-alert.md @@ -1,10 +1,5 @@ - - # eslint/no-alert
@@ -46,26 +41,6 @@ function foo() { } ``` -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny no-alert -``` - -```json [Config (.oxlintrc.json)] -{ - "rules": { - "no-alert": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/eslint/no_alert.rs) diff --git a/src/docs/guide/usage/linter/rules/eslint/no-array-constructor.md b/src/docs/guide/usage/linter/rules/eslint/no-array-constructor.md index c4368a5ce3e..2f17afa40f9 100644 --- a/src/docs/guide/usage/linter/rules/eslint/no-array-constructor.md +++ b/src/docs/guide/usage/linter/rules/eslint/no-array-constructor.md @@ -1,15 +1,10 @@ - - # eslint/no-array-constructor
-πŸ› οΈ An auto-fix is available for this rule. +🚧 An auto-fix is still under development.
@@ -42,26 +37,6 @@ let arr2 = Array.from(iterable); let arr3 = new Array(9); ``` -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny no-array-constructor -``` - -```json [Config (.oxlintrc.json)] -{ - "rules": { - "no-array-constructor": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/eslint/no_array_constructor.rs) diff --git a/src/docs/guide/usage/linter/rules/eslint/no-async-promise-executor.md b/src/docs/guide/usage/linter/rules/eslint/no-async-promise-executor.md index 2b4114e8d29..17598364257 100644 --- a/src/docs/guide/usage/linter/rules/eslint/no-async-promise-executor.md +++ b/src/docs/guide/usage/linter/rules/eslint/no-async-promise-executor.md @@ -1,10 +1,5 @@ - - # eslint/no-async-promise-executor
@@ -15,17 +10,19 @@ const source = `https://github.com/oxc-project/oxc/blob/${ data }/crates/oxc_lin ### What it does -Disallow using an async function as a Promise executor. +Disallow using an async function as a Promise executor ### Why is this bad? The `new Promise` constructor accepts an executor function as an argument, -which has `resolve` and `reject` parameters that can be used to control the state of the -created Promise. For example: +which has `resolve` and `reject` parameters that can be used to control the state of the created Promise. +For example: + +### Example ```javascript const result = new Promise(function executor(resolve, reject) { - readFile("foo.txt", function(err, result) { + readFile("foo.txt", function (err, result) { if (err) { reject(err); } else { @@ -37,68 +34,9 @@ const result = new Promise(function executor(resolve, reject) { The executor function can also be an `async function`. However, this is usually a mistake, for a few reasons: -- If an async executor function throws an error, the error will be lost and won’t cause - the newly-constructed `Promise` to reject.This could make it difficult to debug and handle some errors. -- If a `Promise` executor function is using `await`, this is usually a sign that it is not - actually necessary to use the new `Promise` constructor, or the scope of the new - `Promise` constructor can be reduced. - -### Examples - -Examples of **incorrect** code for this rule: - -```javascript -const foo = new Promise(async (resolve, reject) => { - readFile("foo.txt", function(err, result) { - if (err) { - reject(err); - } else { - resolve(result); - } - }); -}); - -const result = new Promise(async (resolve, reject) => { - resolve(await foo); -}); -``` - -Examples of **correct** code for this rule: - -```javascript -const foo = new Promise((resolve, reject) => { - readFile("foo.txt", function(err, result) { - if (err) { - reject(err); - } else { - resolve(result); - } - }); -}); - -const result = Promise.resolve(foo); -``` - -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny no-async-promise-executor -``` - -```json [Config (.oxlintrc.json)] -{ - "rules": { - "no-async-promise-executor": "error" - } -} -``` - -::: +- If an async executor function throws an error, the error will be lost and won’t cause the newly-constructed `Promise` to reject.This could make it difficult to debug and handle some errors. +- If a Promise executor function is using `await`, this is usually a sign that it is not actually necessary to use the `new Promise` constructor, or the scope of the `new Promise` constructor can be reduced. ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/eslint/no_async_promise_executor.rs) diff --git a/src/docs/guide/usage/linter/rules/eslint/no-await-in-loop.md b/src/docs/guide/usage/linter/rules/eslint/no-await-in-loop.md index 355fdcd9f26..abec3920eab 100644 --- a/src/docs/guide/usage/linter/rules/eslint/no-await-in-loop.md +++ b/src/docs/guide/usage/linter/rules/eslint/no-await-in-loop.md @@ -1,10 +1,5 @@ - - # eslint/no-await-in-loop
@@ -19,7 +14,7 @@ This rule disallows the use of `await` within loop bodies. (for, for-in, for-of, It potentially indicates that the async operations are not being effectively parallelized. Instead, they are being run in series, which can lead to poorer performance. -### Examples +### Example Examples of **incorrect** code for this rule: @@ -35,30 +30,10 @@ Examples of **correct** code for this rule: ```javascript async function good() { - await Promise.all(users.map(user => getUserRecord(user))); + await Promise.all(users.map((user) => getUserRecord(user))); } ``` -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny no-await-in-loop -``` - -```json [Config (.oxlintrc.json)] -{ - "rules": { - "no-await-in-loop": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/eslint/no_await_in_loop.rs) diff --git a/src/docs/guide/usage/linter/rules/eslint/no-bitwise.md b/src/docs/guide/usage/linter/rules/eslint/no-bitwise.md index 2c95f6ea953..e2d591c6b26 100644 --- a/src/docs/guide/usage/linter/rules/eslint/no-bitwise.md +++ b/src/docs/guide/usage/linter/rules/eslint/no-bitwise.md @@ -1,10 +1,5 @@ - - # eslint/no-bitwise
@@ -19,85 +14,12 @@ Disallow bitwise operators The use of bitwise operators in JavaScript is very rare and often `&` or `|` is simply a mistyped `&&` or `||`, which will lead to unexpected behavior. -### Examples - -Examples of **incorrect** code for this rule: +### Example ```javascript var x = y | z; ``` -```javascript -var x = y ^ z; -``` - -```javascript -var x = y >> z; -``` - -Examples of **correct** code for this rule: - -```javascript -var x = y || z; -``` - -```javascript -var x = y && z; -``` - -```javascript -var x = y > z; -``` - -### Options - -#### allow - -`{ type: string[], default: [] }` - -The `allow` option permits the given list of bitwise operators to be used -as exceptions to this rule. - -For example `{ "allow": ["~"] }` would allow the use of the bitwise operator -`~` without restriction. Such as in the following: - -```javascript -~[1, 2, 3].indexOf(1) === -1; -``` - -#### int32Hint - -`{ type: boolean, default: false }` - -When set to true the `int32Hint` option allows the use of bitwise OR in |0 -pattern for type casting. - -For example with `{ "int32Hint": true }` the following is permitted: - -```javascript -const b = a | 0; -``` - -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny no-bitwise -``` - -```json [Config (.oxlintrc.json)] -{ - "rules": { - "no-bitwise": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/eslint/no_bitwise.rs) diff --git a/src/docs/guide/usage/linter/rules/eslint/no-caller.md b/src/docs/guide/usage/linter/rules/eslint/no-caller.md index ac1cbf4ee02..3f0d3bc42d1 100644 --- a/src/docs/guide/usage/linter/rules/eslint/no-caller.md +++ b/src/docs/guide/usage/linter/rules/eslint/no-caller.md @@ -1,10 +1,5 @@ - - # eslint/no-caller
@@ -34,7 +29,7 @@ This rule is aimed at discouraging the use of deprecated and sub-optimal code by disallowing the use of `arguments.caller` and `arguments.callee`. As such, it will warn when `arguments.caller` and `arguments.callee` are used. -### Examples +### Example Examples of **incorrect** code for this rule: @@ -47,7 +42,7 @@ function foo(n) { arguments.callee(n - 1); } -[1, 2, 3, 4, 5].map(function(n) { +[1, 2, 3, 4, 5].map(function (n) { return !(n > 1) ? 1 : arguments.callee(n - 1) * n; }); ``` @@ -68,26 +63,6 @@ function foo(n) { }); ``` -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny no-caller -``` - -```json [Config (.oxlintrc.json)] -{ - "rules": { - "no-caller": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/eslint/no_caller.rs) diff --git a/src/docs/guide/usage/linter/rules/eslint/no-case-declarations.md b/src/docs/guide/usage/linter/rules/eslint/no-case-declarations.md index 7bf3ce07426..5802d30933d 100644 --- a/src/docs/guide/usage/linter/rules/eslint/no-case-declarations.md +++ b/src/docs/guide/usage/linter/rules/eslint/no-case-declarations.md @@ -1,10 +1,5 @@ - - # eslint/no-case-declarations
@@ -20,9 +15,7 @@ The reason is that the lexical declaration is visible in the entire switch block but it only gets initialized when it is assigned, which will only happen if the case where it is defined is reached. -### Examples - -Examples of **incorrect** code for this rule: +### Example ```javascript switch (foo) { @@ -40,48 +33,6 @@ switch (foo) { } ``` -Examples of **correct** code for this rule: - -```javascript -switch (foo) { - case 1: { - let x = 1; - break; - } - case 2: { - const y = 2; - break; - } - case 3: { - function f() {} - break; - } - default: { - class C {} - } -} -``` - -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny no-case-declarations -``` - -```json [Config (.oxlintrc.json)] -{ - "rules": { - "no-case-declarations": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/eslint/no_case_declarations.rs) diff --git a/src/docs/guide/usage/linter/rules/eslint/no-class-assign.md b/src/docs/guide/usage/linter/rules/eslint/no-class-assign.md index 4b4c73e732d..44422e126b4 100644 --- a/src/docs/guide/usage/linter/rules/eslint/no-class-assign.md +++ b/src/docs/guide/usage/linter/rules/eslint/no-class-assign.md @@ -1,10 +1,5 @@ - - # eslint/no-class-assign
@@ -19,83 +14,17 @@ Disallow reassigning class variables. ### Why is this bad? -`ClassDeclaration` creates a variable that can be re-assigned, but the re-assignment is a -mistake in most cases. - -### Examples +`ClassDeclaration` creates a variable that can be re-assigned, +but the re-assignment is a mistake in most cases. -Examples of **incorrect** code for this rule: - -```javascript -class A {} -A = 0; -``` +### Example ```javascript -A = 0; class A {} +A = 123; +let a = new A(); // Error ``` -```javascript -class A { - b() { - A = 0; - } -} -``` - -```javascript -let A = class A { - b() { - A = 0; - // `let A` is shadowed by the class name. - } -}; -``` - -Examples of **correct** code for this rule: - -```javascript -let A = class A {}; -A = 0; // A is a variable. -``` - -```javascript -let A = class { - b() { - A = 0; // A is a variable. - } -}; -``` - -```javascript -class A { - b(A) { - A = 0; // A is a parameter. - } -} -``` - -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny no-class-assign -``` - -```json [Config (.oxlintrc.json)] -{ - "rules": { - "no-class-assign": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/eslint/no_class_assign.rs) diff --git a/src/docs/guide/usage/linter/rules/eslint/no-compare-neg-zero.md b/src/docs/guide/usage/linter/rules/eslint/no-compare-neg-zero.md index a351829e5a1..41b34839bb8 100644 --- a/src/docs/guide/usage/linter/rules/eslint/no-compare-neg-zero.md +++ b/src/docs/guide/usage/linter/rules/eslint/no-compare-neg-zero.md @@ -1,10 +1,5 @@ - - # eslint/no-compare-neg-zero
@@ -26,62 +21,13 @@ The rule should warn against code that tries to compare against -0, since that will not work as intended. That is, code like x === -0 will pass for both +0 and -0. The author probably intended Object.is(x, -0). -### Examples - -Examples of **incorrect** code for this rule: +### Example ```javascript if (x === -0) { - // doSomething()... -} -``` - -```javascript -if (-0 > x) { - // doSomething()... -} -``` - -Examples of **correct** code for this rule: - -```javascript -if (x === 0) { - // doSomething()... -} -``` - -```javascript -if (Object.is(x, -0)) { - // doSomething()... -} -``` - -```javascript -if (0 > x) { - // doSomething()... -} -``` - -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny no-compare-neg-zero -``` - -```json [Config (.oxlintrc.json)] -{ - "rules": { - "no-compare-neg-zero": "error" - } } ``` -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/eslint/no_compare_neg_zero.rs) diff --git a/src/docs/guide/usage/linter/rules/eslint/no-cond-assign.md b/src/docs/guide/usage/linter/rules/eslint/no-cond-assign.md index 276eacac4e3..957a4cd4062 100644 --- a/src/docs/guide/usage/linter/rules/eslint/no-cond-assign.md +++ b/src/docs/guide/usage/linter/rules/eslint/no-cond-assign.md @@ -1,10 +1,5 @@ - - # eslint/no-cond-assign
@@ -26,46 +21,15 @@ There are valid reasons to use assignment operators in conditional statements. However, it can be difficult to tell whether a specific assignment was intentional. -### Examples - -Examples of **incorrect** code for this rule: +### Example ```js // Check the user's job title -if (user.jobTitle = "manager") { +if ((user.jobTitle = "manager")) { // user.jobTitle is now incorrect } ``` -Examples of **correct** code for this rule: - -```js -// Check the user's job title -if (user.jobTitle === "manager") { - // correctly compared `jobTitle` -} -``` - -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny no-cond-assign -``` - -```json [Config (.oxlintrc.json)] -{ - "rules": { - "no-cond-assign": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/eslint/no_cond_assign.rs) diff --git a/src/docs/guide/usage/linter/rules/eslint/no-console.md b/src/docs/guide/usage/linter/rules/eslint/no-console.md index 86095351e5c..c4160e1270f 100644 --- a/src/docs/guide/usage/linter/rules/eslint/no-console.md +++ b/src/docs/guide/usage/linter/rules/eslint/no-console.md @@ -1,91 +1,30 @@ - - # eslint/no-console
-πŸ’‘ A suggestion is available for this rule for some violations. +πŸ’‘ A suggestion is available for this rule.
### What it does -Disallow the use of console. +Disallows using the global console object. ### Why is this bad? -In JavaScript that is designed to be executed in the browser, it’s considered a best -practice to avoid using methods on console. Such messages are considered to be for -debugging purposes and therefore not suitable to ship to the client. In general, calls -using console should be stripped before being pushed to production. - -### Examples +In JavaScript that is designed to be executed in the browser, +it’s considered a best practice to avoid using methods on console. +Such messages are considered to be for debugging purposes and therefore +not suitable to ship to the client. -Examples of **incorrect** code for this rule: +### Example ```javascript -console.log("Log a debug level message."); -console.warn("Log a warn level message."); -console.error("Log an error level message."); -console.log = foo(); +console.log("here"); ``` -Examples of **correct** code for this rule: - -```javascript -// custom console -Console.log("Hello world!"); -``` - -### Options - -#### allow - -`{ type: string[], default: [] }` - -The `allow` option permits the given list of console methods to be used as exceptions to -this rule. - -Say the option was configured as `{ "allow": ["info"] }` then the rule would behave as -follows: - -Example of **incorrect** code for this option: - -```javascript -console.log("foo"); -``` - -Example of **correct** code for this option: - -```javascript -console.info("foo"); -``` - -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny no-console -``` - -```json [Config (.oxlintrc.json)] -{ - "rules": { - "no-console": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/eslint/no_console.rs) diff --git a/src/docs/guide/usage/linter/rules/eslint/no-const-assign.md b/src/docs/guide/usage/linter/rules/eslint/no-const-assign.md index 2af295137ef..043c3d499aa 100644 --- a/src/docs/guide/usage/linter/rules/eslint/no-const-assign.md +++ b/src/docs/guide/usage/linter/rules/eslint/no-const-assign.md @@ -1,10 +1,5 @@ - - # eslint/no-const-assign
@@ -22,7 +17,7 @@ Disallow reassigning `const` variables. We cannot modify variables that are declared using const keyword. It will raise a runtime error. -### Examples +### Example Examples of **incorrect** code for this rule: @@ -44,26 +39,6 @@ var b = 0; b += 1; ``` -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny no-const-assign -``` - -```json [Config (.oxlintrc.json)] -{ - "rules": { - "no-const-assign": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/eslint/no_const_assign.rs) diff --git a/src/docs/guide/usage/linter/rules/eslint/no-constant-binary-expression.md b/src/docs/guide/usage/linter/rules/eslint/no-constant-binary-expression.md index 3c6b373a416..38026c59c09 100644 --- a/src/docs/guide/usage/linter/rules/eslint/no-constant-binary-expression.md +++ b/src/docs/guide/usage/linter/rules/eslint/no-constant-binary-expression.md @@ -1,10 +1,5 @@ - - # eslint/no-constant-binary-expression
@@ -28,9 +23,7 @@ Additionally, this rule detects comparisons to newly constructed objects/arrays/ In JavaScript, where objects are compared by reference, a newly constructed object can never `===` any other value. This can be surprising for programmers coming from languages where objects are compared by value. -### Examples - -Examples of **incorrect** code for this rule: +### Example ```javascript // One might think this would evaluate as `a + (b ?? c)`: @@ -45,34 +38,6 @@ const isEmpty = x === []; // However, this will always result in `isEmpty` being `false`. ``` -Examples of **correct** code for this rule: - -```javascript -const x = a + (b ?? c); - -const isEmpty = x.length === 0; -``` - -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny no-constant-binary-expression -``` - -```json [Config (.oxlintrc.json)] -{ - "rules": { - "no-constant-binary-expression": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/eslint/no_constant_binary_expression.rs) diff --git a/src/docs/guide/usage/linter/rules/eslint/no-constant-condition.md b/src/docs/guide/usage/linter/rules/eslint/no-constant-condition.md index 2a65bc0bfe8..a18257ee650 100644 --- a/src/docs/guide/usage/linter/rules/eslint/no-constant-condition.md +++ b/src/docs/guide/usage/linter/rules/eslint/no-constant-condition.md @@ -1,10 +1,5 @@ - - # eslint/no-constant-condition
@@ -27,7 +22,7 @@ This rule disallows constant expressions in the test condition of: - `if`, `for`, `while`, or `do...while` statement - `?`: ternary expression -### Examples +### Example Examples of **incorrect** code for this rule: @@ -39,13 +34,13 @@ if (false) { if (new Boolean(x)) { doSomethingAlways(); } -if (x ||= true) { +if ((x ||= true)) { doSomethingAlways(); } do { doSomethingForever(); -} while (x = -1); +} while ((x = -1)); ``` Examples of **correct** code for this rule: @@ -60,36 +55,6 @@ while (typeof x === "undefined") { } ``` -### Options - -#### checkLoops - -`{ type: "all" | "allExceptWhileTrue" | "none" | boolean, default: "allExceptWhileTrue" }` - -- `"all"` or `true` disallows constant expressions in loops -- `"allExceptWhileTrue"` disallows constant expressions in loops except while loops with expression `true` -- `"none"` or `false` allows constant expressions in loops - -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny no-constant-condition -``` - -```json [Config (.oxlintrc.json)] -{ - "rules": { - "no-constant-condition": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/eslint/no_constant_condition.rs) diff --git a/src/docs/guide/usage/linter/rules/eslint/no-constructor-return.md b/src/docs/guide/usage/linter/rules/eslint/no-constructor-return.md index 0ef499f34ac..bac181dfdd0 100644 --- a/src/docs/guide/usage/linter/rules/eslint/no-constructor-return.md +++ b/src/docs/guide/usage/linter/rules/eslint/no-constructor-return.md @@ -1,10 +1,5 @@ - - # eslint/no-constructor-return
@@ -19,48 +14,24 @@ Disallow returning value from constructor In JavaScript, returning a value in the constructor of a class may be a mistake. Forbidding this pattern prevents mistakes resulting from unfamiliarity with the language or a copy-paste error. -### Examples +### Example Examples of **incorrect** code for this rule: -```js +```rust class C { - constructor() { - return 42; - } + constructor() { return 42; } } ``` Examples of **correct** code for this rule: -```js +```rust class C { - constructor() { - this.value = 42; - } -} -``` - -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny no-constructor-return -``` - -```json [Config (.oxlintrc.json)] -{ - "rules": { - "no-constructor-return": "error" - } + constructor() { this.value = 42; } } ``` -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/eslint/no_constructor_return.rs) diff --git a/src/docs/guide/usage/linter/rules/eslint/no-continue.md b/src/docs/guide/usage/linter/rules/eslint/no-continue.md index 605fd80de9b..707a1c52f9c 100644 --- a/src/docs/guide/usage/linter/rules/eslint/no-continue.md +++ b/src/docs/guide/usage/linter/rules/eslint/no-continue.md @@ -1,10 +1,5 @@ - - # eslint/no-continue
@@ -18,9 +13,7 @@ Disallow `continue` statements The continue statement terminates execution of the statements in the current iteration of the current or labeled loop, and continues execution of the loop with the next iteration. When used incorrectly it makes code less testable, less readable and less maintainable. Structured control flow statements such as if should be used instead. -### Examples - -Examples of **incorrect** code for this rule: +### Example ```javascript var sum = 0, @@ -35,37 +28,6 @@ for (i = 0; i < 10; i++) { } ``` -Examples of **correct** code for this rule: - -```javascript -var sum = 0, i; -for (i = 0; i < 10; i++) { - if (i < 5) { - sum += i; - } -} -``` - -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny no-continue -``` - -```json [Config (.oxlintrc.json)] -{ - "rules": { - "no-continue": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/eslint/no_continue.rs) diff --git a/src/docs/guide/usage/linter/rules/eslint/no-control-regex.md b/src/docs/guide/usage/linter/rules/eslint/no-control-regex.md index 75dc9a90e20..77dfc5985b8 100644 --- a/src/docs/guide/usage/linter/rules/eslint/no-control-regex.md +++ b/src/docs/guide/usage/linter/rules/eslint/no-control-regex.md @@ -1,10 +1,5 @@ - - # eslint/no-control-regex
@@ -25,7 +20,7 @@ Control characters are special, invisible characters in the ASCII range regular expression containing elements that explicitly match these characters is most likely a mistake. -### Examples +### Example Examples of **incorrect** code for this rule: @@ -52,26 +47,6 @@ var pattern7 = new RegExp("\\t"); var pattern8 = new RegExp("\\n"); ``` -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny no-control-regex -``` - -```json [Config (.oxlintrc.json)] -{ - "rules": { - "no-control-regex": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/eslint/no_control_regex.rs) diff --git a/src/docs/guide/usage/linter/rules/eslint/no-debugger.md b/src/docs/guide/usage/linter/rules/eslint/no-debugger.md index 0c11319c504..50e792283a5 100644 --- a/src/docs/guide/usage/linter/rules/eslint/no-debugger.md +++ b/src/docs/guide/usage/linter/rules/eslint/no-debugger.md @@ -1,10 +1,5 @@ - - # eslint/no-debugger
@@ -25,9 +20,7 @@ Checks for usage of the `debugger` statement `debugger` statements do not affect functionality when a debugger isn't attached. They're most commonly an accidental debugging leftover. -### Examples - -Examples of **incorrect** code for this rule: +### Example ```javascript async function main() { @@ -37,35 +30,6 @@ async function main() { } ``` -Examples of **correct** code for this rule: - -```javascript -async function main() { - const data = await getData(); - const result = complexCalculation(data); -} -``` - -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny no-debugger -``` - -```json [Config (.oxlintrc.json)] -{ - "rules": { - "no-debugger": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/eslint/no_debugger.rs) diff --git a/src/docs/guide/usage/linter/rules/eslint/no-delete-var.md b/src/docs/guide/usage/linter/rules/eslint/no-delete-var.md index bb1ebbdd86a..e277e733320 100644 --- a/src/docs/guide/usage/linter/rules/eslint/no-delete-var.md +++ b/src/docs/guide/usage/linter/rules/eslint/no-delete-var.md @@ -1,10 +1,5 @@ - - # eslint/no-delete-var
@@ -23,7 +18,7 @@ object. Using the `delete` operator on a variable might lead to unexpected behavior. -### Examples +### Example Examples of **incorrect** code for this rule: @@ -32,35 +27,6 @@ var x; delete x; ``` -Examples of **correct** code for this rule: - -```javascript -var x; - -var y; -delete y.prop; -``` - -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny no-delete-var -``` - -```json [Config (.oxlintrc.json)] -{ - "rules": { - "no-delete-var": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/eslint/no_delete_var.rs) diff --git a/src/docs/guide/usage/linter/rules/eslint/no-div-regex.md b/src/docs/guide/usage/linter/rules/eslint/no-div-regex.md index f3a7bdae03d..e90e85bcf03 100644 --- a/src/docs/guide/usage/linter/rules/eslint/no-div-regex.md +++ b/src/docs/guide/usage/linter/rules/eslint/no-div-regex.md @@ -1,10 +1,5 @@ - - # eslint/no-div-regex
@@ -22,9 +17,7 @@ Disallow equal signs explicitly at the beginning of regular expressions. Characters /= at the beginning of a regular expression literal can be confused with a division assignment operator. -### Examples - -Examples of **incorrect** code for this rule: +### Example ```javascript function bar() { @@ -32,34 +25,6 @@ function bar() { } ``` -Examples of **correct** code for this rule: - -```javascript -function bar() { - return /[=]foo/; -} -``` - -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny no-div-regex -``` - -```json [Config (.oxlintrc.json)] -{ - "rules": { - "no-div-regex": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/eslint/no_div_regex.rs) diff --git a/src/docs/guide/usage/linter/rules/eslint/no-dupe-class-members.md b/src/docs/guide/usage/linter/rules/eslint/no-dupe-class-members.md index 705f2318b4e..727093458dc 100644 --- a/src/docs/guide/usage/linter/rules/eslint/no-dupe-class-members.md +++ b/src/docs/guide/usage/linter/rules/eslint/no-dupe-class-members.md @@ -1,10 +1,5 @@ - - # eslint/no-dupe-class-members
@@ -22,9 +17,7 @@ Disallow duplicate class members If there are declarations of the same name in class members, the last declaration overwrites other declarations silently. It can cause unexpected behaviors. -### Examples - -Examples of **incorrect** code for this rule: +### Example ```javascript class A { @@ -37,38 +30,6 @@ let a = new A(); a.foo(); // Uncaught TypeError: a.foo is not a function ``` -Examples of **correct** code for this rule: - -```javascript -class A { - foo() { - console.log("foo"); - } -} -let a = new A(); -a.foo(); -``` - -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny no-dupe-class-members -``` - -```json [Config (.oxlintrc.json)] -{ - "rules": { - "no-dupe-class-members": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/eslint/no_dupe_class_members.rs) diff --git a/src/docs/guide/usage/linter/rules/eslint/no-dupe-else-if.md b/src/docs/guide/usage/linter/rules/eslint/no-dupe-else-if.md index 8a2c210d520..a4698cb7477 100644 --- a/src/docs/guide/usage/linter/rules/eslint/no-dupe-else-if.md +++ b/src/docs/guide/usage/linter/rules/eslint/no-dupe-else-if.md @@ -1,10 +1,5 @@ - - # eslint/no-dupe-else-if
@@ -23,9 +18,7 @@ if-else-if chains are commonly used when there is a need to execute only one bra Two identical test conditions in the same chain are almost always a mistake in the code. Unless there are side effects in the expressions, a duplicate will evaluate to the same true or false value as the identical expression earlier in the chain, meaning that its branch can never execute. -### Examples - -Examples of **incorrect** code for this rule: +### Example ```javascript if (a) { @@ -37,82 +30,6 @@ if (a) { } ``` -```javascript -if (a || b) { - foo(); -} else if (a) { - bar(); -} -``` - -```javascript -if (n === 1) { - foo(); -} else if (n === 2) { - bar(); -} else if (n === 3) { - baz(); -} else if (n === 2) { - quux(); -} else if (n === 5) { - quuux(); -} -``` - -Examples of **correct** code for this rule: - -```javascript -if (a) { - foo(); -} else if (b) { - bar(); -} else if (c) { - baz(); -} -``` - -```javascript -if (a || b) { - foo(); -} else if (c) { - bar(); -} -``` - -```javascript -if (n === 1) { - foo(); -} else if (n === 2) { - bar(); -} else if (n === 3) { - baz(); -} else if (n === 4) { - quux(); -} else if (n === 5) { - quuux(); -} -``` - -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny no-dupe-else-if -``` - -```json [Config (.oxlintrc.json)] -{ - "rules": { - "no-dupe-else-if": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/eslint/no_dupe_else_if.rs) diff --git a/src/docs/guide/usage/linter/rules/eslint/no-dupe-keys.md b/src/docs/guide/usage/linter/rules/eslint/no-dupe-keys.md index 7d145d0e5a3..df12bd01e4d 100644 --- a/src/docs/guide/usage/linter/rules/eslint/no-dupe-keys.md +++ b/src/docs/guide/usage/linter/rules/eslint/no-dupe-keys.md @@ -1,10 +1,5 @@ - - # eslint/no-dupe-keys
@@ -25,7 +20,7 @@ unexpected behavior in your application. It is safe to disable this rule when using TypeScript because TypeScript's compiler enforces this check. -### Examples +### Example Examples of **incorrect** code for this rule: @@ -36,7 +31,7 @@ var foo = { }; var foo = { - "bar": "baz", + bar: "baz", bar: "qux", }; @@ -55,26 +50,6 @@ var foo = { }; ``` -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny no-dupe-keys -``` - -```json [Config (.oxlintrc.json)] -{ - "rules": { - "no-dupe-keys": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/eslint/no_dupe_keys.rs) diff --git a/src/docs/guide/usage/linter/rules/eslint/no-duplicate-case.md b/src/docs/guide/usage/linter/rules/eslint/no-duplicate-case.md index 1ede413a928..b854c30628d 100644 --- a/src/docs/guide/usage/linter/rules/eslint/no-duplicate-case.md +++ b/src/docs/guide/usage/linter/rules/eslint/no-duplicate-case.md @@ -1,10 +1,5 @@ - - # eslint/no-duplicate-case
@@ -22,12 +17,13 @@ Disallow duplicate case labels If a switch statement has duplicate test expressions in case clauses, it is likely that a programmer copied a case clause but forgot to change the test expression. -### Examples +### Example Examples of **incorrect** code for this rule: ```js -var a = 1, one = 1; +var a = 1, + one = 1; switch (a) { case 1: break; @@ -75,26 +71,6 @@ switch (a) { } ``` -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny no-duplicate-case -``` - -```json [Config (.oxlintrc.json)] -{ - "rules": { - "no-duplicate-case": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/eslint/no_duplicate_case.rs) diff --git a/src/docs/guide/usage/linter/rules/eslint/no-duplicate-imports.md b/src/docs/guide/usage/linter/rules/eslint/no-duplicate-imports.md index 61651b8a6e1..d78ce15be0f 100644 --- a/src/docs/guide/usage/linter/rules/eslint/no-duplicate-imports.md +++ b/src/docs/guide/usage/linter/rules/eslint/no-duplicate-imports.md @@ -1,10 +1,5 @@ - - # eslint/no-duplicate-imports
@@ -15,112 +10,29 @@ const source = `https://github.com/oxc-project/oxc/blob/${ data }/crates/oxc_lin ### What it does -Disallow duplicate module imports. +Disallow duplicate module imports ### Why is this bad? -Using a single import statement per module will make the code clearer because you can see -everything being imported from that module on one line. +Using a single import statement per module will make the code clearer because you can see everything being imported from that module on one line. ### Examples Examples of **incorrect** code for this rule: -In the following example the module import on line 1 is repeated on line 3. These can be -combined to make the list of imports more succinct. - ```js -import something from "another-module"; import { merge } from "module"; +import something from "another-module"; import { find } from "module"; ``` Examples of **correct** code for this rule: ```js +import { merge, find } from "module"; import something from "another-module"; -import { find, merge } from "module"; -``` - -### Options - -#### includeExports - -`{ type: boolean, default: false }` - -When `true` this rule will also look at exports to see if there is both a re-export of a -module as in `export ... from 'module'` and also a standard import statement for the same -module. This would count as a rule violation because there are in a sense two statements -importing from the same module. - -Examples of **incorrect** code when `includeExports` is set to `true`: - -```js -import { merge } from "module"; - -export { find } from "module"; // re-export which is an import and an export. -``` - -Examples of **correct** code when `includeExports` is set to `true`: - -If re-exporting from an imported module, you should add the imports to the -`import` statement, and export that directly, not use `export ... from`. - -```js -import { merge } from "lodash-es"; -export { merge as lodashMerge }; -``` - -```js -import { find, merge } from "module"; - -// cannot be merged with the above import -export * as something from "module"; - -// cannot be written differently -export * from "module"; ``` -#### allowSeparateTypeImports - -`{ type: boolean, default: false }` - -When `true`, imports with only type specifiers (inline types or type imports) are -considered separate from imports with value specifiers, so they can be imported from the -same module on separate import statements. - -Examples of **correct** code when `allowSeparateTypeImports` is set to `true`: - -```js -import { foo } from "module"; -import type { Bar } from "module"; -``` - -```js -import { type Foo } from "module"; -import type { Bar } from "module"; -``` - -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny no-duplicate-imports -``` - -```json [Config (.oxlintrc.json)] -{ - "rules": { - "no-duplicate-imports": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/eslint/no_duplicate_imports.rs) diff --git a/src/docs/guide/usage/linter/rules/eslint/no-else-return.md b/src/docs/guide/usage/linter/rules/eslint/no-else-return.md index 812301668b2..0686510eea1 100644 --- a/src/docs/guide/usage/linter/rules/eslint/no-else-return.md +++ b/src/docs/guide/usage/linter/rules/eslint/no-else-return.md @@ -1,10 +1,5 @@ - - # eslint/no-else-return
@@ -170,26 +165,6 @@ function foo() { } ``` -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny no-else-return -``` - -```json [Config (.oxlintrc.json)] -{ - "rules": { - "no-else-return": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/eslint/no_else_return.rs) diff --git a/src/docs/guide/usage/linter/rules/eslint/no-empty-character-class.md b/src/docs/guide/usage/linter/rules/eslint/no-empty-character-class.md index 90711f03a1d..94157ad10d2 100644 --- a/src/docs/guide/usage/linter/rules/eslint/no-empty-character-class.md +++ b/src/docs/guide/usage/linter/rules/eslint/no-empty-character-class.md @@ -1,10 +1,5 @@ - - # eslint/no-empty-character-class
@@ -21,41 +16,12 @@ Disallow empty character classes in regular expressions Because empty character classes in regular expressions do not match anything, they might be typing mistakes. -### Examples - -Examples of **incorrect** code for this rule: +### Example ```javascript var foo = /^abc[]/; ``` -Examples of **correct** code for this rule: - -```javascript -var foo = /^abc/; -var foo2 = /^abc[123]/; -``` - -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny no-empty-character-class -``` - -```json [Config (.oxlintrc.json)] -{ - "rules": { - "no-empty-character-class": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/eslint/no_empty_character_class.rs) diff --git a/src/docs/guide/usage/linter/rules/eslint/no-empty-function.md b/src/docs/guide/usage/linter/rules/eslint/no-empty-function.md index 2378e725fb1..0b2ab33332c 100644 --- a/src/docs/guide/usage/linter/rules/eslint/no-empty-function.md +++ b/src/docs/guide/usage/linter/rules/eslint/no-empty-function.md @@ -1,10 +1,5 @@ - - # eslint/no-empty-function
@@ -16,66 +11,22 @@ Disallows the usages of empty functions ### Why is this bad? -Empty functions can reduce readability because readers need to guess whether it's +Empty functions can reduce readability because readers need to guess whether it’s intentional or not. So writing a clear comment for empty functions is a good practice. -### Options - -#### allow - -`{ type: string[], default: [] }` - -You may pass a list of allowed function kinds, which will allow functions of -these kinds to be empty. - -Example: - -```json -{ - "no-empty-function": [ - "error", - { "allow": ["functions"] } - ] -} -``` - -`allow` accepts the following values: - -- `"functions"` -- `"arrowFunctions"` -- `"generatorFunctions"` -- `"methods"` -- `"generatorMethods"` -- `"getters"` -- `"setters"` -- `"constructors"` -- `"privateConstructors"` -- `"protectedConstructors"` -- `"asyncFunctions"` -- `"asyncMethods"` -- `"decoratedFunctions"` -- `"overrideMethods"` - -### Examples +### Example Examples of **incorrect** code for this rule: -```typescript -function foo() { -} +```javascript +function foo() {} const bar = () => {}; - -class Foo { - constructor(); - someMethod() {} - set bar(value) {} -} ``` Examples of **correct** code for this rule: -```typescript +```javascript function foo() { // do nothing } @@ -84,38 +35,8 @@ function foo() { return; } const add = (a, b) => a + b; - -class Foo { - // constructor body is empty, but it declares a private property named - // `_name` - constructor(private _name: string) {} - - public get name() { - return this._name; - } -} ``` -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny no-empty-function -``` - -```json [Config (.oxlintrc.json)] -{ - "rules": { - "no-empty-function": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/eslint/no_empty_function.rs) diff --git a/src/docs/guide/usage/linter/rules/eslint/no-empty-pattern.md b/src/docs/guide/usage/linter/rules/eslint/no-empty-pattern.md index 1c5e50b0225..80afcd95c8d 100644 --- a/src/docs/guide/usage/linter/rules/eslint/no-empty-pattern.md +++ b/src/docs/guide/usage/linter/rules/eslint/no-empty-pattern.md @@ -1,10 +1,5 @@ - - # eslint/no-empty-pattern
@@ -25,7 +20,7 @@ an embedded object destructuring pattern, such as: ```JavaScript // doesn't create any variables -var { a: {} } = foo; +var {a: {}} = foo; ``` In this code, no new variables are created because a is just a location helper @@ -33,7 +28,7 @@ while the `{}` is expected to contain the variables to create, such as: ```JavaScript // creates variable b -var { a: { b } } = foo; +var {a: { b }} = foo; ``` In many cases, the empty object pattern is a mistake @@ -41,7 +36,7 @@ where the author intended to use a default value instead, such as: ```JavaScript // creates variable a -var { a = {} } = foo; +var {a = {}} = foo; ``` The difference between these two patterns is subtle, @@ -52,43 +47,23 @@ especially because the problematic empty pattern looks just like an object liter ```JavaScript var {} = foo; var [] = foo; -var { a: {} } = foo; -var { a: [] } = foo; +var {a: {}} = foo; +var {a: []} = foo; function foo({}) {} function foo([]) {} -function foo({ a: {} }) {} -function foo({ a: [] }) {} +function foo({a: {}}) {} +function foo({a: []}) {} ``` ### Examples of correct code for this rule: ```JavaScript -var { a = {} } = foo; -var { a = [] } = foo; -function foo({ a = {} }) {} -function foo({ a = [] }) {} +var {a = {}} = foo; +var {a = []} = foo; +function foo({a = {}}) {} +function foo({a = []}) {} ``` -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny no-empty-pattern -``` - -```json [Config (.oxlintrc.json)] -{ - "rules": { - "no-empty-pattern": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/eslint/no_empty_pattern.rs) diff --git a/src/docs/guide/usage/linter/rules/eslint/no-empty-static-block.md b/src/docs/guide/usage/linter/rules/eslint/no-empty-static-block.md index 3e60af2180d..73a62a5b3b2 100644 --- a/src/docs/guide/usage/linter/rules/eslint/no-empty-static-block.md +++ b/src/docs/guide/usage/linter/rules/eslint/no-empty-static-block.md @@ -1,10 +1,5 @@ - - # eslint/no-empty-static-block
@@ -26,14 +21,13 @@ Empty block statements, while not technically errors, usually occur due to refactoring that wasn’t completed. They can cause confusion when reading code. -### Examples +### Example Examples of **incorrect** code for this rule: ```js class Foo { - static { - } + static {} } ``` @@ -52,26 +46,6 @@ class Bar { } ``` -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny no-empty-static-block -``` - -```json [Config (.oxlintrc.json)] -{ - "rules": { - "no-empty-static-block": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/eslint/no_empty_static_block.rs) diff --git a/src/docs/guide/usage/linter/rules/eslint/no-empty.md b/src/docs/guide/usage/linter/rules/eslint/no-empty.md index 06a24db1c25..50cddd1e9ca 100644 --- a/src/docs/guide/usage/linter/rules/eslint/no-empty.md +++ b/src/docs/guide/usage/linter/rules/eslint/no-empty.md @@ -1,10 +1,5 @@ - - # eslint/no-empty
@@ -22,43 +17,13 @@ Disallows empty block statements Empty block statements, while not technically errors, usually occur due to refactoring that wasn’t completed. They can cause confusion when reading code. -### Examples - -Examples of **incorrect** code for this rule: +### Example ```javascript if (condition) { } ``` -Examples of **correct** code for this rule: - -```javascript -if (condition) { - throw new Error("condition should be false"); -} -``` - -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny no-empty -``` - -```json [Config (.oxlintrc.json)] -{ - "rules": { - "no-empty": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/eslint/no_empty.rs) diff --git a/src/docs/guide/usage/linter/rules/eslint/no-eq-null.md b/src/docs/guide/usage/linter/rules/eslint/no-eq-null.md index 8f773b3a0da..3c937daea18 100644 --- a/src/docs/guide/usage/linter/rules/eslint/no-eq-null.md +++ b/src/docs/guide/usage/linter/rules/eslint/no-eq-null.md @@ -1,10 +1,5 @@ - - # eslint/no-eq-null
@@ -23,7 +18,7 @@ Comparing to `null` without a type-checking operator (`==` or `!=`), can have unintended results as the comparison will evaluate to `true` when comparing to not just a `null`, but also an `undefined` value. -### Examples +### Example Examples of **incorrect** code for this rule: @@ -52,26 +47,6 @@ if (bang === undefined) { } ``` -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny no-eq-null -``` - -```json [Config (.oxlintrc.json)] -{ - "rules": { - "no-eq-null": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/eslint/no_eq_null.rs) diff --git a/src/docs/guide/usage/linter/rules/eslint/no-eval.md b/src/docs/guide/usage/linter/rules/eslint/no-eval.md index 9d40e13f699..24ba609b822 100644 --- a/src/docs/guide/usage/linter/rules/eslint/no-eval.md +++ b/src/docs/guide/usage/linter/rules/eslint/no-eval.md @@ -1,113 +1,26 @@ - - -# eslint/no-eval +# eslint/no-eval
- -βœ… This rule is turned on by default. -
### What it does -Disallows referencing the `eval` function. This rule is aimed at preventing -potentially dangerous, unnecessary, and slow code by disallowing the use of -the `eval()` function. +Disallows referencing the 'eval' function. ### Why is this bad? -JavaScript’s `eval()` function is potentially dangerous and is often misused. -Using `eval()` on untrusted code can open a program up to several different -injection attacks. The use of `eval()` in most contexts can be substituted for -a better, safer alternative approach to solving the problem, such as using -`JSON.parse()` or `Function` constructors in safer ways. - -### Examples - -Examples of **incorrect** code for this rule: - -```js -const obj = { x: "foo" }, - key = "x", - value = eval("obj." + key); - -(0, eval)("const a = 0"); - -const foo = eval; -foo("const a = 0"); - -this.eval("const a = 0"); -``` - -Examples of **correct** code for this rule: - -```js -const obj = { x: "foo" }, - key = "x", - value = obj[key]; - -class A { - foo() { - this.eval("const a = 0"); - } - - eval() {} - - static { - this.eval("const a = 0"); - } - - static eval() {} -} -``` - -### Options - -#### allowIndirect - -`{ type: boolean, default: true }` - -This `allowIndirect` option allows indirect `eval()` calls. - -Indirect calls to `eval`(e.g., `window['eval']`) are less dangerous -than direct calls because they cannot dynamically change the scope. -Indirect `eval()` calls also typically have less impact on performance -compared to direct calls, as they do not invoke JavaScript's scope chain. - -Example: +Calling 'eval' is not supported in some secure contexts and can lead to +vulnerabilities. -```json -"eslint/no-eval": [ - "error", - { "allowIndirect": true } -] -``` - -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group +### Example -```bash [CLI] -oxlint --deny no-eval +```javascript +const someString = "console.log('pwned')"; +eval(someString); ``` -```json [Config (.oxlintrc.json)] -{ - "rules": { - "no-eval": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/eslint/no_eval.rs) diff --git a/src/docs/guide/usage/linter/rules/eslint/no-ex-assign.md b/src/docs/guide/usage/linter/rules/eslint/no-ex-assign.md index e8d1c5a5cf9..ffde7e3bcc1 100644 --- a/src/docs/guide/usage/linter/rules/eslint/no-ex-assign.md +++ b/src/docs/guide/usage/linter/rules/eslint/no-ex-assign.md @@ -1,10 +1,5 @@ - - # eslint/no-ex-assign
@@ -25,9 +20,7 @@ it is impossible to refer to the error from that point on. Since there is no arguments object to offer alternative access to this data, assignment of the parameter is absolutely destructive. -### Examples - -Examples of **incorrect** code for this rule: +### Example ```javascript try { @@ -37,36 +30,6 @@ try { } ``` -Examples of **correct** code for this rule: - -```javascript -try { - // code -} catch (e) { - let val = 10; -} -``` - -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny no-ex-assign -``` - -```json [Config (.oxlintrc.json)] -{ - "rules": { - "no-ex-assign": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/eslint/no_ex_assign.rs) diff --git a/src/docs/guide/usage/linter/rules/eslint/no-extend-native.md b/src/docs/guide/usage/linter/rules/eslint/no-extend-native.md index 365bc95bc03..520fc61860d 100644 --- a/src/docs/guide/usage/linter/rules/eslint/no-extend-native.md +++ b/src/docs/guide/usage/linter/rules/eslint/no-extend-native.md @@ -1,10 +1,5 @@ - - # eslint/no-extend-native
@@ -27,8 +22,8 @@ Object.prototype.extra = 55; // Defining a user object const users = { - "1": "user1", - "2": "user2", + 1: "user1", + 2: "user2", }; for (const id in users) { @@ -53,26 +48,6 @@ x.prototype.p = 0; Object.defineProperty(x.prototype, "p", { value: 0 }); ``` -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny no-extend-native -``` - -```json [Config (.oxlintrc.json)] -{ - "rules": { - "no-extend-native": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/eslint/no_extend_native.rs) diff --git a/src/docs/guide/usage/linter/rules/eslint/no-extra-bind.md b/src/docs/guide/usage/linter/rules/eslint/no-extra-bind.md deleted file mode 100644 index bfaeb80200c..00000000000 --- a/src/docs/guide/usage/linter/rules/eslint/no-extra-bind.md +++ /dev/null @@ -1,74 +0,0 @@ - - - - -# eslint/no-extra-bind - -
- -🚧 An auto-fix is still under development. - -
- -### What it does - -Disallow unnecessary calls to .bind() - -### Why is this bad? - -This rule is aimed at avoiding the unnecessary use of bind() -and as such will warn whenever an immediately-invoked function expression (IIFE) is using bind() -and doesn’t have an appropriate this value. -This rule won’t flag usage of bind() that includes function argument binding. - -### Examples - -Examples of **incorrect** code for this rule: - -```js -const x = function() { - foo(); -}.bind(bar); - -const z = (() => { - this.foo(); -}).bind(this); -``` - -Examples of **correct** code for this rule: - -```js -const x = function() { - this.foo(); -}.bind(bar); -const y = function(a) { - return a + 1; -}.bind(foo, bar); -``` - -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny no-extra-bind -``` - -```json [Config (.oxlintrc.json)] -{ - "rules": { - "no-extra-bind": "error" - } -} -``` - -::: - -## References - -- Rule Source diff --git a/src/docs/guide/usage/linter/rules/eslint/no-extra-boolean-cast.md b/src/docs/guide/usage/linter/rules/eslint/no-extra-boolean-cast.md index baca15c0902..a6889e8eea4 100644 --- a/src/docs/guide/usage/linter/rules/eslint/no-extra-boolean-cast.md +++ b/src/docs/guide/usage/linter/rules/eslint/no-extra-boolean-cast.md @@ -1,10 +1,5 @@ - - # eslint/no-extra-boolean-cast
@@ -12,7 +7,7 @@ const source = `https://github.com/oxc-project/oxc/blob/${ data }/crates/oxc_lin βœ… This rule is turned on by default. -πŸ› οΈπŸ’‘ An auto-fix and a suggestion are available for this rule for some violations. +🚧 An auto-fix is still under development.
@@ -22,57 +17,25 @@ This rule disallows unnecessary boolean casts. ### Why is this bad? -In contexts such as an if statement's test where the result of the expression will already be coerced to a Boolean, +In contexts such as an if statement’s test where the result of the expression will already be coerced to a Boolean, casting to a Boolean via double negation (!!) or a Boolean call is unnecessary. -### Examples - -Examples of **incorrect** code for this rule: +### Example ```javascript var foo = !!!bar; var foo = Boolean(!!bar); -if (!!foo) {} -if (Boolean(foo)) {} - -// with "enforceForLogicalOperands" option enabled -if (!!foo || bar) {} -``` - -Examples of **correct** code for this rule: - -```javascript -var foo = !bar; -var foo = Boolean(bar); - -if (foo) {} -if (foo) {} +if (!!foo) { +} +if (Boolean(foo)) { +} // with "enforceForLogicalOperands" option enabled -if (foo || bar) {} -``` - -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny no-extra-boolean-cast -``` - -```json [Config (.oxlintrc.json)] -{ - "rules": { - "no-extra-boolean-cast": "error" - } +if (!!foo || bar) { } ``` -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/eslint/no_extra_boolean_cast.rs) diff --git a/src/docs/guide/usage/linter/rules/eslint/no-extra-label.md b/src/docs/guide/usage/linter/rules/eslint/no-extra-label.md deleted file mode 100644 index 14298bbf5b8..00000000000 --- a/src/docs/guide/usage/linter/rules/eslint/no-extra-label.md +++ /dev/null @@ -1,109 +0,0 @@ - - - - -# eslint/no-extra-label - -
- -πŸ› οΈ An auto-fix is available for this rule. - -
- -### What it does - -Disallow unnecessary labels. - -### Why is this bad? - -If a loop contains no nested loops or switches, labeling the loop is unnecessary. - -```js -A: while (a) { - break A; -} -``` - -You can achieve the same result by removing the label and using `break` or `continue` without a label. -Probably those labels would confuse developers because they expect labels to jump to further. - -### Examples - -Examples of **incorrect** code for this rule: - -```js -A: while (a) { - break A; -} - -B: for (let i = 0; i < 10; ++i) { - break B; -} - -C: switch (a) { - case 0: - break C; -} -``` - -Examples of **correct** code for this rule: - -```js -while (a) { - break; -} - -for (let i = 0; i < 10; ++i) { - break; -} - -switch (a) { - case 0: - break; -} - -A: { - break A; -} - -B: while (a) { - while (b) { - break B; - } -} - -C: switch (a) { - case 0: - while (b) { - break C; - } - break; -} -``` - -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny no-extra-label -``` - -```json [Config (.oxlintrc.json)] -{ - "rules": { - "no-extra-label": "error" - } -} -``` - -::: - -## References - -- Rule Source diff --git a/src/docs/guide/usage/linter/rules/eslint/no-fallthrough.md b/src/docs/guide/usage/linter/rules/eslint/no-fallthrough.md index 8df623b5009..189e24de8ab 100644 --- a/src/docs/guide/usage/linter/rules/eslint/no-fallthrough.md +++ b/src/docs/guide/usage/linter/rules/eslint/no-fallthrough.md @@ -1,10 +1,5 @@ - - # eslint/no-fallthrough
@@ -62,7 +57,7 @@ fallthrough is intentional using a comment which matches the switch (foo) { case 1: doSomething(); - // falls through + // falls through case 2: doSomethingElse(); @@ -71,7 +66,7 @@ switch (foo) { switch (foo) { case 1: doSomething(); - // fall through + // fall through case 2: doSomethingElse(); @@ -80,7 +75,7 @@ switch (foo) { switch (foo) { case 1: doSomething(); - // fallsthrough + // fallsthrough case 2: doSomethingElse(); @@ -102,11 +97,13 @@ In this example, there is no confusion as to the expected behavior. It is clear that the first case is meant to fall through to the second case. -### Examples +### Example Examples of **incorrect** code for this rule: ```js +/*oxlint no-fallthrough: "error"*/ + switch (foo) { case 1: doSomething(); @@ -119,6 +116,8 @@ switch (foo) { Examples of **correct** code for this rule: ```js +/*oxlint no-fallthrough: "error"*/ + switch (foo) { case 1: doSomething(); @@ -163,7 +162,7 @@ switch (foo) { switch (foo) { case 1: doSomething(); - // falls through + // falls through case 2: doSomething(); @@ -184,26 +183,6 @@ switch (foo) { Note that the last case statement in these examples does not cause a warning because there is nothing to fall through into. -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny no-fallthrough -``` - -```json [Config (.oxlintrc.json)] -{ - "rules": { - "no-fallthrough": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/eslint/no_fallthrough.rs) diff --git a/src/docs/guide/usage/linter/rules/eslint/no-func-assign.md b/src/docs/guide/usage/linter/rules/eslint/no-func-assign.md index b116d33a801..cfc2ed09011 100644 --- a/src/docs/guide/usage/linter/rules/eslint/no-func-assign.md +++ b/src/docs/guide/usage/linter/rules/eslint/no-func-assign.md @@ -1,10 +1,5 @@ - - # eslint/no-func-assign
@@ -19,69 +14,15 @@ Disallow reassigning `function` declarations ### Why is this bad? -Overwriting/reassigning a function written as a FunctionDeclaration is often indicative of -a mistake or issue. - -### Examples +Overwriting/reassigning a function written as a FunctionDeclaration is often indicative of a mistake or issue. -Examples of **incorrect** code for this rule: +### Example ```javascript function foo() {} foo = bar; ``` -```javascript -function foo() { - foo = bar; -} -``` - -```javascript -let a = function hello() { - hello = 123; -}; -``` - -Examples of **correct** code for this rule: - -```javascript -let foo = function() {}; -foo = bar; -``` - -```javascript -function baz(baz) { // `baz` is shadowed. - baz = bar; -} -``` - -``` -function qux() { - const qux = bar; // `qux` is shadowed. -} -``` - -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny no-func-assign -``` - -```json [Config (.oxlintrc.json)] -{ - "rules": { - "no-func-assign": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/eslint/no_func_assign.rs) diff --git a/src/docs/guide/usage/linter/rules/eslint/no-global-assign.md b/src/docs/guide/usage/linter/rules/eslint/no-global-assign.md index 2f7787fa35e..8bdcbc48ab2 100644 --- a/src/docs/guide/usage/linter/rules/eslint/no-global-assign.md +++ b/src/docs/guide/usage/linter/rules/eslint/no-global-assign.md @@ -1,10 +1,5 @@ - - # eslint/no-global-assign
@@ -21,34 +16,12 @@ Disallow modifications to read-only global variables. In almost all cases, you don’t want to assign a value to these global variables as doing so could result in losing access to important functionality. -### Examples - -Examples of **incorrect** code for this rule: +### Example ```javascript Object = null; ``` -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny no-global-assign -``` - -```json [Config (.oxlintrc.json)] -{ - "rules": { - "no-global-assign": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/eslint/no_global_assign.rs) diff --git a/src/docs/guide/usage/linter/rules/eslint/no-import-assign.md b/src/docs/guide/usage/linter/rules/eslint/no-import-assign.md index 82eb9783dd4..ea1e5d85f6e 100644 --- a/src/docs/guide/usage/linter/rules/eslint/no-import-assign.md +++ b/src/docs/guide/usage/linter/rules/eslint/no-import-assign.md @@ -1,10 +1,5 @@ - - # eslint/no-import-assign
@@ -21,9 +16,7 @@ Disallow assigning to imported bindings The updates of imported bindings by ES Modules cause runtime errors. -### Examples - -Examples of **incorrect** code for this rule: +### Example ```javascript import mod, { named } from "./mod.mjs"; @@ -37,26 +30,6 @@ mod_ns = {}; // ERROR: 'mod_ns' is readonly. Object.assign(mod_ns, { foo: "foo" }); // ERROR: The members of 'mod_ns' are readonly. ``` -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny no-import-assign -``` - -```json [Config (.oxlintrc.json)] -{ - "rules": { - "no-import-assign": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/eslint/no_import_assign.rs) diff --git a/src/docs/guide/usage/linter/rules/eslint/no-inner-declarations.md b/src/docs/guide/usage/linter/rules/eslint/no-inner-declarations.md index d1705491479..a9cc25e8466 100644 --- a/src/docs/guide/usage/linter/rules/eslint/no-inner-declarations.md +++ b/src/docs/guide/usage/linter/rules/eslint/no-inner-declarations.md @@ -1,10 +1,5 @@ - - # eslint/no-inner-declarations
@@ -20,9 +15,7 @@ A variable declaration is permitted anywhere a statement can go, even nested dee This is often undesirable due to variable hoisting, and moving declarations to the root of the program or function body can increase clarity. Note that block bindings (let, const) are not hoisted and therefore they are not affected by this rule. -### Examples - -Examples of **incorrect** code for this rule: +### Example ```javascript if (test) { @@ -30,35 +23,6 @@ if (test) { } ``` -Examples of **correct** code for this rule: - -```javascript -function doSomethingElse() {} -if (test) { - // your code here -} -``` - -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny no-inner-declarations -``` - -```json [Config (.oxlintrc.json)] -{ - "rules": { - "no-inner-declarations": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/eslint/no_inner_declarations.rs) diff --git a/src/docs/guide/usage/linter/rules/eslint/no-invalid-regexp.md b/src/docs/guide/usage/linter/rules/eslint/no-invalid-regexp.md index 9d3a3a8eaef..3c84a3de41f 100644 --- a/src/docs/guide/usage/linter/rules/eslint/no-invalid-regexp.md +++ b/src/docs/guide/usage/linter/rules/eslint/no-invalid-regexp.md @@ -1,10 +1,5 @@ - - # eslint/no-invalid-regexp
@@ -40,38 +35,6 @@ new RegExp(); this.RegExp("["); ``` -## Configuration - -This rule accepts a configuration object with the following properties: - -### allowConstructorFlags - -type: `string[]` - -default: `[]` - -Case-sensitive array of flags that will be allowed. - -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny no-invalid-regexp -``` - -```json [Config (.oxlintrc.json)] -{ - "rules": { - "no-invalid-regexp": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/eslint/no_invalid_regexp.rs) diff --git a/src/docs/guide/usage/linter/rules/eslint/no-irregular-whitespace.md b/src/docs/guide/usage/linter/rules/eslint/no-irregular-whitespace.md index 9aee11c8032..b274615cfbf 100644 --- a/src/docs/guide/usage/linter/rules/eslint/no-irregular-whitespace.md +++ b/src/docs/guide/usage/linter/rules/eslint/no-irregular-whitespace.md @@ -1,10 +1,5 @@ - - # eslint/no-irregular-whitespace
@@ -15,53 +10,21 @@ const source = `https://github.com/oxc-project/oxc/blob/${ data }/crates/oxc_lin ### What it does -Disallows the use of irregular whitespace characters in the code. - -### Why is this bad? - -Irregular whitespace characters are invisible to most editors and can -cause unexpected behavior, making code harder to debug and maintain. -They can also cause issues with code formatting and parsing. - -### Examples +Disallows the use of irregular whitespaces in the code. -Examples of **incorrect** code for this rule: +### Why is this bad -```javascript -// Contains irregular whitespace characters (invisible) -function example() { - var foo = "bar"; // irregular whitespace before 'bar' -} -``` +The use of irregular whitespaces can hinder code readability and +create inconsistencies, making maintenance and collaboration more challenging. -Examples of **correct** code for this rule: +### Example ```javascript -function example() { - var foo = "bar"; // regular spaces only -} -``` - -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny no-irregular-whitespace -``` - -```json [Config (.oxlintrc.json)] -{ - "rules": { - "no-irregular-whitespace": "error" - } +function invalidExample() { + return 42; } ``` -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/eslint/no_irregular_whitespace.rs) diff --git a/src/docs/guide/usage/linter/rules/eslint/no-iterator.md b/src/docs/guide/usage/linter/rules/eslint/no-iterator.md index b5e70f7b65a..1892c31a93b 100644 --- a/src/docs/guide/usage/linter/rules/eslint/no-iterator.md +++ b/src/docs/guide/usage/linter/rules/eslint/no-iterator.md @@ -1,15 +1,10 @@ - - # eslint/no-iterator
-πŸ’‘ A suggestion is available for this rule. +🚧 An auto-fix is still under development.
@@ -26,23 +21,23 @@ now obsolete, so it should not be used. Here’s an example of how this used to work: ```js -Foo.prototype.__iterator__ = function() { +Foo.prototype.__iterator__ = function () { return new FooIterator(this); }; ``` -### Examples +### Example Examples of **incorrect** code for this rule: ```javascript -Foo.prototype.__iterator__ = function() { +Foo.prototype.__iterator__ = function () { return new FooIterator(this); }; -foo.__iterator__ = function() {}; +foo.__iterator__ = function () {}; -foo["__iterator__"] = function() {}; +foo["__iterator__"] = function () {}; ``` Examples of **correct** code for this rule: @@ -50,31 +45,11 @@ Examples of **correct** code for this rule: ```js const __iterator__ = 42; // not using the __iterator__ property -Foo.prototype[Symbol.iterator] = function() { +Foo.prototype[Symbol.iterator] = function () { return new FooIterator(this); }; ``` -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny no-iterator -``` - -```json [Config (.oxlintrc.json)] -{ - "rules": { - "no-iterator": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/eslint/no_iterator.rs) diff --git a/src/docs/guide/usage/linter/rules/eslint/no-label-var.md b/src/docs/guide/usage/linter/rules/eslint/no-label-var.md index 6f2c04adf97..1153135f49f 100644 --- a/src/docs/guide/usage/linter/rules/eslint/no-label-var.md +++ b/src/docs/guide/usage/linter/rules/eslint/no-label-var.md @@ -1,10 +1,5 @@ - - # eslint/no-label-var
@@ -19,15 +14,14 @@ Disallow labels that share a name with a variable. This rule aims to create clearer code by disallowing the bad practice of creating a label that shares a name with a variable that is in scope. -### Examples +### Example Examples of **incorrect** code for this rule: ```js var x = foo; function bar() { - x: - for (;;) { + x: for (;;) { break x; } } @@ -43,33 +37,12 @@ function foo() { } function bar() { - q: - for (;;) { + q: for (;;) { break q; } } ``` -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny no-label-var -``` - -```json [Config (.oxlintrc.json)] -{ - "rules": { - "no-label-var": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/eslint/no_label_var.rs) diff --git a/src/docs/guide/usage/linter/rules/eslint/no-labels.md b/src/docs/guide/usage/linter/rules/eslint/no-labels.md deleted file mode 100644 index b661c0278e2..00000000000 --- a/src/docs/guide/usage/linter/rules/eslint/no-labels.md +++ /dev/null @@ -1,141 +0,0 @@ - - - - -# eslint/no-labels - -
-
- -### What it does - -Disallow labeled statements. - -### Why is this bad? - -Labeled statements in JavaScript are used in conjunction with `break` and `continue` to control flow around multiple loops. For example: - -```js -outer: -while (true) { - while (true) { - break outer; - } -} -``` - -The `break outer` statement ensures that this code will not result in an infinite loop because control is returned to the next statement after the `outer` label was applied. If this statement was changed to be just `break`, control would flow back to the outer `while` statement and an infinite loop would result. -While convenient in some cases, labels tend to be used only rarely and are frowned upon by some as a remedial form of flow control that is more error prone and harder to understand. - -### Examples - -Examples of **incorrect** code for this rule: - -```js -label: -while (true) { - // ... -} - -label: -while (true) { - break label; -} - -label: -while (true) { - continue label; -} - -label: -switch (a) { - case 0: - break label; -} - -label: -{ - break label; -} - -label: -if (a) { - break label; -} -``` - -Examples of **correct** code for this rule: - -```js -var f = { - label: "foo", -}; - -while (true) { - break; -} - -while (true) { - continue; -} -``` - -### Options - -The options allow labels with loop or switch statements: - -- `"allowLoop"` (`boolean`, default is `false`) - If this option was set `true`, this rule ignores labels which are sticking to loop statements. -- `"allowSwitch"` (`boolean`, default is `false`) - If this option was set `true`, this rule ignores labels which are sticking to switch statements. - -Actually labeled statements in JavaScript can be used with other than loop and switch statements. -However, this way is ultra rare, not well-known, so this would be confusing developers. - -#### allowLoop - -Examples of **correct** code for the `{ "allowLoop": true }` option: - -```js -label: -while (true) { - break label; -} -``` - -#### allowSwitch - -Examples of **correct** code for the `{ "allowSwitch": true }` option: - -```js -label: -switch (a) { - case 0: - break label; -} -``` - -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny no-labels -``` - -```json [Config (.oxlintrc.json)] -{ - "rules": { - "no-labels": "error" - } -} -``` - -::: - -## References - -- Rule Source diff --git a/src/docs/guide/usage/linter/rules/eslint/no-lone-blocks.md b/src/docs/guide/usage/linter/rules/eslint/no-lone-blocks.md deleted file mode 100644 index 09e0b413240..00000000000 --- a/src/docs/guide/usage/linter/rules/eslint/no-lone-blocks.md +++ /dev/null @@ -1,66 +0,0 @@ - - - - -# eslint/no-lone-blocks - -
-
- -### What it does - -Disallows unnecessary standalone block statements. - -### Why is this bad? - -Standalone blocks can be confusing as they do not provide any meaningful purpose when used unnecessarily. -They may introduce extra nesting, reducing code readability, and can mislead readers about scope or intent. - -### Examples - -Examples of **incorrect** code for this rule: - -```js -{ - var x = 1; -} -``` - -Examples of **correct** code for this rule: - -```js -if (condition) { - var x = 1; -} - -{ - let x = 1; // Used to create a valid block scope. -} -``` - -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny no-lone-blocks -``` - -```json [Config (.oxlintrc.json)] -{ - "rules": { - "no-lone-blocks": "error" - } -} -``` - -::: - -## References - -- Rule Source diff --git a/src/docs/guide/usage/linter/rules/eslint/no-lonely-if.md b/src/docs/guide/usage/linter/rules/eslint/no-lonely-if.md deleted file mode 100644 index 8ae7d85f830..00000000000 --- a/src/docs/guide/usage/linter/rules/eslint/no-lonely-if.md +++ /dev/null @@ -1,104 +0,0 @@ - - - - -# eslint/no-lonely-if - -
- -🚧 An auto-fix is still under development. - -
- -### What it does - -Disallow `if` statements as the only statement in `else` blocks - -### Why is this bad? - -When an `if` statement is the only statement in an `else` block, it is often clearer to use -an `else if` instead. - -### Examples - -Examples of **incorrect** code for this rule: - -```js -if (condition) { - // ... -} else { - if (anotherCondition) { - // ... - } -} -``` - -```js -if (condition) { - // ... -} else { - if (anotherCondition) { - // ... - } else { - // ... - } -} -``` - -Examples of **correct** code for this rule: - -```js -if (condition) { - // ... -} else if (anotherCondition) { - // ... -} -``` - -```js -if (condition) { - // ... -} else if (anotherCondition) { - // ... -} else { - // ... -} -``` - -```js -if (condition) { - // ... -} else { - if (anotherCondition) { - // ... - } - doSomething(); -} -``` - -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny no-lonely-if -``` - -```json [Config (.oxlintrc.json)] -{ - "rules": { - "no-lonely-if": "error" - } -} -``` - -::: - -## References - -- Rule Source diff --git a/src/docs/guide/usage/linter/rules/eslint/no-loss-of-precision.md b/src/docs/guide/usage/linter/rules/eslint/no-loss-of-precision.md index b0e9e1cb138..bb6bfa4df5d 100644 --- a/src/docs/guide/usage/linter/rules/eslint/no-loss-of-precision.md +++ b/src/docs/guide/usage/linter/rules/eslint/no-loss-of-precision.md @@ -1,10 +1,5 @@ - - # eslint/no-loss-of-precision
@@ -22,78 +17,12 @@ Disallow precision loss of number literal It can lead to unexpected results in certain situations For example, when performing mathematical operations -In JS, Numbers are stored as double-precision floating-point numbers -according to the IEEE 754 standard. Because of this, numbers can only -retain accuracy up to a certain amount of digits. If the programmer -enters additional digits, those digits will be lost in the conversion -to the Number type and will result in unexpected behavior. - -### Examples - -Examples of **incorrect** code for this rule: +### Example ```javascript var x = 2e999; ``` -```javascript -var x = 9007199254740993; -``` - -```javascript -var x = 5123000000000000000000000000001; -``` - -```javascript -var x = 1230000000000000000000000.0; -``` - -```javascript -var x = 0X200000_0000000_1; -``` - -Examples of **correct** code for this rule: - -```javascript -var x = 12345"; -``` - -```javascript -var x = 123.456; -``` - -```javascript -var x = 123.0000000000000000000000"; -``` - -```javascript -var x = 123e34; -``` - -```javascript -var x = 0x1FFF_FFFF_FFF_FFF; -``` - -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny no-loss-of-precision -``` - -```json [Config (.oxlintrc.json)] -{ - "rules": { - "no-loss-of-precision": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/eslint/no_loss_of_precision.rs) diff --git a/src/docs/guide/usage/linter/rules/eslint/no-magic-numbers.md b/src/docs/guide/usage/linter/rules/eslint/no-magic-numbers.md index f9279bad0b1..909ad4f0344 100644 --- a/src/docs/guide/usage/linter/rules/eslint/no-magic-numbers.md +++ b/src/docs/guide/usage/linter/rules/eslint/no-magic-numbers.md @@ -1,10 +1,5 @@ - - # eslint/no-magic-numbers
@@ -15,7 +10,7 @@ const source = `https://github.com/oxc-project/oxc/blob/${ data }/crates/oxc_lin ### What it does -This rule aims to make code more readable and refactoring easier by ensuring that special numbers are declared as constants to make their meaning explicit. +The no-magic-numbers rule aims to make code more readable and refactoring easier by ensuring that special numbers are declared as constants to make their meaning explicit. The current implementation does not support BigInt numbers inside array indexes. ### Why is this bad? @@ -28,7 +23,7 @@ Examples of **incorrect** code for this rule: ```javascript var dutyFreePrice = 100; -var finalPrice = dutyFreePrice + (dutyFreePrice * 0.25); +var finalPrice = dutyFreePrice + dutyFreePrice * 0.25; ``` Examples of **correct** code for this rule with option "ignore": @@ -47,7 +42,7 @@ var item = data[2]; data[100] = a; f(data[0]); a = data[-0]; // same as data[0], -0 will be coerced to "0" -a = data[0xAB]; +a = data[0xab]; a = data[5.6e1]; a = data[4294967294]; // max array index ``` @@ -57,7 +52,9 @@ Examples of **correct** code for this rule with option "ignoreDefaultValues": ```javascript /*typescript no-magic-numbers: ["error", { "ignoreDefaultValues": true }]*/ const { tax = 0.25 } = accountancy; -function mapParallel(concurrency = 3) {/***/} +function mapParallel(concurrency = 3) { + /***/ +} ``` Examples of **correct** code for this rule with option "ignoreClassFieldInitialValues": @@ -135,26 +132,6 @@ type Foo = Bar[0]; type Baz = Parameters[2]; ``` -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny no-magic-numbers -``` - -```json [Config (.oxlintrc.json)] -{ - "rules": { - "no-magic-numbers": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/eslint/no_magic_numbers.rs) diff --git a/src/docs/guide/usage/linter/rules/eslint/no-misleading-character-class.md b/src/docs/guide/usage/linter/rules/eslint/no-misleading-character-class.md deleted file mode 100644 index f78f4e73c0e..00000000000 --- a/src/docs/guide/usage/linter/rules/eslint/no-misleading-character-class.md +++ /dev/null @@ -1,106 +0,0 @@ - - - - -# eslint/no-misleading-character-class - -
-
- -### What it does - -This rule reports regular expressions which include multiple code point characters in character class syntax. This includes: - -- Characters with combining marks (e.g., `Á` where `A` is followed by a combining acute accent) -- Characters with emoji modifiers (e.g., `πŸ‘ΆπŸ»`) -- Pairs of regional indicator symbols (e.g., `πŸ‡―πŸ‡΅`) -- Characters joined by zero-width joiner (ZWJ) (e.g., `πŸ‘¨β€πŸ‘©β€πŸ‘¦`) -- Surrogate pairs without the Unicode flag (e.g., `/^[πŸ‘]$/`) - -### Why is this bad? - -Unicode includes characters which are made by multiple code points. -RegExp character class syntax (`/[abc]/`) cannot handle characters -which are made by multiple code points as a character; -those characters will be dissolved to each code point. -For example, `❇️` is made by `❇` (`U+2747`) and VARIATION SELECTOR-16 (`U+FE0F`). -If this character is in a RegExp character class, -it will match either `❇` (`U+2747`) or VARIATION SELECTOR-16 (`U+FE0F`) rather than `❇️`. - -This can lead to regular expressions that do not match what the author intended, -especially for emoji, regional indicators, and characters with combining marks. - -#### Examples - -Examples of **incorrect** code for this rule: - -```javascript -/^[Á]$/u; -/^[❇️]$/u; -/^[πŸ‘ΆπŸ»]$/u; -/^[πŸ‡―πŸ‡΅]$/u; -/^[πŸ‘¨β€πŸ‘©β€πŸ‘¦]$/u; -/^[πŸ‘]$/; -new RegExp("[🎡]"); -``` - -Examples of **correct** code for this rule: - -```javascript -/^[abc]$/; -/^[πŸ‘]$/u; -/[\u00B7\u0300-\u036F]/u; -new RegExp("^[\u{1F1EF}\u{1F1F5}]", "u"); -``` - -#### Options - -This rule has an object option: - -- `allowEscape`: When set to `true`, the rule allows any grouping of code points - inside a character class as long as they are written using escape sequences. - -Examples of **incorrect** code for this rule with `{ "allowEscape": true }`: - -```javascript -/[\uD83D]/; // backslash can be omitted -new RegExp("[\ud83d" + "\udc4d]"); -``` - -Examples of **correct** code for this rule with `{ "allowEscape": true }`: - -```javascript -/[\ud83d\udc4d]/; -/[\u00B7\u0300-\u036F]/u; -/[πŸ‘¨\u200dπŸ‘©]/u; -new RegExp("[\x41\u0301]"); -new RegExp(`[\u{1F1EF}\u{1F1F5}]`, "u"); -new RegExp("[\\u{1F1EF}\\u{1F1F5}]", "u"); -``` - -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny no-misleading-character-class -``` - -```json [Config (.oxlintrc.json)] -{ - "rules": { - "no-misleading-character-class": "error" - } -} -``` - -::: - -## References - -- Rule Source diff --git a/src/docs/guide/usage/linter/rules/eslint/no-multi-assign.md b/src/docs/guide/usage/linter/rules/eslint/no-multi-assign.md deleted file mode 100644 index 5a3356815d9..00000000000 --- a/src/docs/guide/usage/linter/rules/eslint/no-multi-assign.md +++ /dev/null @@ -1,123 +0,0 @@ - - - - -# eslint/no-multi-assign - -
-
- -### What it does - -Disallow use of chained assignment expressions. - -### Why is this bad? - -Chaining the assignment of variables can lead to unexpected results and be difficult to read. - -```js -(function() { - const foo = bar = 0; // Did you mean `foo = bar == 0`? - bar = 1; // This will not fail since `bar` is not constant. -})(); -console.log(bar); // This will output 1 since `bar` is not scoped. -``` - -### Examples - -Examples of **incorrect** code for this rule: - -```js -var a = b = c = 5; - -const foo = bar = "baz"; - -let d = e = f; - -class Foo { - a = b = 10; -} - -a = b = "quux"; -``` - -Examples of **correct** code for this rule: - -```js -var a = 5; -var b = 5; -var c = 5; - -const foo = "baz"; -const bar = "baz"; - -let d = c; -let e = c; - -class Foo { - a = 10; - b = 10; -} - -a = "quux"; -b = "quux"; -``` - -### Options - -This rule has an object option: - -- `"ignoreNonDeclaration"`: When set to `true`, the rule allows chains that don't include initializing a variable in a declaration or initializing a class field. Default is `false`. - -#### ignoreNonDeclaration - -Examples of **correct** code for the `{ "ignoreNonDeclaration": true }` option: - -```js -let a; -let b; -a = b = "baz"; - -const x = {}; -const y = {}; -x.one = y.one = 1; -``` - -Examples of **incorrect** code for the `{ "ignoreNonDeclaration": true }` option: - -```js -let a = b = "baz"; - -const foo = bar = 1; - -class Foo { - a = b = 10; -} -``` - -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny no-multi-assign -``` - -```json [Config (.oxlintrc.json)] -{ - "rules": { - "no-multi-assign": "error" - } -} -``` - -::: - -## References - -- Rule Source diff --git a/src/docs/guide/usage/linter/rules/eslint/no-multi-str.md b/src/docs/guide/usage/linter/rules/eslint/no-multi-str.md index ae611a55cd9..9f8a8485324 100644 --- a/src/docs/guide/usage/linter/rules/eslint/no-multi-str.md +++ b/src/docs/guide/usage/linter/rules/eslint/no-multi-str.md @@ -1,10 +1,5 @@ - - # eslint/no-multi-str
@@ -19,35 +14,14 @@ Disallow multiline strings. Some consider this to be a bad practice as it was an undocumented feature of JavaScript that was only formalized later. -### Examples - -Examples of **incorrect** code for this rule: +### Example ```javascript -var x = "Line 1 \ +var x = + "Line 1 \ Line 2"; ``` -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny no-multi-str -``` - -```json [Config (.oxlintrc.json)] -{ - "rules": { - "no-multi-str": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/eslint/no_multi_str.rs) diff --git a/src/docs/guide/usage/linter/rules/eslint/no-negated-condition.md b/src/docs/guide/usage/linter/rules/eslint/no-negated-condition.md deleted file mode 100644 index 79cee9bcaf4..00000000000 --- a/src/docs/guide/usage/linter/rules/eslint/no-negated-condition.md +++ /dev/null @@ -1,72 +0,0 @@ - - - - -# eslint/no-negated-condition - -
- -🚧 An auto-fix is still under development. - -
- -### What it does - -Disallow negated conditions. - -### Why is this bad? - -Negated conditions are more difficult to understand. Code can be made more readable by inverting the condition. - -### Examples - -Examples of **incorrect** code for this rule: - -```javascript -if (!a) { - doSomethingC(); -} else { - doSomethingB(); -} - -!a ? doSomethingC() : doSomethingB(); -``` - -Examples of **correct** code for this rule: - -```javascript -if (a) { - doSomethingB(); -} else { - doSomethingC(); -} - -a ? doSomethingB() : doSomethingC(); -``` - -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny no-negated-condition -``` - -```json [Config (.oxlintrc.json)] -{ - "rules": { - "no-negated-condition": "error" - } -} -``` - -::: - -## References - -- Rule Source diff --git a/src/docs/guide/usage/linter/rules/eslint/no-nested-ternary.md b/src/docs/guide/usage/linter/rules/eslint/no-nested-ternary.md deleted file mode 100644 index 26076cdec14..00000000000 --- a/src/docs/guide/usage/linter/rules/eslint/no-nested-ternary.md +++ /dev/null @@ -1,62 +0,0 @@ - - - - -# eslint/no-nested-ternary - -
-
- -### What it does - -Disallows nested ternary expressions to improve code readability and maintainability. - -### Why is this bad? - -Nested ternary expressions make code harder to read and understand. They can lead to complex, difficult-to-debug logic. - -### Examples - -Examples of **incorrect** code for this rule: - -```js -const result = condition1 ? (condition2 ? "a" : "b") : "c"; -``` - -Examples of **correct** code for this rule: - -```js -let result; -if (condition1) { - result = condition2 ? "a" : "b"; -} else { - result = "c"; -} -``` - -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny no-nested-ternary -``` - -```json [Config (.oxlintrc.json)] -{ - "rules": { - "no-nested-ternary": "error" - } -} -``` - -::: - -## References - -- Rule Source diff --git a/src/docs/guide/usage/linter/rules/eslint/no-new-func.md b/src/docs/guide/usage/linter/rules/eslint/no-new-func.md index 1e9beb1c37c..2394b82e685 100644 --- a/src/docs/guide/usage/linter/rules/eslint/no-new-func.md +++ b/src/docs/guide/usage/linter/rules/eslint/no-new-func.md @@ -1,10 +1,5 @@ - - # eslint/no-new-func
@@ -34,31 +29,11 @@ var f = Function.bind(null, "a", "b", "return a + b"); Examples of **correct** code for this rule: ```js -let x = function(a, b) { +let x = function (a, b) { return a + b; }; ``` -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny no-new-func -``` - -```json [Config (.oxlintrc.json)] -{ - "rules": { - "no-new-func": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/eslint/no_new_func.rs) diff --git a/src/docs/guide/usage/linter/rules/eslint/no-new-native-nonconstructor.md b/src/docs/guide/usage/linter/rules/eslint/no-new-native-nonconstructor.md index 5fa706ffc55..1ed0cb183ef 100644 --- a/src/docs/guide/usage/linter/rules/eslint/no-new-native-nonconstructor.md +++ b/src/docs/guide/usage/linter/rules/eslint/no-new-native-nonconstructor.md @@ -1,10 +1,5 @@ - - # eslint/no-new-native-nonconstructor
@@ -23,7 +18,7 @@ Both `new Symbol` and `new BigInt` throw a type error because they are functions and not classes. It is easy to make this mistake by assuming the uppercase letters indicate classes. -### Examples +### Example Examples of **incorrect** code for this rule: @@ -43,26 +38,6 @@ let foo = Symbol("foo"); let result = BigInt(9007199254740991); ``` -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny no-new-native-nonconstructor -``` - -```json [Config (.oxlintrc.json)] -{ - "rules": { - "no-new-native-nonconstructor": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/eslint/no_new_native_nonconstructor.rs) diff --git a/src/docs/guide/usage/linter/rules/eslint/no-new-wrappers.md b/src/docs/guide/usage/linter/rules/eslint/no-new-wrappers.md index 4e32af525af..a552c4b7ee6 100644 --- a/src/docs/guide/usage/linter/rules/eslint/no-new-wrappers.md +++ b/src/docs/guide/usage/linter/rules/eslint/no-new-wrappers.md @@ -1,15 +1,10 @@ - - # eslint/no-new-wrappers
-πŸ› οΈ An auto-fix is available for this rule. +🚧 An auto-fix is still under development.
@@ -27,7 +22,7 @@ always resolves to `true` even when its actual value is `false`. https://eslint.org/docs/latest/rules/no-new-wrappers -### Examples +### Example Examples of **incorrect** code for this rule: @@ -35,7 +30,6 @@ Examples of **incorrect** code for this rule: var stringObject = new String("Hello world"); var numberObject = new Number(33); var booleanObject = new Boolean(false); -var symbolObject = new Symbol("foo"); // symbol is not a constructor ``` Examples of **correct** code for this rule: @@ -45,29 +39,8 @@ var stringObject = "Hello world"; var stringObject2 = String(value); var numberObject = Number(value); var booleanObject = Boolean(value); -var symbolObject = Symbol("foo"); ``` -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny no-new-wrappers -``` - -```json [Config (.oxlintrc.json)] -{ - "rules": { - "no-new-wrappers": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/eslint/no_new_wrappers.rs) diff --git a/src/docs/guide/usage/linter/rules/eslint/no-new.md b/src/docs/guide/usage/linter/rules/eslint/no-new.md index e7f9de7c68e..206c38832a8 100644 --- a/src/docs/guide/usage/linter/rules/eslint/no-new.md +++ b/src/docs/guide/usage/linter/rules/eslint/no-new.md @@ -1,10 +1,5 @@ - - # eslint/no-new
@@ -19,44 +14,12 @@ Disallow new operators outside of assignments or comparisons. Calling new without assigning or comparing it the reference is thrown away and in many cases the constructor can be replaced with a function. -### Examples - -Examples of **incorrect** code for this rule: +### Example ```javascript new Person(); - -(() => { - new Date(); -}); -``` - -Examples of **correct** code for this rule: - -```javascript -var a = new Date()(() => new Date()); ``` -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny no-new -``` - -```json [Config (.oxlintrc.json)] -{ - "rules": { - "no-new": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/eslint/no_new.rs) diff --git a/src/docs/guide/usage/linter/rules/eslint/no-nonoctal-decimal-escape.md b/src/docs/guide/usage/linter/rules/eslint/no-nonoctal-decimal-escape.md index 8cb135d0a61..175523dbef4 100644 --- a/src/docs/guide/usage/linter/rules/eslint/no-nonoctal-decimal-escape.md +++ b/src/docs/guide/usage/linter/rules/eslint/no-nonoctal-decimal-escape.md @@ -1,10 +1,5 @@ - - # eslint/no-nonoctal-decimal-escape
@@ -24,42 +19,15 @@ This rule disallows \8 and \9 escape sequences in string literals ECMAScript specification treats \8 and \9 in string literals as a legacy feature -### Examples - -Examples of **incorrect** code for this rule: +### Example ```javascript -let x = "\8"; -let y = "\9"; -``` - -Examples of **correct** code for this rule: - -```javascript -let x = "8"; -let y = "\\9"; -``` - -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny no-nonoctal-decimal-escape +incorrect: "\8"; +("\9"); +correct: "8"; +("\\9"); ``` -```json [Config (.oxlintrc.json)] -{ - "rules": { - "no-nonoctal-decimal-escape": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/eslint/no_nonoctal_decimal_escape.rs) diff --git a/src/docs/guide/usage/linter/rules/eslint/no-obj-calls.md b/src/docs/guide/usage/linter/rules/eslint/no-obj-calls.md index 8a1a30c2166..065dcd8cc18 100644 --- a/src/docs/guide/usage/linter/rules/eslint/no-obj-calls.md +++ b/src/docs/guide/usage/linter/rules/eslint/no-obj-calls.md @@ -1,10 +1,5 @@ - - # eslint/no-obj-calls
@@ -22,7 +17,7 @@ Disallow calling some global objects as functions Some global objects are not intended to be called as functions. Calling them as functions will usually result in a TypeError being thrown. -### Examples +### Example Examples of **incorrect** code for this rule: @@ -46,32 +41,12 @@ let newReflect = new Reflect(); Examples of **correct** code for this rule: ```javascript -let area = r => 2 * Math.PI * r * r; +let area = (r) => 2 * Math.PI * r * r; let object = JSON.parse("{}"); let first = Atomics.load(sharedArray, 0); let segmenterFrom = Intl.Segmenter("fr", { granularity: "word" }); ``` -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny no-obj-calls -``` - -```json [Config (.oxlintrc.json)] -{ - "rules": { - "no-obj-calls": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/eslint/no_obj_calls.rs) diff --git a/src/docs/guide/usage/linter/rules/eslint/no-object-constructor.md b/src/docs/guide/usage/linter/rules/eslint/no-object-constructor.md index 42757f771a3..ac8ec854190 100644 --- a/src/docs/guide/usage/linter/rules/eslint/no-object-constructor.md +++ b/src/docs/guide/usage/linter/rules/eslint/no-object-constructor.md @@ -1,10 +1,5 @@ - - # eslint/no-object-constructor
@@ -35,30 +30,10 @@ Examples of **correct** code for this rule: ```js Object("foo"); const obj = { a: 1, b: 2 }; -const isObject = value => value === Object(value); -const createObject = Object => new Object(); +const isObject = (value) => value === Object(value); +const createObject = (Object) => new Object(); ``` -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny no-object-constructor -``` - -```json [Config (.oxlintrc.json)] -{ - "rules": { - "no-object-constructor": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/eslint/no_object_constructor.rs) diff --git a/src/docs/guide/usage/linter/rules/eslint/no-param-reassign.md b/src/docs/guide/usage/linter/rules/eslint/no-param-reassign.md deleted file mode 100644 index 58b9761b900..00000000000 --- a/src/docs/guide/usage/linter/rules/eslint/no-param-reassign.md +++ /dev/null @@ -1,85 +0,0 @@ - - - - -# eslint/no-param-reassign - -
-
- -### What it does - -Disallow reassigning function parameters or, optionally, their properties. - -### Why is this bad? - -Reassigning parameters can lead to unexpected behavior, especially when relying on the -original arguments passed into the function. Mutating parameter properties can be similarly -surprising and harder to reason about. - -### Examples - -```javascript -function foo(bar) { - bar = 1; -} - -function baz(qux) { - qux.prop = 2; // when `props` option is enabled -} -``` - -## Configuration - -This rule accepts a configuration object with the following properties: - -### ignorePropertyModificationsFor - -type: `string[]` - -default: `[]` - -An array of parameter names whose property modifications should be ignored. - -### ignorePropertyModificationsForRegex - -type: `string[]` - -An array of regex patterns (as strings) for parameter names whose property modifications should be ignored. -Note that this uses [Rust regex syntax](https://docs.rs/regex/latest/regex/) and so may not have all features -available to JavaScript regexes. - -### props - -type: `boolean` - -default: `false` - -When true, also check for modifications to properties of parameters. - -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny no-param-reassign -``` - -```json [Config (.oxlintrc.json)] -{ - "rules": { - "no-param-reassign": "error" - } -} -``` - -::: - -## References - -- Rule Source diff --git a/src/docs/guide/usage/linter/rules/eslint/no-plusplus.md b/src/docs/guide/usage/linter/rules/eslint/no-plusplus.md index 890a20dbfb4..90f06a732e1 100644 --- a/src/docs/guide/usage/linter/rules/eslint/no-plusplus.md +++ b/src/docs/guide/usage/linter/rules/eslint/no-plusplus.md @@ -1,10 +1,5 @@ - - # eslint/no-plusplus
@@ -15,7 +10,7 @@ const source = `https://github.com/oxc-project/oxc/blob/${ data }/crates/oxc_lin ### What it does -Disallow the unary operators `++` and `--`. +Disallow the unary operators `++`` and `--`. ### Why is this bad? @@ -66,38 +61,6 @@ for (let i = 0; i < l; i += 1) { } ``` -## Configuration - -This rule accepts a configuration object with the following properties: - -### allowForLoopAfterthoughts - -type: `boolean` - -default: `false` - -Whether to allow `++` and `--` in for loop afterthoughts. - -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny no-plusplus -``` - -```json [Config (.oxlintrc.json)] -{ - "rules": { - "no-plusplus": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/eslint/no_plusplus.rs) diff --git a/src/docs/guide/usage/linter/rules/eslint/no-proto.md b/src/docs/guide/usage/linter/rules/eslint/no-proto.md index e5ab268bf86..035fdc222bf 100644 --- a/src/docs/guide/usage/linter/rules/eslint/no-proto.md +++ b/src/docs/guide/usage/linter/rules/eslint/no-proto.md @@ -1,10 +1,5 @@ - - # eslint/no-proto
@@ -23,9 +18,7 @@ The `__proto__` property has been deprecated as of ECMAScript 3.1 and shouldn’t be used in new code. Use `Object.getPrototypeOf` and `Object.setPrototypeOf` instead. -### Examples - -Examples of **incorrect** code for this rule: +### Example ```javascript /*eslint no-proto: "error"*/ @@ -39,26 +32,6 @@ obj.__proto__ = b; obj["__proto__"] = b; ``` -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny no-proto -``` - -```json [Config (.oxlintrc.json)] -{ - "rules": { - "no-proto": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/eslint/no_proto.rs) diff --git a/src/docs/guide/usage/linter/rules/eslint/no-prototype-builtins.md b/src/docs/guide/usage/linter/rules/eslint/no-prototype-builtins.md index 4163a11490e..13788dabdce 100644 --- a/src/docs/guide/usage/linter/rules/eslint/no-prototype-builtins.md +++ b/src/docs/guide/usage/linter/rules/eslint/no-prototype-builtins.md @@ -1,10 +1,5 @@ - - # eslint/no-prototype-builtins
@@ -24,9 +19,7 @@ For example, it would be unsafe for a webserver to parse JSON input from a clien To avoid subtle bugs like this, it’s better to always call these methods from Object.prototype. For example, foo.hasOwnProperty("bar") should be replaced with Object.prototype.hasOwnProperty.call(foo, "bar"). -### Examples - -Examples of **incorrect** code for this rule: +### Example ```javascript var hasBarProperty = foo.hasOwnProperty("bar"); @@ -34,26 +27,6 @@ var isPrototypeOfBar = foo.isPrototypeOf(bar); var barIsEnumerable = foo.propertyIsEnumerable("bar"); ``` -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny no-prototype-builtins -``` - -```json [Config (.oxlintrc.json)] -{ - "rules": { - "no-prototype-builtins": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/eslint/no_prototype_builtins.rs) diff --git a/src/docs/guide/usage/linter/rules/eslint/no-redeclare.md b/src/docs/guide/usage/linter/rules/eslint/no-redeclare.md index 2ab1ef37be3..1ee5e0ebe2f 100644 --- a/src/docs/guide/usage/linter/rules/eslint/no-redeclare.md +++ b/src/docs/guide/usage/linter/rules/eslint/no-redeclare.md @@ -1,10 +1,5 @@ - - # eslint/no-redeclare
@@ -12,58 +7,19 @@ const source = `https://github.com/oxc-project/oxc/blob/${ data }/crates/oxc_lin ### What it does -This rule disallows redeclaring variables within the same scope, ensuring that each variable -is declared only once. It helps avoid confusion and unintended behavior in code. +Disallow variable redeclaration ### Why is this bad? -Redeclaring variables in the same scope can lead to unexpected behavior, overwriting existing values, -and making the code harder to understand and maintain. - -### Examples +n JavaScript, it’s possible to redeclare the same variable name using var. This can lead to confusion as to where the variable is actually declared and initialized. -Examples of **incorrect** code for this rule: +### Example ```javascript var a = 3; var a = 10; ``` -Examples of **correct** code for this rule: - -```javascript -var a = 3; -a = 10; -``` - -### Options - -#### builtinGlobals - -`{ type: bool, default: true }` - -When set `true`, it flags redeclaring built-in globals (e.g., `let Object = 1;`). - -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny no-redeclare -``` - -```json [Config (.oxlintrc.json)] -{ - "rules": { - "no-redeclare": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/eslint/no_redeclare.rs) diff --git a/src/docs/guide/usage/linter/rules/eslint/no-regex-spaces.md b/src/docs/guide/usage/linter/rules/eslint/no-regex-spaces.md index b74f4daef2b..7039d3765e6 100644 --- a/src/docs/guide/usage/linter/rules/eslint/no-regex-spaces.md +++ b/src/docs/guide/usage/linter/rules/eslint/no-regex-spaces.md @@ -1,10 +1,5 @@ - - # eslint/no-regex-spaces
@@ -27,34 +22,12 @@ then specify how many spaces are expected using a quantifier. var re = /foo {3}bar/; ``` -### Examples - -Examples of **incorrect** code for this rule: +### Example ```javascript var re = /foo bar/; ``` -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny no-regex-spaces -``` - -```json [Config (.oxlintrc.json)] -{ - "rules": { - "no-regex-spaces": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/eslint/no_regex_spaces.rs) diff --git a/src/docs/guide/usage/linter/rules/eslint/no-restricted-globals.md b/src/docs/guide/usage/linter/rules/eslint/no-restricted-globals.md index e51a06d80d0..4cd6112444a 100644 --- a/src/docs/guide/usage/linter/rules/eslint/no-restricted-globals.md +++ b/src/docs/guide/usage/linter/rules/eslint/no-restricted-globals.md @@ -1,10 +1,5 @@ - - # eslint/no-restricted-globals
@@ -39,26 +34,6 @@ function onClick() { } ``` -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny no-restricted-globals -``` - -```json [Config (.oxlintrc.json)] -{ - "rules": { - "no-restricted-globals": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/eslint/no_restricted_globals.rs) diff --git a/src/docs/guide/usage/linter/rules/eslint/no-restricted-imports.md b/src/docs/guide/usage/linter/rules/eslint/no-restricted-imports.md index dcb139afe02..ae380e07be4 100644 --- a/src/docs/guide/usage/linter/rules/eslint/no-restricted-imports.md +++ b/src/docs/guide/usage/linter/rules/eslint/no-restricted-imports.md @@ -1,11 +1,6 @@ - - -# eslint/no-restricted-imports +# eslint/no-restricted-imports
@@ -17,345 +12,32 @@ It applies to static imports only, not dynamic ones. ### Why is this bad? -Some imports might not make sense in a particular environment. -For example, Node.js’ fs module would not make sense in an environment that didn’t have a file system. +Some imports might not make sense in a particular environment. For example, Node.js’ fs module would not make sense in an environment that didn’t have a file system. -Some modules provide similar or identical functionality, think lodash and underscore. Your project may have standardized on a module. -You want to make sure that the other alternatives are not being used as this would unnecessarily bloat the project -and provide a higher maintenance cost of two dependencies when one would suffice. +Some modules provide similar or identical functionality, think lodash and underscore. Your project may have standardized on a module. You want to make sure that the other alternatives are not being used as this would unnecessarily bloat the project and provide a higher maintenance cost of two dependencies when one would suffice. ### Examples Examples of **incorrect** code for this rule: -```js -/*eslint no-restricted-imports: ["error", "disallowed-import"]"*/ - -import foo from "disallowed-import"; -export * from "disallowed-import"; -``` - -Examples of **correct** code for this rule: - -```js -/*eslint no-restricted-imports: ["error", "fs"]*/ - -import crypto from "crypto"; -export * from "bar"; -``` - -### Options - -You may also specify a custom message for a particular module using the `name` and `message` properties inside an object, -where the value of the name is the `name` of the module and message property contains the custom message. -The custom message will be displayed as a help text for the user. - -Examples of **incorrect** code for this rule: - ```js /*eslint no-restricted-imports: ["error", { - "name": "disallowed-import", - "message": "Please use 'allowed-import' instead" + "name": "disallowed-import", + "message": "Please use 'allowed-import' instead" }]*/ import foo from "disallowed-import"; ``` -#### paths - -This is an object option whose value is an array containing the names of the modules you want to restrict. - -```json -{"rules: {"no-restricted-imports": ["error", { "paths": ["import1", "import2"] }]}} -``` - -Examples of **incorrect** code for `paths`: - -```js -/*eslint no-restricted-imports: ["error", { "paths": ["cluster"] }]*/ - -import cluster from "cluster"; -``` - -Custom messages for a particular module can also be specified in `paths` array using objects with `name` and `message`. - -```json -"no-restricted-imports": ["error", { - "paths": [{ - "name": "import-foo", - "message": "Please use import-bar instead." - }, { - "name": "import-baz", - "message": "Please use import-quux instead." - }] -}] -``` - -##### importNames - -This option in `paths` is an array and can be used to specify the names of certain bindings exported from a module. -Import names specified inside `paths` array affect the module specified in the `name` property of corresponding object, -so it is required to specify the `name` property first when you are using `importNames` or `message` option. - -Specifying `"default"` string inside the `importNames` array will restrict the default export from being imported. - -Examples of **incorrect** code for this rule: - -```js -/*eslint no-restricted-imports: ["error", { paths: [{ - "name": "foo", - "importNames": ["default"] -}, { - "name": "bar", - "importNames": ["Baz"] -}]}]*/ - -import { Baz } from "far"; -import DisallowedObject from "foo"; -``` - -##### allowImportNames - -This option is an array. Inverse of `importNames`, `allowImportNames` allows the imports that are specified inside this array. -So it restricts all imports from a module, except specified allowed ones. - -Note: `allowImportNames` cannot be used in combination with `importNames`. - -Examples of **incorrect** code for this rule: - -```js -/*eslint no-restricted-imports: ["error", { paths: [{ - "name": "foo", - "allowImportNames": ["AllowedObject"], - "message": "Please use only 'AllowedObject' from 'foo'." -}]}]*/ - -import { DisallowedObject } from "foo"; -``` - -#### allowTypeImports - -Whether to allow type-only imports for a path. Default: `false`. - -Examples of **incorrect** code for this rule: - -```typescript -/*eslint no-restricted-imports: ["error", { paths: [{ - "name": "foo", - "allowTypeImports": true -}]}]*/ - -import foo from "import-foo"; -export { Foo } from "import-foo"; -``` - Examples of **correct** code for this rule: -```typescript -/*eslint no-restricted-imports: ["error", { paths: [{ - "name": "foo", - "allowTypeImports": true -}]}]*/ - -import type foo from "import-foo"; -export type { Foo } from "import-foo"; -``` - -#### patterns - -This is also an object option whose value is an array. -This option allows you to specify multiple modules to restrict using `gitignore`-style patterns or regular expressions. - -Where `paths` option takes exact import paths, `patterns` option can be used to specify the import paths with more flexibility, -allowing for the restriction of multiple modules within the same directory. For example: - -```json -"no-restricted-imports": ["error", { - "paths": [{ - "name": "import-foo", - }] -}] -``` - -This configuration restricts import of the `import-foo` module -but wouldn’t restrict the import of `import-foo/bar` or `import-foo/baz`. You can use `patterns` to restrict both: - -```json -"no-restricted-imports": ["error", { - "paths": [{ - "name": "import-foo", - }], - "patterns": [{ - "group": ["import-foo/ba*"], - }] -}] -``` - -This configuration restricts imports not just from `import-foo` using path, -but also `import-foo/bar` and `import-foo/baz` using `patterns`. - -You can also use regular expressions to restrict modules (see the `regex` option). - -Examples of **incorrect** code for `patterns` option: - ```js -/*eslint no-restricted-imports: ["error", { "patterns": ["lodash/*"] }]*/ - -import pick from "lodash/pick"; -``` - -Examples of **correct** code for `patterns` option: - -```js -/*eslint no-restricted-imports: ["error", { "patterns": ["crypto/*"] }]*/ +/*eslint no-restricted-imports: ["error", {"name": "fs"}]*/ import crypto from "crypto"; +export { foo } from "bar"; ``` -##### group - -The `patterns` array can also include objects. The `group` property is used to specify the `gitignore`-style patterns -for restricting modules and the `message` property is used to specify a custom message. - -Either of the `group` or `regex` properties is required when using the `patterns` option. - -Examples of **incorrect** code for `group` option: - -```js -/*eslint no-restricted-imports: ["error", { patterns: [{ - group: ["lodash/*"], - message: "Please use the default import from 'lodash' instead." -}]}]*/ - -import pick from "lodash/pick"; -``` - -##### regex - -The `regex` property is used to specify the regex patterns for restricting modules. - -Note: `regex` cannot be used in combination with `group`. - -**Warning**: This rule uses the [Rust-Regex](https://docs.rs/regex/latest/regex/), which supports not all features of JS-Regex, -like Lookahead and Lookbehinds. - -Examples of **incorrect** code for `regex` option: - -```js -/*eslint no-restricted-imports: ["error", { patterns: [{ - regex: "@app/(api|enums).*", -}]}]*/ - -import Foo from "@app/api"; -import Bar from "@app/api/bar"; -import Baz from "@app/api/baz"; -import Bux from "@app/api/enums/foo"; -``` - -##### caseSensitive - -This is a boolean option and sets the patterns specified in the `group` property to be case-sensitive when `true`. Default is `false`. - -**Warning**: It will not apply case-sensitive checks to `regex`. `regex` uses Rust-RegEx which has its own implementation of case-sensitive. - -##### importNames - -You can also specify `importNames` within objects inside the `patterns` array. -In this case, the specified names apply only to the associated `group` or `regex` property. - -Examples of **incorrect** code for `importNames` in `patterns`: - -```js -/*eslint no-restricted-imports: ["error", { patterns: [{ - group: ["utils/*"], - importNames: ['isEmpty'], - message: "Use 'isEmpty' from lodash instead." -}]}]*/ - -import { isEmpty } from "utils/collection-utils"; -``` - -##### allowImportNames - -You can also specify `allowImportNames` within objects inside the `patterns` array. -In this case, the specified names apply only to the associated `group` or `regex` property. - -Note: `allowImportNames` cannot be used in combination with `importNames`, `importNamePattern` or `allowImportNamePattern`. - -##### importNamePattern - -This option allows you to use regex patterns to restrict import names. - -Examples of **incorrect** code for `importNamePattern` option: - -```js -/*eslint no-restricted-imports: ["error", { patterns: [{ - group: ["foo/*"], - importNamePattern: '^(is|has)', - message: "Use 'is*' and 'has*' functions from baz/bar instead" -}]}]*/ - -import { hasSomething, isSomething } from "foo/bar"; -``` - -##### allowImportNamePattern - -This is a string option. Inverse of `importNamePattern`, this option allows imports that matches the specified regex pattern. -So it restricts all imports from a module, except specified allowed patterns. - -Note: `allowImportNamePattern` cannot be used in combination with `importNames`, `importNamePattern` or `allowImportNames`. - -```json -"no-restricted-imports": ["error", { - "patterns": [{ - "group": ["import-foo/*"], - "allowImportNamePattern": "^foo", - }] -}] -``` - -Examples of **incorrect** code for `allowImportNamePattern` option: - -```js -/*eslint no-restricted-imports: ["error", { patterns: [{ - group: ["utils/*"], - allowImportNamePattern: '^has' -}]}]*/ - -import { isEmpty } from "utils/collection-utils"; -``` - -Examples of **correct** code for `allowImportNamePattern` option: - -```js -/*eslint no-restricted-imports: ["error", { patterns: [{ - group: ["utils/*"], - allowImportNamePattern: '^is' -}]}]*/ - -import { isEmpty } from "utils/collection-utils"; -``` - -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny no-restricted-imports -``` - -```json [Config (.oxlintrc.json)] -{ - "rules": { - "no-restricted-imports": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/eslint/no_restricted_imports.rs) diff --git a/src/docs/guide/usage/linter/rules/eslint/no-return-assign.md b/src/docs/guide/usage/linter/rules/eslint/no-return-assign.md index 282c883892b..51dd7ac2908 100644 --- a/src/docs/guide/usage/linter/rules/eslint/no-return-assign.md +++ b/src/docs/guide/usage/linter/rules/eslint/no-return-assign.md @@ -1,10 +1,5 @@ - - # eslint/no-return-assign
@@ -28,42 +23,22 @@ Because of this ambiguity, it’s considered a best practice to not use assignme Examples of **incorrect** code for this rule: ```js -(() => a = b); +() => (a = b); function x() { - return a = b; + return (a = b); } ``` Examples of **correct** code for this rule: ```js -(() => (a = b)); +() => (a = b); function x() { - var result = a = b; + var result = (a = b); return result; } ``` -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny no-return-assign -``` - -```json [Config (.oxlintrc.json)] -{ - "rules": { - "no-return-assign": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/eslint/no_return_assign.rs) diff --git a/src/docs/guide/usage/linter/rules/eslint/no-script-url.md b/src/docs/guide/usage/linter/rules/eslint/no-script-url.md index eb0f44566a4..d0ef503b1fe 100644 --- a/src/docs/guide/usage/linter/rules/eslint/no-script-url.md +++ b/src/docs/guide/usage/linter/rules/eslint/no-script-url.md @@ -1,10 +1,5 @@ - - # eslint/no-script-url
@@ -33,26 +28,6 @@ location.href = "javascript:void(0)"; location.href = `javascript:void(0)`; ``` -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny no-script-url -``` - -```json [Config (.oxlintrc.json)] -{ - "rules": { - "no-script-url": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/eslint/no_script_url.rs) diff --git a/src/docs/guide/usage/linter/rules/eslint/no-self-assign.md b/src/docs/guide/usage/linter/rules/eslint/no-self-assign.md index d027c99c1a2..1cc8a024058 100644 --- a/src/docs/guide/usage/linter/rules/eslint/no-self-assign.md +++ b/src/docs/guide/usage/linter/rules/eslint/no-self-assign.md @@ -1,10 +1,5 @@ - - # eslint/no-self-assign
@@ -15,95 +10,19 @@ const source = `https://github.com/oxc-project/oxc/blob/${ data }/crates/oxc_lin ### What it does -Disallow assignments where both sides are exactly the same. +Disallow assignments where both sides are exactly the same ### Why is this bad? -Self assignments have no effect, so probably those are an error due to incomplete -refactoring. Those indicate that what you should do is still remaining. - -### Examples +Self assignments have no effect, so probably those are an error due to incomplete refactoring. Those indicate that what you should do is still remaining. -Examples of **incorrect** code for this rule: +### Example ```javascript foo = foo; - -[a, b] = [a, b]; -[a, ...b] = [x, ...b]; - -({ a, b } = { a, x }); - -foo &&= foo; -foo ||= foo; -foo ??= foo; -``` - -```javascript -obj.a = obj.a; -obj.a.b = obj.a.b; -obj["a"] = obj["a"]; -obj[a] = obj[a]; -``` - -Examples of **correct** code for this rule: - -```javascript -foo = bar; -[a, b] = [b, a]; - -// This pattern is warned by the `no-use-before-define` rule. -let foo = foo; - -// The default values have an effect. -[foo = 1] = [foo]; - -// This ignores if there is a function call. -obj.a().b = obj.a().b; -a().b = a().b; - -// `&=` and `|=` have an effect on non-integers. -foo &= foo; -foo |= foo; +[bar, baz] = [bar, qiz]; ``` -### Options - -#### props - -`{ type: boolean, default: true }` - -The `props` option when set to `false`, disables the checking of properties. - -With `props` set to `false` the following are examples of correct code: - -```javascript -obj.a = obj.a; -obj.a.b = obj.a.b; -obj["a"] = obj["a"]; -obj[a] = obj[a]; -``` - -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny no-self-assign -``` - -```json [Config (.oxlintrc.json)] -{ - "rules": { - "no-self-assign": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/eslint/no_self_assign.rs) diff --git a/src/docs/guide/usage/linter/rules/eslint/no-self-compare.md b/src/docs/guide/usage/linter/rules/eslint/no-self-compare.md index b3a5ccda09f..9650912743a 100644 --- a/src/docs/guide/usage/linter/rules/eslint/no-self-compare.md +++ b/src/docs/guide/usage/linter/rules/eslint/no-self-compare.md @@ -1,10 +1,5 @@ - - # eslint/no-self-compare
@@ -19,7 +14,7 @@ Disallow comparisons where both sides are exactly the same Comparing a variable against itself is usually an error, either a typo or refactoring error. It is confusing to the reader and may potentially introduce a runtime error. -### Examples +### Example Examples of **incorrect** code for this rule: @@ -30,26 +25,6 @@ if (x === x) { } ``` -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny no-self-compare -``` - -```json [Config (.oxlintrc.json)] -{ - "rules": { - "no-self-compare": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/eslint/no_self_compare.rs) diff --git a/src/docs/guide/usage/linter/rules/eslint/no-setter-return.md b/src/docs/guide/usage/linter/rules/eslint/no-setter-return.md index 36b114c0602..5cd56f45d9b 100644 --- a/src/docs/guide/usage/linter/rules/eslint/no-setter-return.md +++ b/src/docs/guide/usage/linter/rules/eslint/no-setter-return.md @@ -1,10 +1,5 @@ - - # eslint/no-setter-return
@@ -23,9 +18,7 @@ While returning a value from a setter does not produce an error, the returned va being ignored. Therefore, returning a value from a setter is either unnecessary or a possible error, since the returned value cannot be used. -### Examples - -Examples of **incorrect** code for this rule: +### Example ```javascript class URL { @@ -35,26 +28,6 @@ class URL { } ``` -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny no-setter-return -``` - -```json [Config (.oxlintrc.json)] -{ - "rules": { - "no-setter-return": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/eslint/no_setter_return.rs) diff --git a/src/docs/guide/usage/linter/rules/eslint/no-shadow-restricted-names.md b/src/docs/guide/usage/linter/rules/eslint/no-shadow-restricted-names.md index 16861ba7973..6eaf8dc6857 100644 --- a/src/docs/guide/usage/linter/rules/eslint/no-shadow-restricted-names.md +++ b/src/docs/guide/usage/linter/rules/eslint/no-shadow-restricted-names.md @@ -1,10 +1,5 @@ - - # eslint/no-shadow-restricted-names
@@ -15,32 +10,16 @@ const source = `https://github.com/oxc-project/oxc/blob/${ data }/crates/oxc_lin ### What it does -Disallows the redefining of global variables such as `undefined`, `NaN`, `Infinity`, -`eval`, and `arguments`. +Disallow redefine the global variables like 'undefined', 'NaN', 'Infinity', 'eval', 'arguments'. ### Why is this bad? -Value properties of the Global Object `NaN`, `Infinity`, `undefined` as well as the strict -mode restricted identifiers `eval` and `arguments` are considered to be restricted names in -JavaScript. Defining them to mean something else can have unintended consequences and -confuse others reading the code. For example, there’s nothing preventing you from -writing: - -```javascript -var undefined = "foo"; -``` - -Then any code used within the same scope would not get the global undefined, but rather the -local version with a very different meaning. - -### Examples - -Examples of **incorrect** code for this rule: +### Example ```javascript function NaN() {} -!function(Infinity) {}; +!function (Infinity) {}; var undefined = 5; @@ -48,61 +27,6 @@ try { } catch (eval) {} ``` -```javascript -import NaN from "foo"; - -import { undefined } from "bar"; - -class Infinity {} -``` - -Examples of **correct** code for this rule: - -```javascript -var Object; - -function f(a, b) {} - -// Exception: `undefined` may be shadowed if the variable is never assigned a value. -var undefined; -``` - -```javascript -import { undefined as undef } from "bar"; -``` - -## Configuration - -This rule accepts a configuration object with the following properties: - -### reportGlobalThis - -type: `boolean` - -default: `false` - -If true, also report shadowing of `globalThis`. - -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny no-shadow-restricted-names -``` - -```json [Config (.oxlintrc.json)] -{ - "rules": { - "no-shadow-restricted-names": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/eslint/no_shadow_restricted_names.rs) diff --git a/src/docs/guide/usage/linter/rules/eslint/no-sparse-arrays.md b/src/docs/guide/usage/linter/rules/eslint/no-sparse-arrays.md index a090703c57b..d0038fdc03f 100644 --- a/src/docs/guide/usage/linter/rules/eslint/no-sparse-arrays.md +++ b/src/docs/guide/usage/linter/rules/eslint/no-sparse-arrays.md @@ -1,10 +1,5 @@ - - # eslint/no-sparse-arrays
@@ -19,66 +14,15 @@ Disallow sparse arrays. ### Why is this bad? -Take the following example: - -```javascript -const items = [, ,]; -``` - -While the items array in this example has a length of 2, there are actually -no values in items[0] or items[1]. The fact that the array literal is -valid with only commas inside, coupled with the length being set and -actual item values not being set, make sparse arrays confusing for many -developers. - -The confusion around sparse arrays is enough that it’s recommended to -avoid using them unless you are certain that they are useful in your -code. - -### Examples +The confusion around sparse arrays is enough that it’s recommended to avoid using them unless you are certain that they are useful in your code. -Examples of **incorrect** code for this rule: +### Example ```javascript var items = [, ,]; -``` - -```javascript var colors = ["red", , "blue"]; ``` -Examples of **correct** code for this rule: - -```javascript -var items = []; -``` - -// trailing comma (after the last element) is not a problem - -```javascript -var colors = ["red", "blue"]; -``` - -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny no-sparse-arrays -``` - -```json [Config (.oxlintrc.json)] -{ - "rules": { - "no-sparse-arrays": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/eslint/no_sparse_arrays.rs) diff --git a/src/docs/guide/usage/linter/rules/eslint/no-template-curly-in-string.md b/src/docs/guide/usage/linter/rules/eslint/no-template-curly-in-string.md index 5f1fd1dc3c4..94730dd954d 100644 --- a/src/docs/guide/usage/linter/rules/eslint/no-template-curly-in-string.md +++ b/src/docs/guide/usage/linter/rules/eslint/no-template-curly-in-string.md @@ -1,70 +1,38 @@ - - # eslint/no-template-curly-in-string
-βš οΈπŸ› οΈοΈ A dangerous auto-fix is available for this rule. +🚧 An auto-fix is still under development.
### What it does -Disallow template literal placeholder syntax in regular strings. This rule ensures that -expressions like `${variable}` are only used within template literals, avoiding incorrect -usage in regular strings. +Disallow template literal placeholder syntax in regular strings ### Why is this bad? -ECMAScript 6 allows programmers to create strings containing variables or expressions using -template literals. This is done by embedding expressions like `${variable}` between backticks. -If regular quotes (`'` or `"`) are used with template literal syntax, it results in the literal -string `"${variable}"` instead of evaluating the expression. This rule helps to avoid this mistake, -ensuring that expressions are correctly evaluated inside template literals. +ECMAScript 6 allows programmers to create strings containing variable or +expressions using template literals, instead of string concatenation, by +writing expressions like `${variable}` between two backtick quotes. It +can be easy to use the wrong quotes when wanting to use template +literals, by writing `"${variable}"`, and end up with the literal value +`"${variable}"` instead of a string containing the value of the injected +expressions. -### Examples +### Example Examples of **incorrect** code for this rule: ```javascript +/*eslint no-template-curly-in-string: "error"*/ "Hello ${name}!"; "Hello ${name}!"; "Time: ${12 * 60 * 60 * 1000}"; ``` -Examples of **correct** code for this rule: - -```javascript -`Hello ${name}!`; -`Time: ${12 * 60 * 60 * 1000}`; -templateFunction`Hello ${name}`; -``` - -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny no-template-curly-in-string -``` - -```json [Config (.oxlintrc.json)] -{ - "rules": { - "no-template-curly-in-string": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/eslint/no_template_curly_in_string.rs) diff --git a/src/docs/guide/usage/linter/rules/eslint/no-ternary.md b/src/docs/guide/usage/linter/rules/eslint/no-ternary.md index f91c8436fa2..900b53641e2 100644 --- a/src/docs/guide/usage/linter/rules/eslint/no-ternary.md +++ b/src/docs/guide/usage/linter/rules/eslint/no-ternary.md @@ -1,10 +1,5 @@ - - # eslint/no-ternary
@@ -16,66 +11,14 @@ Disallow ternary operators ### Why is this bad? -The ternary operator is used to conditionally assign a value to a -variable. Some believe that the use of ternary operators leads to -unclear code. - -### Examples +The ternary operator is used to conditionally assign a value to a variable. Some believe that the use of ternary operators leads to unclear code. -Examples of **incorrect** code for this rule: +### Example ```javascript var foo = isBar ? baz : qux; ``` -```javascript -function quux() { - return foo ? bar() : baz(); -} -``` - -Examples of **correct** code for this rule: - -```javascript -let foo; - -if (isBar) { - foo = baz; -} else { - foo = qux; -} -``` - -```javascript -function quux() { - if (foo) { - return bar(); - } else { - return baz(); - } -} -``` - -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny no-ternary -``` - -```json [Config (.oxlintrc.json)] -{ - "rules": { - "no-ternary": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/eslint/no_ternary.rs) diff --git a/src/docs/guide/usage/linter/rules/eslint/no-this-before-super.md b/src/docs/guide/usage/linter/rules/eslint/no-this-before-super.md index 4553220a1b2..39e205312c6 100644 --- a/src/docs/guide/usage/linter/rules/eslint/no-this-before-super.md +++ b/src/docs/guide/usage/linter/rules/eslint/no-this-before-super.md @@ -1,10 +1,5 @@ - - # eslint/no-this-before-super
@@ -22,9 +17,7 @@ Requires calling `super()` before using `this` or `super`. Getters should always return a value. If they don't, it's probably a mistake. -### Examples - -Examples of **incorrect** code for this rule: +### Example ```javascript class A1 extends B { @@ -36,26 +29,6 @@ class A1 extends B { } ``` -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny no-this-before-super -``` - -```json [Config (.oxlintrc.json)] -{ - "rules": { - "no-this-before-super": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/eslint/no_this_before_super.rs) diff --git a/src/docs/guide/usage/linter/rules/eslint/no-throw-literal.md b/src/docs/guide/usage/linter/rules/eslint/no-throw-literal.md index 2acfe769b6f..6755df33510 100644 --- a/src/docs/guide/usage/linter/rules/eslint/no-throw-literal.md +++ b/src/docs/guide/usage/linter/rules/eslint/no-throw-literal.md @@ -1,10 +1,5 @@ - - # eslint/no-throw-literal
@@ -61,26 +56,6 @@ try { } ``` -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny no-throw-literal -``` - -```json [Config (.oxlintrc.json)] -{ - "rules": { - "no-throw-literal": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/eslint/no_throw_literal.rs) diff --git a/src/docs/guide/usage/linter/rules/eslint/no-unassigned-vars.md b/src/docs/guide/usage/linter/rules/eslint/no-unassigned-vars.md deleted file mode 100644 index 8842adf87b1..00000000000 --- a/src/docs/guide/usage/linter/rules/eslint/no-unassigned-vars.md +++ /dev/null @@ -1,69 +0,0 @@ - - - - -# eslint/no-unassigned-vars - -
- -βœ… This rule is turned on by default. - -
- -### What it does - -Disallow let or var variables that are read but never assigned - -### Why is this bad? - -This rule flags let or var declarations that are never assigned a value but are still read or used in the code. -Since these variables will always be undefined, their usage is likely a programming mistake. - -### Examples - -Examples of **incorrect** code for this rule: - -```js -let status; -if (status === "ready") { - console.log("Ready!"); -} -``` - -Examples of **correct** code for this rule: - -```js -let message = "hello"; -console.log(message); - -let user; -user = getUser(); -console.log(user.name); -``` - -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny no-unassigned-vars -``` - -```json [Config (.oxlintrc.json)] -{ - "rules": { - "no-unassigned-vars": "error" - } -} -``` - -::: - -## References - -- Rule Source diff --git a/src/docs/guide/usage/linter/rules/eslint/no-undef.md b/src/docs/guide/usage/linter/rules/eslint/no-undef.md index 8a234c95434..6799f2fb551 100644 --- a/src/docs/guide/usage/linter/rules/eslint/no-undef.md +++ b/src/docs/guide/usage/linter/rules/eslint/no-undef.md @@ -1,10 +1,5 @@ - - # eslint/no-undef
@@ -18,35 +13,13 @@ Disallow the use of undeclared variables. It is most likely a potential ReferenceError caused by a misspelling of a variable or parameter name. -### Examples - -Examples of **incorrect** code for this rule: +### Example ```javascript var foo = someFunction(); var bar = a + 1; ``` -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny no-undef -``` - -```json [Config (.oxlintrc.json)] -{ - "rules": { - "no-undef": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/eslint/no_undef.rs) diff --git a/src/docs/guide/usage/linter/rules/eslint/no-undefined.md b/src/docs/guide/usage/linter/rules/eslint/no-undefined.md index 5cba8b690c9..2424aa2e30d 100644 --- a/src/docs/guide/usage/linter/rules/eslint/no-undefined.md +++ b/src/docs/guide/usage/linter/rules/eslint/no-undefined.md @@ -1,10 +1,5 @@ - - # eslint/no-undefined
@@ -16,12 +11,7 @@ Disallow the use of `undefined` as an identifier ### Why is this bad? -Using undefined directly can lead to bugs, since it can be shadowed or overwritten in JavaScript. -It's safer and more intentional to use null or rely on implicit undefined (e.g., missing return) to avoid accidental issues. - -### Examples - -Examples of **incorrect** code for this rule: +### Example of bad code ```javascript var foo = undefined; @@ -39,7 +29,7 @@ function baz(undefined) { bar(undefined, "lorem"); ``` -Examples of **correct** code for this rule: +### Example of good code ```javascript var foo = void 0; @@ -55,26 +45,6 @@ global.undefined = "foo"; bar(void 0, "lorem"); ``` -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny no-undefined -``` - -```json [Config (.oxlintrc.json)] -{ - "rules": { - "no-undefined": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/eslint/no_undefined.rs) diff --git a/src/docs/guide/usage/linter/rules/eslint/no-unexpected-multiline.md b/src/docs/guide/usage/linter/rules/eslint/no-unexpected-multiline.md index 552df3d8124..188753c2475 100644 --- a/src/docs/guide/usage/linter/rules/eslint/no-unexpected-multiline.md +++ b/src/docs/guide/usage/linter/rules/eslint/no-unexpected-multiline.md @@ -1,10 +1,5 @@ - - # eslint/no-unexpected-multiline
@@ -32,12 +27,11 @@ Examples of **incorrect** code for this rule: ```js var a = b(x || y).doSomething(); -var a = b[a, b, c].forEach(doSomething); +var a = b[(a, b, c)].forEach(doSomething); -let x = function() {}`hello`; +let x = (function () {})`hello`; -foo - / bar / g.test(baz); +foo / bar / g.test(baz); ``` Examples of **correct** code for this rule: @@ -49,33 +43,13 @@ var a = b; var a = b; [a, b, c].forEach(doSomething); -let x = function() {}; +let x = function () {}; `hello`; foo; /bar/g.test(baz); ``` -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny no-unexpected-multiline -``` - -```json [Config (.oxlintrc.json)] -{ - "rules": { - "no-unexpected-multiline": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/eslint/no_unexpected_multiline.rs) diff --git a/src/docs/guide/usage/linter/rules/eslint/no-unneeded-ternary.md b/src/docs/guide/usage/linter/rules/eslint/no-unneeded-ternary.md deleted file mode 100644 index 7fe79cdb482..00000000000 --- a/src/docs/guide/usage/linter/rules/eslint/no-unneeded-ternary.md +++ /dev/null @@ -1,70 +0,0 @@ - - - - -# eslint/no-unneeded-ternary - -
- -βš οΈπŸ› οΈοΈ A dangerous auto-fix is available for this rule. - -
- -### What it does - -Disallow ternary operators when simpler alternatives exist - -### Why is this bad? - -It’s a common mistake in JavaScript to use a conditional expression to select between two -Boolean values instead of using ! to convert the test to a Boolean. - -Another common mistake is using a single variable as both the conditional test and the -consequent. In such cases, the logical OR can be used to provide the same functionality. - -### Examples - -Examples of **incorrect** code for this rule: - -```js -const isYes = answer === 1 ? true : false; -const isNo = answer === 1 ? false : true; - -foo(bar ? bar : 1); -``` - -Examples of **correct** code for this rule: - -```js -const isYes = answer === 1; -const isNo = answer !== 1; - -foo(bar || 1); -``` - -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny no-unneeded-ternary -``` - -```json [Config (.oxlintrc.json)] -{ - "rules": { - "no-unneeded-ternary": "error" - } -} -``` - -::: - -## References - -- Rule Source diff --git a/src/docs/guide/usage/linter/rules/eslint/no-unreachable.md b/src/docs/guide/usage/linter/rules/eslint/no-unreachable.md index d4605fa373c..b8e9f90be00 100644 --- a/src/docs/guide/usage/linter/rules/eslint/no-unreachable.md +++ b/src/docs/guide/usage/linter/rules/eslint/no-unreachable.md @@ -1,10 +1,5 @@ - - # eslint/no-unreachable
@@ -38,26 +33,6 @@ function foo() { } ``` -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny no-unreachable -``` - -```json [Config (.oxlintrc.json)] -{ - "rules": { - "no-unreachable": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/eslint/no_unreachable.rs) diff --git a/src/docs/guide/usage/linter/rules/eslint/no-unsafe-finally.md b/src/docs/guide/usage/linter/rules/eslint/no-unsafe-finally.md index f253c28bfed..7177d3d049c 100644 --- a/src/docs/guide/usage/linter/rules/eslint/no-unsafe-finally.md +++ b/src/docs/guide/usage/linter/rules/eslint/no-unsafe-finally.md @@ -1,10 +1,5 @@ - - # eslint/no-unsafe-finally
@@ -22,9 +17,7 @@ Disallow control flow statements in finally blocks JavaScript suspends the control flow statements of try and catch blocks until the execution of finally block finishes. So, when return, throw, break, or continue is used in finally, control flow statements inside try and catch are overwritten, which is considered as unexpected behavior. -### Examples - -Examples of **incorrect** code for this rule: +### Example ```javascript // We expect this function to return 1; @@ -41,26 +34,6 @@ Examples of **incorrect** code for this rule: // > 3 ``` -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny no-unsafe-finally -``` - -```json [Config (.oxlintrc.json)] -{ - "rules": { - "no-unsafe-finally": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/eslint/no_unsafe_finally.rs) diff --git a/src/docs/guide/usage/linter/rules/eslint/no-unsafe-negation.md b/src/docs/guide/usage/linter/rules/eslint/no-unsafe-negation.md index f06b20fe3bc..9cdae9eab4f 100644 --- a/src/docs/guide/usage/linter/rules/eslint/no-unsafe-negation.md +++ b/src/docs/guide/usage/linter/rules/eslint/no-unsafe-negation.md @@ -1,10 +1,5 @@ - - # eslint/no-unsafe-negation
@@ -18,65 +13,23 @@ const source = `https://github.com/oxc-project/oxc/blob/${ data }/crates/oxc_lin ### What it does -Disallows negating the left operand of relational operators to prevent logical errors -caused by misunderstanding operator precedence or accidental use of negation. +Disallow negating the left operand of relational operators ### Why is this bad? -Negating the left operand of relational operators can result in unexpected behavior due to -operator precedence, leading to logical errors. For instance, `!a in b` may be interpreted -as `(!a) in b` instead of `!(a in b)`, which is not the intended logic. - -### Examples +Just as developers might type -a + b when they mean -(a + b) for the negative of a sum, +they might type !key in object by mistake when they almost certainly mean !(key in object) +to test that a key is not in an object. !obj instanceof Ctor is similar. -Examples of **incorrect** code for this rule: +### Example ```javascript -if ((!key) in object) {} - -if ((!obj) instanceof Ctor) {} -``` - -Examples of **correct** code for this rule: - -```javascript -if (!(key in object)) {} - -if (!(obj instanceof Ctor)) {} -``` - -### Options - -#### enforceForOrderingRelations - -`{ type: boolean, default: false }` - -The `enforceForOrderingRelations` option determines whether negation is allowed -on the left-hand side of ordering relational operators (<, >, <=, >=). - -The purpose is to avoid expressions such as `!a < b` (which is equivalent to `(a ? 0 : 1) < b`) -when what is really intended is `!(a < b)`. - -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny no-unsafe-negation -``` - -```json [Config (.oxlintrc.json)] -{ - "rules": { - "no-unsafe-negation": "error" - } +if ((!key) in object) { + //operator precedence makes it equivalent to (!key) in object + //and type conversion makes it equivalent to (key ? "false" : "true") in object } ``` -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/eslint/no_unsafe_negation.rs) diff --git a/src/docs/guide/usage/linter/rules/eslint/no-unsafe-optional-chaining.md b/src/docs/guide/usage/linter/rules/eslint/no-unsafe-optional-chaining.md index e84164b97a6..54d7c9b13e6 100644 --- a/src/docs/guide/usage/linter/rules/eslint/no-unsafe-optional-chaining.md +++ b/src/docs/guide/usage/linter/rules/eslint/no-unsafe-optional-chaining.md @@ -1,10 +1,5 @@ - - # eslint/no-unsafe-optional-chaining
@@ -23,9 +18,7 @@ The optional chaining (?.) expression can short-circuit with a return value of u Therefore, treating an evaluated optional chaining expression as a function, object, number, etc., can cause TypeError or unexpected results. For example: -### Examples - -Examples of **incorrect** code for this rule: +### Example ```javascript var obj = undefined; @@ -36,26 +29,6 @@ bar instanceof obj?.foo; // TypeError const { bar } = obj?.foo; // TypeError ``` -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny no-unsafe-optional-chaining -``` - -```json [Config (.oxlintrc.json)] -{ - "rules": { - "no-unsafe-optional-chaining": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/eslint/no_unsafe_optional_chaining.rs) diff --git a/src/docs/guide/usage/linter/rules/eslint/no-unused-expressions.md b/src/docs/guide/usage/linter/rules/eslint/no-unused-expressions.md index 2dd7b1c0d8f..f29f3e4ed06 100644 --- a/src/docs/guide/usage/linter/rules/eslint/no-unused-expressions.md +++ b/src/docs/guide/usage/linter/rules/eslint/no-unused-expressions.md @@ -1,16 +1,8 @@ - - -# eslint/no-unused-expressions +# eslint/no-unused-expressions
- -βœ… This rule is turned on by default. -
### What it does @@ -37,62 +29,6 @@ Examples of **correct** code for this rule: const foo = new Set(); ``` -## Configuration - -This rule accepts a configuration object with the following properties: - -### allowShortCircuit - -type: `boolean` - -default: `false` - -When set to `true`, allows short circuit evaluations in expressions. - -### allowTaggedTemplates - -type: `boolean` - -default: `false` - -When set to `true`, allows tagged template literals in expressions. - -### allowTernary - -type: `boolean` - -default: `false` - -When set to `true`, allows ternary operators in expressions. - -### enforceForJsx - -type: `boolean` - -default: `false` - -When set to `true`, enforces the rule for unused JSX expressions also. - -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny no-unused-expressions -``` - -```json [Config (.oxlintrc.json)] -{ - "rules": { - "no-unused-expressions": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/eslint/no_unused_expressions.rs) diff --git a/src/docs/guide/usage/linter/rules/eslint/no-unused-labels.md b/src/docs/guide/usage/linter/rules/eslint/no-unused-labels.md index e7e90a4f9f7..29c8e66cd63 100644 --- a/src/docs/guide/usage/linter/rules/eslint/no-unused-labels.md +++ b/src/docs/guide/usage/linter/rules/eslint/no-unused-labels.md @@ -1,10 +1,5 @@ - - # eslint/no-unused-labels
@@ -24,24 +19,10 @@ Disallow unused labels Labels that are declared and not used anywhere in the code are most likely an error due to incomplete refactoring. -### Examples - -Examples of **incorrect** code for this rule: - -```javascript -OUTER_LOOP: -for (const student of students) { - if (checkScores(student.scores)) { - continue; - } - doSomething(student); -} -``` - -Examples of **correct** code for this rule: +### Example ```javascript -for (const student of students) { +OUTER_LOOP: for (const student of students) { if (checkScores(student.scores)) { continue; } @@ -49,26 +30,6 @@ for (const student of students) { } ``` -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny no-unused-labels -``` - -```json [Config (.oxlintrc.json)] -{ - "rules": { - "no-unused-labels": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/eslint/no_unused_labels.rs) diff --git a/src/docs/guide/usage/linter/rules/eslint/no-unused-private-class-members.md b/src/docs/guide/usage/linter/rules/eslint/no-unused-private-class-members.md index f5f44dd3f95..c96161132b4 100644 --- a/src/docs/guide/usage/linter/rules/eslint/no-unused-private-class-members.md +++ b/src/docs/guide/usage/linter/rules/eslint/no-unused-private-class-members.md @@ -1,10 +1,5 @@ - - # eslint/no-unused-private-class-members
@@ -83,26 +78,6 @@ class C { } ``` -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny no-unused-private-class-members -``` - -```json [Config (.oxlintrc.json)] -{ - "rules": { - "no-unused-private-class-members": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/eslint/no_unused_private_class_members.rs) diff --git a/src/docs/guide/usage/linter/rules/eslint/no-unused-vars.md b/src/docs/guide/usage/linter/rules/eslint/no-unused-vars.md index 700ab1587a2..9e7a9bb3848 100644 --- a/src/docs/guide/usage/linter/rules/eslint/no-unused-vars.md +++ b/src/docs/guide/usage/linter/rules/eslint/no-unused-vars.md @@ -1,10 +1,5 @@ - - # eslint/no-unused-vars
@@ -45,7 +40,7 @@ true: (`doSomething(function() { foo(); })`) - It is exported (`export const foo = 42`) - It is used as an operand to TypeScript's `typeof` operator (`const bar: - typeof foo = 4`) +typeof foo = 4`) A variable is _not_ considered to be used if it is only ever declared (`var foo = 5`) or assigned to (`foo = 7`). @@ -83,7 +78,7 @@ comments as a way to indicate that a variable is used in another script and should not be considered unused. Since ES6 modules are now a TC39 standard, Oxlint does not support this feature. -### Examples +### Example Examples of **incorrect** code for this rule: @@ -105,7 +100,7 @@ var z = 0; z = z + 1; // By default, unused arguments cause warnings. -(function(foo) { +(function (foo) { return 5; })(); @@ -141,16 +136,18 @@ var x = 10; alert(x); // foo is considered used here -myFunc(function foo() { - // ... -}.bind(this)); +myFunc( + function foo() { + // ... + }.bind(this), +); -(function(foo) { +(function (foo) { return foo; })(); var myFunc; -myFunc = setTimeout(function() { +myFunc = setTimeout(function () { // myFunc is considered used myFunc(); }, 50); @@ -181,220 +178,6 @@ Examples of **incorrect** code for `/* exported variableName */` operation: var global_var = 42; ``` -## Configuration - -This rule accepts a configuration object with the following properties: - -### args - -Controls how unused arguments are checked. - -This option has three settings: - -1. `after-used` - Unused positional arguments that occur before the last - used argument will not be checked, but all named arguments and all - positional arguments after the last used argument will be checked. - This is the default setting. -2. `all` - All named arguments must be used. -3. `none` - Do not check arguments. - -### caughtErrors - -type: `boolean` - -Used for `catch` block validation. - -It has two settings: - -- `none` - do not check error objects. This is the default setting. -- `all` - all named arguments must be used`.`none`corresponds to`false`, while`all`corresponds to`true`. - -### ignoreClassWithStaticInitBlock - -type: `boolean` - -The `ignoreClassWithStaticInitBlock` option is a boolean (default: -`false`). Static initialization blocks allow you to initialize static -variables and execute code during the evaluation of a class definition, -meaning the static block code is executed without creating a new -instance of the class. When set to true, this option ignores classes -containing static initialization blocks. - -## Example - -Examples of **incorrect** code for the `{ "ignoreClassWithStaticInitBlock": true }` option - -```javascript -/*eslint no-unused-vars: ["error", { "ignoreClassWithStaticInitBlock": true }]*/ - -class Foo { - static myProperty = "some string"; - static mymethod() { - return "some string"; - } -} - -class Bar { - static { - let baz; // unused variable - } -} -``` - -Examples of **correct** code for the `{ "ignoreClassWithStaticInitBlock": true }` option - -```javascript -/*eslint no-unused-vars: ["error", { "ignoreClassWithStaticInitBlock": true }]*/ - -class Foo { - static { - let bar = "some string"; - - console.log(bar); - } -} -``` - -### ignoreRestSiblings - -type: `boolean` - -Using a Rest property it is possible to "omit" properties from an -object, but by default the sibling properties are marked as "unused". -With this option enabled the rest property's siblings are ignored. - -By default this option is `false`. - -## Example - -Examples of **correct** code when this option is set to `true`: - -```js -// 'foo' and 'bar' were ignored because they have a rest property sibling. -var { foo, ...coords } = data; - -var bar; -({ bar, ...coords } = data); -``` - -### ignoreUsingDeclarations - -type: `boolean` - -The `ignoreUsingDeclarations` option is a boolean (default: `false`). -When set to `true`, the rule will ignore variables declared with -`using` or `await using` declarations, even if they are unused. - -This is useful when working with resources that need to be disposed -via the explicit resource management proposal, where the primary -purpose is the disposal side effect rather than using the resource. - -## Example - -Examples of **correct** code for the `{ "ignoreUsingDeclarations": true }` option: - -```javascript -/*eslint no-unused-vars: ["error", { "ignoreUsingDeclarations": true }]*/ - -using resource = getResource(); -await using anotherResource = getAnotherResource(); -``` - -### reportUsedIgnorePattern - -type: `boolean` - -The `reportUsedIgnorePattern` option is a boolean (default: `false`). -Using this option will report variables that match any of the valid -ignore pattern options (`varsIgnorePattern`, `argsIgnorePattern`, -`caughtErrorsIgnorePattern`, or `destructuredArrayIgnorePattern`) if -they have been used. - -## Example - -Examples of **incorrect** code for the `{ "reportUsedIgnorePattern": true }` option: - -```javascript -/*eslint no-unused-vars: ["error", { "reportUsedIgnorePattern": true, "varsIgnorePattern": "[iI]gnored" }]*/ - -var firstVarIgnored = 1; -var secondVar = 2; -console.log(firstVarIgnored, secondVar); -``` - -Examples of **correct** code for the `{ "reportUsedIgnorePattern": true }` option: - -```javascript -/*eslint no-unused-vars: ["error", { "reportUsedIgnorePattern": true, "varsIgnorePattern": "[iI]gnored" }]*/ - -var firstVar = 1; -var secondVar = 2; -console.log(firstVar, secondVar); -``` - -### reportVarsOnlyUsedAsTypes - -type: `boolean` - -The `reportVarsOnlyUsedAsTypes` option is a boolean (default: `false`). - -If `true`, the rule will also report variables that are only used as types. - -## Examples - -Examples of **incorrect** code for the `{ "reportVarsOnlyUsedAsTypes": true }` option: - -```javascript -/* eslint no-unused-vars: ["error", { "reportVarsOnlyUsedAsTypes": true }] */ - -const myNumber: number = 4; -export type MyNumber = typeof myNumber -``` - -Examples of **correct** code for the `{ "reportVarsOnlyUsedAsTypes": true }` option: - -```javascript -export type MyNumber = number; -``` - -Note: even with `{ "reportVarsOnlyUsedAsTypes": false }`, cases where the value is -only used a type within itself will still be reported: - -```javascript -function foo(): typeof foo {} -``` - -### vars - -Controls how usage of a variable in the global scope is checked. - -This option has two settings: - -1. `all` checks all variables for usage, including those in the global - scope. This is the default setting. -2. `local` checks only that locally-declared variables are used but will - allow global variables to be unused. - -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny no-unused-vars -``` - -```json [Config (.oxlintrc.json)] -{ - "rules": { - "no-unused-vars": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/eslint/no_unused_vars/mod.rs) diff --git a/src/docs/guide/usage/linter/rules/eslint/no-useless-backreference.md b/src/docs/guide/usage/linter/rules/eslint/no-useless-backreference.md deleted file mode 100644 index 297e2194faf..00000000000 --- a/src/docs/guide/usage/linter/rules/eslint/no-useless-backreference.md +++ /dev/null @@ -1,73 +0,0 @@ - - - - -# eslint/no-useless-backreference - -
- -βœ… This rule is turned on by default. - -
- -### What it does - -Disallows backreferences in regular expressions that will always be ignored -because the capture group they refer to has not matched and cannot match -at the time the backreference is evaluated. - -### Why is this bad? - -Useless backreferences can lead to confusing or misleading regular expressions. -They may give the impression that a group’s value is being reused, but due to -the structure of the pattern (e.g., order of evaluation, disjunctions, or negative -lookarounds), the group has not matched anything β€” so the reference always -resolves to an empty string. This is almost always a mistake and makes patterns -harder to understand and maintain. - -### Examples - -Examples of **incorrect** code for this rule: - -```js -/\1(a)/; // backreference appears before group -/(a|\1b)/; // group and reference are in different alternatives -/(?<=\1(a))b/; // backreference used before group in lookbehind -/\1(?!(a))/; // group is inside negative lookahead -/(a\1)/; // backreference is inside its own group -``` - -Examples of **correct** code for this rule: - -```js -/(a)\1/; // valid β€” backreference follows completed group -/(?a)\k/; // named group used properly -/(?:a|(b))\1/; // backreference only used when group matches -``` - -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny no-useless-backreference -``` - -```json [Config (.oxlintrc.json)] -{ - "rules": { - "no-useless-backreference": "error" - } -} -``` - -::: - -## References - -- Rule Source diff --git a/src/docs/guide/usage/linter/rules/eslint/no-useless-call.md b/src/docs/guide/usage/linter/rules/eslint/no-useless-call.md deleted file mode 100644 index 5d1cb975756..00000000000 --- a/src/docs/guide/usage/linter/rules/eslint/no-useless-call.md +++ /dev/null @@ -1,80 +0,0 @@ - - - - -# eslint/no-useless-call - -
-
- -### What it does - -Disallow unnecessary calls to `.call()` and `.apply()` - -### Why is this bad? - -`Function.prototype.call()` and `Function.prototype.apply()` are slower than the normal function invocation. - -This rule compares code statically to check whether or not thisArg is changed. -So if the code about thisArg is a dynamic expression, this rule cannot judge correctly. - -### Examples - -Examples of **incorrect** code for this rule: - -```js -// These are the same as `foo(1, 2, 3);` -foo.call(undefined, 1, 2, 3); -foo.apply(undefined, [1, 2, 3]); -foo.call(null, 1, 2, 3); -foo.apply(null, [1, 2, 3]); - -// These are the same as `obj.foo(1, 2, 3);` -obj.foo.call(obj, 1, 2, 3); -obj.foo.apply(obj, [1, 2, 3]); -``` - -Examples of **correct** code for this rule: - -```js -// The `this` binding is different. -foo.call(obj, 1, 2, 3); -foo.apply(obj, [1, 2, 3]); -obj.foo.call(null, 1, 2, 3); -obj.foo.apply(null, [1, 2, 3]); -obj.foo.call(otherObj, 1, 2, 3); -obj.foo.apply(otherObj, [1, 2, 3]); - -// The argument list is variadic. -// Those are warned by the `prefer-spread` rule. -foo.apply(undefined, args); -foo.apply(null, args); -obj.foo.apply(obj, args); -``` - -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny no-useless-call -``` - -```json [Config (.oxlintrc.json)] -{ - "rules": { - "no-useless-call": "error" - } -} -``` - -::: - -## References - -- Rule Source diff --git a/src/docs/guide/usage/linter/rules/eslint/no-useless-catch.md b/src/docs/guide/usage/linter/rules/eslint/no-useless-catch.md index c04b2ffedba..caf3913737c 100644 --- a/src/docs/guide/usage/linter/rules/eslint/no-useless-catch.md +++ b/src/docs/guide/usage/linter/rules/eslint/no-useless-catch.md @@ -1,10 +1,5 @@ - - # eslint/no-useless-catch
@@ -24,9 +19,7 @@ and has no effect on the runtime behavior of the program. These redundant clauses can be a source of confusion and code bloat, so it’s better to disallow these unnecessary catch clauses. -### Examples - -Examples of **incorrect** code for this rule: +### Example ```javascript try { @@ -36,32 +29,6 @@ try { } ``` -Examples of **correct** code for this rule: - -```javascript -doSomethingThatMightThrow(); -``` - -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny no-useless-catch -``` - -```json [Config (.oxlintrc.json)] -{ - "rules": { - "no-useless-catch": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/eslint/no_useless_catch.rs) diff --git a/src/docs/guide/usage/linter/rules/eslint/no-useless-computed-key.md b/src/docs/guide/usage/linter/rules/eslint/no-useless-computed-key.md deleted file mode 100644 index c1106b11ae4..00000000000 --- a/src/docs/guide/usage/linter/rules/eslint/no-useless-computed-key.md +++ /dev/null @@ -1,127 +0,0 @@ - - - - -# eslint/no-useless-computed-key - -
- -🚧 An auto-fix is still under development. - -
- -### What it does - -Disallow unnecessary computed property keys in objects and classes - -### Why is this bad? - -It’s unnecessary to use computed properties with literals such as: - -```js -const foo = { ["a"]: "b" }; -``` - -The code can be rewritten as: - -```js -const foo = { "a": "b" }; -``` - -### Examples - -Examples of **incorrect** code for this rule: - -```js -const a = { ["0"]: 0 }; -const b = { ["0+1,234"]: 0 }; -const c = { [0]: 0 }; -const e = { ["x"]() {} }; - -class Foo { - ["foo"] = "bar"; - [0]() {} - static ["foo"] = "bar"; - get ["b"]() {} - set ["c"](value) {} -} -``` - -Examples of **correct** code for this rule: - -```js -const a = { "a": 0 }; -const b = { 0: 0 }; -const c = { x() {} }; -const e = { "0+1,234": 0 }; - -class Foo { - "foo" = "bar"; - 0() {} - "a"() {} - static "foo" = "bar"; -} -``` - -Examples of additional **correct** code for this rule: - -```js -const c = { - "__proto__": foo, // defines object's prototype - ["__proto__"]: bar, // defines a property named "__proto__" -}; -class Foo { - ["constructor"]; // instance field named "constructor" - "constructor"() {} // the constructor of this class - static ["constructor"]; // static field named "constructor" - static ["prototype"]; // runtime error, it would be a parsing error without `[]` -} -``` - -### Options - -#### enforceForClassMembers - -`{ type: boolean, default: true }` - -The `enforceForClassMembers` option controls whether the rule applies to -class members (methods and properties). - -Examples of **correct** code for this rule with the `{ "enforceForClassMembers": false }` option: - -```js -class SomeClass { - ["foo"] = "bar"; - [42] = "baz"; - get ["b"]() {} - set ["c"](value) {} - static ["foo"] = "bar"; -} -``` - -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny no-useless-computed-key -``` - -```json [Config (.oxlintrc.json)] -{ - "rules": { - "no-useless-computed-key": "error" - } -} -``` - -::: - -## References - -- Rule Source diff --git a/src/docs/guide/usage/linter/rules/eslint/no-useless-concat.md b/src/docs/guide/usage/linter/rules/eslint/no-useless-concat.md index a7c684d80a9..ba1726d886d 100644 --- a/src/docs/guide/usage/linter/rules/eslint/no-useless-concat.md +++ b/src/docs/guide/usage/linter/rules/eslint/no-useless-concat.md @@ -1,10 +1,5 @@ - - # eslint/no-useless-concat
@@ -16,55 +11,14 @@ Disallow unnecessary concatenation of literals or template literals ### Why is this bad? -It’s unnecessary to concatenate two strings together when they could -be combined into a single literal. - -### Examples +It’s unnecessary to concatenate two strings together. -Examples of **incorrect** code for this rule: +### Example ```javascript var foo = "a" + "b"; ``` -```javascript -var foo = "a" + "b" + "c"; -``` - -Examples of **correct** code for this rule: - -```javascript -var foo = "a" + bar; -``` - -// when the string concatenation is multiline - -```javascript -var foo = "a" - + "b" - + "c"; -``` - -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny no-useless-concat -``` - -```json [Config (.oxlintrc.json)] -{ - "rules": { - "no-useless-concat": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/eslint/no_useless_concat.rs) diff --git a/src/docs/guide/usage/linter/rules/eslint/no-useless-constructor.md b/src/docs/guide/usage/linter/rules/eslint/no-useless-constructor.md index 2cb535aefc6..17c3d8be769 100644 --- a/src/docs/guide/usage/linter/rules/eslint/no-useless-constructor.md +++ b/src/docs/guide/usage/linter/rules/eslint/no-useless-constructor.md @@ -1,10 +1,5 @@ - - # eslint/no-useless-constructor
@@ -15,22 +10,22 @@ const source = `https://github.com/oxc-project/oxc/blob/${ data }/crates/oxc_lin ### What it does -Disallow constructors that can be safely removed without changing how the class works. +Disallow unnecessary constructors -### Why is this bad? +This rule flags class constructors that can be safely removed without +changing how the class works. ES2015 provides a default class constructor if one is not specified. As such, it is unnecessary to provide an empty constructor or one that -simply delegates into its parent class. +simply delegates into its parent class, as in the following examples: -### Examples +### Example Examples of **incorrect** code for this rule: ```javascript class A { - constructor() { - } + constructor() {} } class B extends A { @@ -65,26 +60,6 @@ class D extends A { } ``` -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny no-useless-constructor -``` - -```json [Config (.oxlintrc.json)] -{ - "rules": { - "no-useless-constructor": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/eslint/no_useless_constructor.rs) diff --git a/src/docs/guide/usage/linter/rules/eslint/no-useless-escape.md b/src/docs/guide/usage/linter/rules/eslint/no-useless-escape.md index 4818d28eaa7..43b6f7198fb 100644 --- a/src/docs/guide/usage/linter/rules/eslint/no-useless-escape.md +++ b/src/docs/guide/usage/linter/rules/eslint/no-useless-escape.md @@ -1,10 +1,5 @@ - - # eslint/no-useless-escape
@@ -18,23 +13,19 @@ const source = `https://github.com/oxc-project/oxc/blob/${ data }/crates/oxc_lin ### What it does -Disallow unnecessary escape characters. +Disallow unnecessary escape characters ### Why is this bad? -Escaping characters unnecessarily has no effect on the behavior of strings or regexes, -and can make code harder to read and understand by adding unnecessary complexity. -This applies to string literals, template literals, and regular expressions. - -### Examples +### Example Examples of **incorrect** code for this rule: ```javascript /*eslint no-useless-escape: "error"*/ -"'"; -"\""; +"\'"; +'\"'; "\#"; "\e"; `\"`; @@ -52,7 +43,7 @@ Examples of **correct** code for this rule: /*eslint no-useless-escape: "error"*/ "\""; -"'"; +'\''; "\x12"; "\u00a9"; "\371"; @@ -68,38 +59,6 @@ Examples of **correct** code for this rule: /[a-z-]/; ``` -## Configuration - -This rule accepts a configuration object with the following properties: - -### allowRegexCharacters - -type: `string[]` - -default: `[]` - -An array of characters that are allowed to be escaped unnecessarily in regexes. - -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny no-useless-escape -``` - -```json [Config (.oxlintrc.json)] -{ - "rules": { - "no-useless-escape": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/eslint/no_useless_escape.rs) diff --git a/src/docs/guide/usage/linter/rules/eslint/no-useless-rename.md b/src/docs/guide/usage/linter/rules/eslint/no-useless-rename.md index 89b0705efab..13c49916956 100644 --- a/src/docs/guide/usage/linter/rules/eslint/no-useless-rename.md +++ b/src/docs/guide/usage/linter/rules/eslint/no-useless-rename.md @@ -1,10 +1,5 @@ - - # eslint/no-useless-rename
@@ -21,7 +16,7 @@ Disallow renaming import, export, and destructured assignments to the same name. It is unnecessary to rename a variable to the same name. -### Examples +### Example Examples of **incorrect** code for this rule: @@ -39,26 +34,6 @@ const { bar: renamed } = obj; export { baz }; ``` -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny no-useless-rename -``` - -```json [Config (.oxlintrc.json)] -{ - "rules": { - "no-useless-rename": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/eslint/no_useless_rename.rs) diff --git a/src/docs/guide/usage/linter/rules/eslint/no-var.md b/src/docs/guide/usage/linter/rules/eslint/no-var.md index 7bd67abb76d..2a766b8c716 100644 --- a/src/docs/guide/usage/linter/rules/eslint/no-var.md +++ b/src/docs/guide/usage/linter/rules/eslint/no-var.md @@ -1,15 +1,10 @@ - - # eslint/no-var
-πŸ› οΈ An auto-fix is available for this rule for some violations. +πŸ› οΈ An auto-fix is available for this rule.
@@ -24,42 +19,18 @@ programmers avoid mistakes. Using `var` in an es6 environment triggers this error -### Examples - -Examples of **incorrect** code for this rule: +### Example ```javascript +// error var x = "y"; var CONFIG = {}; -``` - -Examples of **correct** code for this rule: -```javascript +// success let x = "y"; const CONFIG = {}; ``` -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny no-var -``` - -```json [Config (.oxlintrc.json)] -{ - "rules": { - "no-var": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/eslint/no_var.rs) diff --git a/src/docs/guide/usage/linter/rules/eslint/no-void.md b/src/docs/guide/usage/linter/rules/eslint/no-void.md index 44b244ce765..0b12806dadd 100644 --- a/src/docs/guide/usage/linter/rules/eslint/no-void.md +++ b/src/docs/guide/usage/linter/rules/eslint/no-void.md @@ -1,26 +1,20 @@ - - # eslint/no-void
-πŸ’‘ A suggestion is available for this rule. +🚧 An auto-fix is still under development.
### What it does -Disallows the use of the `void` operator. +Disallow `void` operators. -### Why is this bad? +Why is this bad -The `void` operator is often used to get `undefined`, but this is -unnecessary because `undefined` can be used directly instead. +The `void` operator is often used to obtain the `undefined` primitive value, but it is unnecessary. You can use `undefined` directly instead. ### Examples @@ -39,34 +33,6 @@ Examples of **correct** code for this rule: "foo.void = bar"; ``` -### Options - -#### allowAsStatement - -`{ type: boolean, default: false }` - -If set to `true`, using `void` as a standalone statement is allowed. - -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny no-void -``` - -```json [Config (.oxlintrc.json)] -{ - "rules": { - "no-void": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/eslint/no_void.rs) diff --git a/src/docs/guide/usage/linter/rules/eslint/no-warning-comments.md b/src/docs/guide/usage/linter/rules/eslint/no-warning-comments.md deleted file mode 100644 index 5e31ce8b3e5..00000000000 --- a/src/docs/guide/usage/linter/rules/eslint/no-warning-comments.md +++ /dev/null @@ -1,99 +0,0 @@ - - - - -# eslint/no-warning-comments - -
-
- -### What it does - -Disallows warning comments such as TODO, FIXME, XXX in code. - -### Why is this bad? - -Developers often add comments like TODO or FIXME to mark incomplete work or areas -that need attention. While useful during development, these comments can indicate -unfinished code that shouldn't be shipped to production. This rule helps catch -such comments before they make it into production code. - -### Examples - -Examples of **incorrect** code for this rule: - -```javascript -// TODO: implement this feature -function doSomething() {} - -// FIXME: this is broken -const x = 1; - -/* XXX: hack */ -let y = 2; -``` - -Examples of **correct** code for this rule: - -```javascript -// This is a regular comment -function doSomething() {} - -// Note: This explains something -const x = 1; -``` - -### Options - -This rule has an options object with the following defaults: - -```json -{ - "terms": ["todo", "fixme", "xxx"], - "location": "start", - "decoration": [] -} -``` - -#### `terms` - -An array of terms to match. The matching is case-insensitive. - -#### `location` - -Where to check for the terms: - -- `"start"` (default): Terms must appear at the start of the comment (after any decoration) -- `"anywhere"`: Terms can appear anywhere in the comment - -#### `decoration` - -An array of characters to ignore at the start of comments when `location` is `"start"`. -Useful for ignoring common comment decorations like `*` in JSDoc-style comments. - -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny no-warning-comments -``` - -```json [Config (.oxlintrc.json)] -{ - "rules": { - "no-warning-comments": "error" - } -} -``` - -::: - -## References - -- Rule Source diff --git a/src/docs/guide/usage/linter/rules/eslint/no-with.md b/src/docs/guide/usage/linter/rules/eslint/no-with.md index 13ab6a16013..b93ef0e7dcf 100644 --- a/src/docs/guide/usage/linter/rules/eslint/no-with.md +++ b/src/docs/guide/usage/linter/rules/eslint/no-with.md @@ -1,10 +1,7 @@ - # eslint/no-with +
βœ… This rule is turned on by default. @@ -19,37 +16,14 @@ Disallow `with` statements The with statement is potentially problematic because it adds members of an object to the current scope, making it impossible to tell what a variable inside the block actually refers to. -### Examples +### Example -Examples of **incorrect** code for this rule: ```javascript with (point) { - r = Math.sqrt(x * x + y * y); // is r a member of point? -} -``` - - -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny no-with -``` - -```json [Config (.oxlintrc.json)] -{ - "rules": { - "no-with": "error" - } + r = Math.sqrt(x * x + y * y); // is r a member of point? } ``` -::: - - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/eslint/no_with.rs) diff --git a/src/docs/guide/usage/linter/rules/eslint/operator-assignment.md b/src/docs/guide/usage/linter/rules/eslint/operator-assignment.md deleted file mode 100644 index 2abbf9e7aa7..00000000000 --- a/src/docs/guide/usage/linter/rules/eslint/operator-assignment.md +++ /dev/null @@ -1,104 +0,0 @@ - - - - -# eslint/operator-assignment - -
- -βš οΈπŸ› οΈοΈ A dangerous auto-fix is available for this rule. - -
- -### What it does - -This rule requires or disallows assignment operator shorthand where possible. -It encourages the use of shorthand assignment operators like `+=`, `-=`, `*=`, `/=`, etc. -to make the code more concise and readable. - -### Why is this bad? - -JavaScript provides shorthand operators that combine variable assignment and simple -mathematical operations. Failing to use these shorthand operators can lead to unnecessarily -verbose code and can be seen as a missed opportunity for clarity and simplicity. - -### Examples - -Examples of **incorrect** code for this rule with the default `always` option: - -```js -x = x + y; -x = y * x; -x[0] = x[0] / y; -x.y = x.y << z; -``` - -Examples of **correct** code for this rule with the default `always` option: - -```js -x = y; -x += y; -x = y * z; -x = (x * y) * z; -x[0] /= y; -x[foo()] = x[foo()] % 2; -x = y + x; // `+` is not always commutative (e.g. x = "abc") -``` - -Examples of **incorrect** code for this rule with the `never` option: - -```js -x *= y; -x ^= (y + z) / foo(); -``` - -Examples of **correct** code for this rule with the `never` option: - -```js -x = x + y; -x.y = x.y / a.b; -``` - -### Options - -This rule has a single string option: - -`{ type: string, default: "always" }` - -- `always` requires assignment operator shorthand where possible -- `never` disallows assignment operator shorthand - -Example: - -```json -"eslint/max-nested-callbacks": ["error", "always"] - -"eslint/max-nested-callbacks": ["error", "never"] -``` - -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny operator-assignment -``` - -```json [Config (.oxlintrc.json)] -{ - "rules": { - "operator-assignment": "error" - } -} -``` - -::: - -## References - -- Rule Source diff --git a/src/docs/guide/usage/linter/rules/eslint/prefer-destructuring.md b/src/docs/guide/usage/linter/rules/eslint/prefer-destructuring.md deleted file mode 100644 index 73746986c16..00000000000 --- a/src/docs/guide/usage/linter/rules/eslint/prefer-destructuring.md +++ /dev/null @@ -1,116 +0,0 @@ - - - - -# eslint/prefer-destructuring - -
- -🚧 An auto-fix is still under development. - -
- -### What it does - -Require destructuring from arrays and/or objects - -### Why is this bad? - -With JavaScript ES6, a new syntax was added for creating variables from an array index or object property, -called destructuring. This rule enforces usage of destructuring -instead of accessing a property through a member expression. - -### Examples - -Examples of **incorrect** code for this rule: - -```js -// With `array` enabled -const foo = array[0]; -bar.baz = array[0]; -// With `object` enabled -const qux = object.qux; -const quux = object["quux"]; -``` - -Examples of **correct** code for this rule: - -```js -// With `array` enabled -const [foo] = array; -const arr = array[someIndex]; -[bar.baz] = array; - -// With `object` enabled -const { baz } = object; -const obj = object.bar; -``` - -### Options - -This rule takes two arguments, both of which are objects. -The first object parameter determines what types of destructuring the rule applies to. -In the first object, there are two properties, array and object, -that can be used to turn on or off the destructuring requirement for each of those types independently. -By default, both are true. - -```json -{ - "prefer-destructuring": ["error", { "array": true, "object": true }] -} -``` - -Alternatively, you can use separate configurations for different assignment types. -The first argument accepts two other keys instead of array and object. -One key is VariableDeclarator and the other is AssignmentExpression, -which can be used to control the destructuring requirement for each of those types independently - -```json -{ - "prefer-destructuring": [ - "error", - { - "VariableDeclarator": { "array": true, "object": true }, - "AssignmentExpression": { "array": true, "object": true } - } - ] -} -``` - -#### enforceForRenamedProperties - -The rule has a second object argument with a single key, -enforceForRenamedProperties, which determines whether the object destructuring applies to renamed variables. - -```json -{ - "prefer-destructuring": ["error", { "array": true, "object": true }, { "enforceForRenamedProperties": true }] -} -``` - -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny prefer-destructuring -``` - -```json [Config (.oxlintrc.json)] -{ - "rules": { - "prefer-destructuring": "error" - } -} -``` - -::: - -## References - -- Rule Source diff --git a/src/docs/guide/usage/linter/rules/eslint/prefer-exponentiation-operator.md b/src/docs/guide/usage/linter/rules/eslint/prefer-exponentiation-operator.md index 414ba4cc0d0..8922a7c0400 100644 --- a/src/docs/guide/usage/linter/rules/eslint/prefer-exponentiation-operator.md +++ b/src/docs/guide/usage/linter/rules/eslint/prefer-exponentiation-operator.md @@ -1,10 +1,5 @@ - - # eslint/prefer-exponentiation-operator
@@ -12,48 +7,20 @@ const source = `https://github.com/oxc-project/oxc/blob/${ data }/crates/oxc_lin ### What it does -Disallow the use of Math.pow in favor of the ** operator +Disallow the use of Math.pow in favor of the \*\* operator ### Why is this bad? -Introduced in ES2016, the infix exponentiation operator ** is an alternative for the +Introduced in ES2016, the infix exponentiation operator \*\* is an alternative for the standard Math.pow function. Infix notation is considered to be more readable and thus more preferable than the function notation. -### Examples - -Examples of **incorrect** code for this rule: +### Example ```javascript Math.pow(a, b); ``` -Examples of **correct** code for this rule: - -```javascript -a ** b; -``` - -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny prefer-exponentiation-operator -``` - -```json [Config (.oxlintrc.json)] -{ - "rules": { - "prefer-exponentiation-operator": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/eslint/prefer_exponentiation_operator.rs) diff --git a/src/docs/guide/usage/linter/rules/eslint/prefer-numeric-literals.md b/src/docs/guide/usage/linter/rules/eslint/prefer-numeric-literals.md index d64526258c6..a63150ff6ef 100644 --- a/src/docs/guide/usage/linter/rules/eslint/prefer-numeric-literals.md +++ b/src/docs/guide/usage/linter/rules/eslint/prefer-numeric-literals.md @@ -1,10 +1,5 @@ - - # eslint/prefer-numeric-literals
@@ -25,9 +20,7 @@ hexadecimal strings into integers. As binary, octal, and hexadecimal literals ar in ES6, this rule encourages use of those numeric literals instead of parseInt() or Number.parseInt(). -### Examples - -Examples of **incorrect** code for this rule: +### Example ```javascript parseInt("111110111", 2) === 503; @@ -39,26 +32,6 @@ Number.parseInt("767", 8) === 503; Number.parseInt("1F7", 16) === 503; ``` -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny prefer-numeric-literals -``` - -```json [Config (.oxlintrc.json)] -{ - "rules": { - "prefer-numeric-literals": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/eslint/prefer_numeric_literals.rs) diff --git a/src/docs/guide/usage/linter/rules/eslint/prefer-object-has-own.md b/src/docs/guide/usage/linter/rules/eslint/prefer-object-has-own.md index 2bb5b181e04..26b5737eba0 100644 --- a/src/docs/guide/usage/linter/rules/eslint/prefer-object-has-own.md +++ b/src/docs/guide/usage/linter/rules/eslint/prefer-object-has-own.md @@ -1,10 +1,5 @@ - - # eslint/prefer-object-has-own
@@ -54,26 +49,6 @@ Object.hasOwn(obj, "a"); const hasProperty = Object.hasOwn(object, property); ``` -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny prefer-object-has-own -``` - -```json [Config (.oxlintrc.json)] -{ - "rules": { - "prefer-object-has-own": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/eslint/prefer_object_has_own.rs) diff --git a/src/docs/guide/usage/linter/rules/eslint/prefer-object-spread.md b/src/docs/guide/usage/linter/rules/eslint/prefer-object-spread.md deleted file mode 100644 index 73189f6ddf0..00000000000 --- a/src/docs/guide/usage/linter/rules/eslint/prefer-object-spread.md +++ /dev/null @@ -1,84 +0,0 @@ - - - - -# eslint/prefer-object-spread - -
- -πŸ› οΈ An auto-fix is available for this rule. - -
- -### What it does - -Disallow using `Object.assign` with an object literal as the first argument and prefer the use of object spread instead - -### Why is this bad? - -When `Object.assign` is called using an object literal as the first argument, this rule requires using the object spread syntax instead. This rule also warns on cases where an `Object.assign` call is made using a single argument that is an object literal, in this case, the `Object.assign` call is not needed. - -### Examples - -Examples of **incorrect** code for this rule: - -```js -Object.assign({}, foo); - -Object.assign({}, { foo: "bar" }); - -Object.assign({ foo: "bar" }, baz); - -Object.assign({}, baz, { foo: "bar" }); - -Object.assign({}, { ...baz }); - -// Object.assign with a single argument that is an object literal -Object.assign({}); - -Object.assign({ foo: bar }); -``` - -Examples of **correct** code for this rule: - -```js -({ ...foo }); - -({ ...baz, foo: "bar" }); - -// Any Object.assign call without an object literal as the first argument -Object.assign(foo, { bar: baz }); - -Object.assign(foo, bar); - -Object.assign(foo, { bar, baz }); - -Object.assign(foo, { ...baz }); -``` - -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny prefer-object-spread -``` - -```json [Config (.oxlintrc.json)] -{ - "rules": { - "prefer-object-spread": "error" - } -} -``` - -::: - -## References - -- Rule Source diff --git a/src/docs/guide/usage/linter/rules/eslint/prefer-promise-reject-errors.md b/src/docs/guide/usage/linter/rules/eslint/prefer-promise-reject-errors.md deleted file mode 100644 index caefc2cdd93..00000000000 --- a/src/docs/guide/usage/linter/rules/eslint/prefer-promise-reject-errors.md +++ /dev/null @@ -1,84 +0,0 @@ - - - - -# eslint/prefer-promise-reject-errors - -
-
- -### What it does - -Require using Error objects as Promise rejection reasons - -### Why is this bad? - -It is considered good practice to only pass instances of the built-in `Error` object to the `reject()` function for user-defined errors in Promises. `Error` objects automatically store a stack trace, which can be used to debug an error by determining where it came from. If a Promise is rejected with a non-`Error` value, it can be difficult to determine where the rejection occurred. - -### Options - -This rule takes one optional object argument: - -- `allowEmptyReject: true` (`false` by default) allows calls to `Promise.reject()` with no arguments. - -### Examples - -Examples of **incorrect** code for this rule: - -```js -Promise.reject("something bad happened"); - -Promise.reject(5); - -Promise.reject(); - -new Promise(function(resolve, reject) { - reject("something bad happened"); -}); - -new Promise(function(resolve, reject) { - reject(); -}); -``` - -Examples of **correct** code for this rule: - -```js -Promise.reject(new Error("something bad happened")); - -Promise.reject(new TypeError("something bad happened")); - -new Promise(function(resolve, reject) { - reject(new Error("something bad happened")); -}); - -var foo = getUnknownValue(); -Promise.reject(foo); -``` - -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny prefer-promise-reject-errors -``` - -```json [Config (.oxlintrc.json)] -{ - "rules": { - "prefer-promise-reject-errors": "error" - } -} -``` - -::: - -## References - -- Rule Source diff --git a/src/docs/guide/usage/linter/rules/eslint/prefer-rest-params.md b/src/docs/guide/usage/linter/rules/eslint/prefer-rest-params.md deleted file mode 100644 index ed993cd2217..00000000000 --- a/src/docs/guide/usage/linter/rules/eslint/prefer-rest-params.md +++ /dev/null @@ -1,85 +0,0 @@ - - - - -# eslint/prefer-rest-params - -
-
- -### What it does - -Disallows the use of the `arguments` object and instead enforces the use of rest parameters. - -### Why is this bad? - -The `arguments` object does not have methods from `Array.prototype`, making it inconvenient for array-like operations. -Using rest parameters provides a more intuitive and efficient way to handle variadic arguments. - -### Examples - -Examples of **incorrect** code for this rule: - -```javascript -function foo() { - console.log(arguments); -} - -function foo(action) { - var args = Array.prototype.slice.call(arguments, 1); - action.apply(null, args); -} - -function foo(action) { - var args = [].slice.call(arguments, 1); - action.apply(null, args); -} -``` - -Examples of **correct** code for this rule: - -```javascript -function foo(...args) { - console.log(args); -} - -function foo(action, ...args) { - action.apply(null, args); // Or use `action(...args)` (related to `prefer-spread` rule). -} - -// Note: Implicit `arguments` can be shadowed. -function foo(arguments) { - console.log(arguments); // This refers to the first argument. -} -function foo() { - var arguments = 0; - console.log(arguments); // This is a local variable. -} -``` - -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny prefer-rest-params -``` - -```json [Config (.oxlintrc.json)] -{ - "rules": { - "prefer-rest-params": "error" - } -} -``` - -::: - -## References - -- Rule Source diff --git a/src/docs/guide/usage/linter/rules/eslint/prefer-spread.md b/src/docs/guide/usage/linter/rules/eslint/prefer-spread.md index 00d16559797..490fd6b265d 100644 --- a/src/docs/guide/usage/linter/rules/eslint/prefer-spread.md +++ b/src/docs/guide/usage/linter/rules/eslint/prefer-spread.md @@ -1,17 +1,17 @@ - - # eslint/prefer-spread
+ +πŸ› οΈ An auto-fix is available for this rule for some violations. +
This rule is combined 2 rules from `eslint:prefer-spread` and `unicorn:prefer-spread`. +## original eslint:prefer-spread + ### What it does Require spread operators instead of .apply() @@ -61,26 +61,32 @@ foo.apply(null, [1, 2, 3]); obj.foo.apply(obj, [1, 2, 3]); ``` -## How to use +## unicorn:prefer-spread -To **enable** this rule in the CLI or using the config file, you can use: +### What it does -::: code-group +Enforces the use of [the spread operator (`...`)](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Spread_syntax) over outdated patterns. -```bash [CLI] -oxlint --deny prefer-spread -``` +### Why is this bad? + +Using the spread operator is more concise and readable. + +### Examples -```json [Config (.oxlintrc.json)] -{ - "rules": { - "prefer-spread": "error" - } -} +Examples of **incorrect** code for this rule: + +```javascript +const foo = Array.from(set); +const foo = Array.from(new Set([1, 2])); ``` -::: +Examples of **correct** code for this rule: + +```javascript +[...set].map(() => {}); +Array.from(...argumentsArray); +``` ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/eslint/prefer_spread.rs) diff --git a/src/docs/guide/usage/linter/rules/eslint/prefer-template.md b/src/docs/guide/usage/linter/rules/eslint/prefer-template.md deleted file mode 100644 index ae5839107b0..00000000000 --- a/src/docs/guide/usage/linter/rules/eslint/prefer-template.md +++ /dev/null @@ -1,63 +0,0 @@ - - - - -# eslint/prefer-template - -
- -🚧 An auto-fix is still under development. - -
- -### What it does - -Require template literals instead of string concatenation. - -### Why is this bad? - -In ES2015 (ES6), we can use template literals instead of string concatenation. - -### Examples - -Examples of **incorrect** code for this rule: - -```js -const str = "Hello, " + name + "!"; -const str1 = "Time: " + (12 * 60 * 60 * 1000); -``` - -Examples of **correct** code for this rule: - -```js -const str = "Hello World!"; -const str2 = `Time: ${12 * 60 * 60 * 1000}`; -const str4 = "Hello, " + "World!"; -``` - -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny prefer-template -``` - -```json [Config (.oxlintrc.json)] -{ - "rules": { - "prefer-template": "error" - } -} -``` - -::: - -## References - -- Rule Source diff --git a/src/docs/guide/usage/linter/rules/eslint/preserve-caught-error.md b/src/docs/guide/usage/linter/rules/eslint/preserve-caught-error.md deleted file mode 100644 index 05cb3943d4a..00000000000 --- a/src/docs/guide/usage/linter/rules/eslint/preserve-caught-error.md +++ /dev/null @@ -1,82 +0,0 @@ - - - - -# eslint/preserve-caught-error - -
- -πŸ› οΈ An auto-fix is available for this rule for some violations. - -
- -### What it does - -Enforces that when re-throwing an error in a catch block, the original error -is preserved using the 'cause' property. - -### Why is this bad? - -Re-throwing an error without preserving the original error loses important -debugging information and makes it harder to trace the root cause of issues. - -### Examples - -Examples of **incorrect** code for this rule: - -```js -try { - doSomething(); -} catch (err) { - throw new Error("Something failed"); -} -``` - -Examples of **correct** code for this rule: - -```js -try { - doSomething(); -} catch (err) { - throw new Error("Something failed", { cause: err }); -} -``` - -## Configuration - -This rule accepts a configuration object with the following properties: - -### requireCatchParameter - -type: `boolean` - -default: `false` - -When set to `true`, requires that catch clauses always have a parameter. - -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny preserve-caught-error -``` - -```json [Config (.oxlintrc.json)] -{ - "rules": { - "preserve-caught-error": "error" - } -} -``` - -::: - -## References - -- Rule Source diff --git a/src/docs/guide/usage/linter/rules/eslint/radix.md b/src/docs/guide/usage/linter/rules/eslint/radix.md index d618bc6068f..a69bca543dd 100644 --- a/src/docs/guide/usage/linter/rules/eslint/radix.md +++ b/src/docs/guide/usage/linter/rules/eslint/radix.md @@ -1,16 +1,8 @@ - - # eslint/radix
- -βš οΈπŸ› οΈοΈ A dangerous auto-fix is available for this rule for some violations. -
### What it does @@ -21,40 +13,16 @@ Enforce the consistent use of the radix argument when using `parseInt()`. Using the `parseInt()` function without specifying the radix can lead to unexpected results. -### Examples - -Examples of **incorrect** code for this rule: +### Example ```javascript +// error var num = parseInt("071"); // 57 -``` - -Examples of **correct** code for this rule: -```javascript +// success var num = parseInt("071", 10); // 71 ``` -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny radix -``` - -```json [Config (.oxlintrc.json)] -{ - "rules": { - "radix": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/eslint/radix.rs) diff --git a/src/docs/guide/usage/linter/rules/eslint/require-await.md b/src/docs/guide/usage/linter/rules/eslint/require-await.md index a68bf27055a..eac7681c45f 100644 --- a/src/docs/guide/usage/linter/rules/eslint/require-await.md +++ b/src/docs/guide/usage/linter/rules/eslint/require-await.md @@ -1,16 +1,8 @@ - - # eslint/require-await
- -βš οΈπŸ› οΈοΈ A dangerous auto-fix is available for this rule. -
### What it does @@ -46,7 +38,7 @@ generators yield rather than return a value and async generators might yield all the values of another async generator without ever actually needing to use await. -### Examples +### Example Examples of **incorrect** code for this rule: @@ -64,26 +56,6 @@ async function foo() { } ``` -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny require-await -``` - -```json [Config (.oxlintrc.json)] -{ - "rules": { - "require-await": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/eslint/require_await.rs) diff --git a/src/docs/guide/usage/linter/rules/eslint/require-yield.md b/src/docs/guide/usage/linter/rules/eslint/require-yield.md index 83115f08a92..08646bc08f9 100644 --- a/src/docs/guide/usage/linter/rules/eslint/require-yield.md +++ b/src/docs/guide/usage/linter/rules/eslint/require-yield.md @@ -1,10 +1,5 @@ - - # eslint/require-yield
@@ -21,9 +16,7 @@ This rule generates warnings for generator functions that do not have the yield Probably a mistake. -### Examples - -Examples of **incorrect** code for this rule: +### Example ```javascript function* foo() { @@ -31,26 +24,6 @@ function* foo() { } ``` -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny require-yield -``` - -```json [Config (.oxlintrc.json)] -{ - "rules": { - "require-yield": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/eslint/require_yield.rs) diff --git a/src/docs/guide/usage/linter/rules/eslint/sort-imports.md b/src/docs/guide/usage/linter/rules/eslint/sort-imports.md index 1cef3fcaee4..6c87ae5bd31 100644 --- a/src/docs/guide/usage/linter/rules/eslint/sort-imports.md +++ b/src/docs/guide/usage/linter/rules/eslint/sort-imports.md @@ -1,10 +1,5 @@ - - # eslint/sort-imports
@@ -23,37 +18,15 @@ the code and find necessary imports later. ### Why is this bad? -### Examples - -Examples of **incorrect** code for this rule: +### Example ```javascript -import { a, b, c } from "foo.js"; +import { b, a, c } from "foo.js"; -import e from "bar.js"; import d from "foo.js"; +import e from "bar.js"; ``` -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny sort-imports -``` - -```json [Config (.oxlintrc.json)] -{ - "rules": { - "sort-imports": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/eslint/sort_imports.rs) diff --git a/src/docs/guide/usage/linter/rules/eslint/sort-keys.md b/src/docs/guide/usage/linter/rules/eslint/sort-keys.md index 10c7372b825..aca470ca487 100644 --- a/src/docs/guide/usage/linter/rules/eslint/sort-keys.md +++ b/src/docs/guide/usage/linter/rules/eslint/sort-keys.md @@ -1,15 +1,10 @@ - - # eslint/sort-keys
-πŸ› οΈ An auto-fix is available for this rule for some violations. +🚧 An auto-fix is still under development.
@@ -42,26 +37,6 @@ let myObj = { }; ``` -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny sort-keys -``` - -```json [Config (.oxlintrc.json)] -{ - "rules": { - "sort-keys": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/eslint/sort_keys.rs) diff --git a/src/docs/guide/usage/linter/rules/eslint/sort-vars.md b/src/docs/guide/usage/linter/rules/eslint/sort-vars.md index c1564d4830a..02672cd8a29 100644 --- a/src/docs/guide/usage/linter/rules/eslint/sort-vars.md +++ b/src/docs/guide/usage/linter/rules/eslint/sort-vars.md @@ -1,10 +1,5 @@ - - # eslint/sort-vars
@@ -38,26 +33,6 @@ var a, b, c, d; var B, a, c; ``` -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny sort-vars -``` - -```json [Config (.oxlintrc.json)] -{ - "rules": { - "sort-vars": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/eslint/sort_vars.rs) diff --git a/src/docs/guide/usage/linter/rules/eslint/symbol-description.md b/src/docs/guide/usage/linter/rules/eslint/symbol-description.md index a65310661b3..d4a7fca0adc 100644 --- a/src/docs/guide/usage/linter/rules/eslint/symbol-description.md +++ b/src/docs/guide/usage/linter/rules/eslint/symbol-description.md @@ -1,10 +1,5 @@ - - # eslint/symbol-description
@@ -34,40 +29,12 @@ console.log(foo); // prints - Symbol(some description) ``` -### Examples - -Examples of **incorrect** code for this rule: +### Example ```javascript var foo = Symbol(); ``` -Examples of **correct** code for this rule: - -```javascript -var foo = Symbol("some description"); -``` - -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny symbol-description -``` - -```json [Config (.oxlintrc.json)] -{ - "rules": { - "symbol-description": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/eslint/symbol_description.rs) diff --git a/src/docs/guide/usage/linter/rules/eslint/unicode-bom.md b/src/docs/guide/usage/linter/rules/eslint/unicode-bom.md index f7c29a71737..c5ce87b27af 100644 --- a/src/docs/guide/usage/linter/rules/eslint/unicode-bom.md +++ b/src/docs/guide/usage/linter/rules/eslint/unicode-bom.md @@ -1,10 +1,5 @@ - - # eslint/unicode-bom
@@ -25,34 +20,12 @@ UTF-8 does not require a BOM because byte ordering does not matter when characte single byte. Since UTF-8 is the dominant encoding of the web, we make "never" the default option. -### Examples - -Examples of **incorrect** code for this rule: +### Example ```javascript var a = 123; ``` -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny unicode-bom -``` - -```json [Config (.oxlintrc.json)] -{ - "rules": { - "unicode-bom": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/eslint/unicode_bom.rs) diff --git a/src/docs/guide/usage/linter/rules/eslint/use-isnan.md b/src/docs/guide/usage/linter/rules/eslint/use-isnan.md index c54137daebb..ad19dd97e54 100644 --- a/src/docs/guide/usage/linter/rules/eslint/use-isnan.md +++ b/src/docs/guide/usage/linter/rules/eslint/use-isnan.md @@ -1,10 +1,5 @@ - - # eslint/use-isnan
@@ -35,9 +30,7 @@ the results of comparisons to NaN are confusing: Therefore, use Number.isNaN() or global isNaN() functions to test whether a value is NaN. -### Examples - -Examples of **incorrect** code for this rule: +### Example ```javascript foo == NaN; @@ -46,46 +39,6 @@ foo <= NaN; foo > NaN; ``` -## Configuration - -This rule accepts a configuration object with the following properties: - -### enforceForIndexOf - -type: `boolean` - -default: `false` - -Whether to disallow NaN as arguments of `indexOf` and `lastIndexOf` - -### enforceForSwitchCase - -type: `boolean` - -default: `true` - -Whether to disallow NaN in switch cases and discriminants - -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny use-isnan -``` - -```json [Config (.oxlintrc.json)] -{ - "rules": { - "use-isnan": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/eslint/use_isnan.rs) diff --git a/src/docs/guide/usage/linter/rules/eslint/valid-typeof.md b/src/docs/guide/usage/linter/rules/eslint/valid-typeof.md index d1fa22f0e07..d06faffc9a9 100644 --- a/src/docs/guide/usage/linter/rules/eslint/valid-typeof.md +++ b/src/docs/guide/usage/linter/rules/eslint/valid-typeof.md @@ -1,10 +1,5 @@ - - # eslint/valid-typeof
@@ -18,89 +13,28 @@ const source = `https://github.com/oxc-project/oxc/blob/${ data }/crates/oxc_lin ### What it does -Enforce comparing `typeof` expressions against valid strings. +Enforce comparing `typeof` expressions against valid strings ### Why is this bad? -For a vast majority of use cases, the result of the `typeof` operator is one of the -following string literals: `"undefined"`, `"object"`, `"boolean"`, `"number"`, `"string"`, -`"function"`, `"symbol"`, and `"bigint"`. It is usually a typing mistake to compare the -result of a `typeof` operator to other string literals. - -### Examples +It is usually a typing mistake to compare the result of a `typeof` +operator to other string literals. -Examples of **incorrect** code for this rule: +### Example ```js +// requireStringLiterals: false +// incorrect: typeof foo === "strnig"; -typeof foo == "undefimed"; -typeof bar != "nunber"; // spellchecker:disable-line -typeof bar !== "fucntion"; // spellchecker:disable-line -``` - -Examples of **correct** code for this rule: - -```js +// correct: typeof foo === "string"; -typeof bar == "undefined"; typeof foo === baz; -typeof bar === typeof qux; -``` - -## Configuration - -This rule accepts a configuration object with the following properties: - -### requireStringLiterals - -type: `boolean` - -default: `false` - -The `requireStringLiterals` option when set to `true`, allows the comparison of `typeof` -expressions with only string literals or other `typeof` expressions, and disallows -comparisons to any other value. Default is `false`. - -With `requireStringLiterals` set to `true`, the following are examples of **incorrect** code: -```js -typeof foo === undefined; -typeof bar == Object; -typeof baz === "strnig"; -typeof qux === "some invalid type"; -typeof baz === anotherVariable; -typeof foo == 5; -``` - -With `requireStringLiterals` set to `true`, the following are examples of **correct** code: - -```js -typeof foo === "undefined"; -typeof bar == "object"; -typeof baz === "string"; -typeof bar === typeof qux; -``` - -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny valid-typeof -``` - -```json [Config (.oxlintrc.json)] -{ - "rules": { - "valid-typeof": "error" - } -} +// requireStringLiterals: true +// incorrect: +typeof foo === baz; ``` -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/eslint/valid_typeof.rs) diff --git a/src/docs/guide/usage/linter/rules/eslint/vars-on-top.md b/src/docs/guide/usage/linter/rules/eslint/vars-on-top.md deleted file mode 100644 index 070f4a4fda8..00000000000 --- a/src/docs/guide/usage/linter/rules/eslint/vars-on-top.md +++ /dev/null @@ -1,108 +0,0 @@ - - - - -# eslint/vars-on-top - -
-
- -### What it does - -Enforces that all `var` declarations are placed at the top of their containing scope. - -### Why is this bad? - -In JavaScript, `var` declarations are hoisted to the top of their containing scope. Placing `var` declarations at the top explicitly improves code readability and maintainability by making the scope of variables clear. - -### Examples - -Examples of **incorrect** code for this rule: - -```js -function doSomething() { - if (true) { - var first = true; - } - var second; -} - -function doSomethingElse() { - for (var i = 0; i < 10; i++) {} -} - -f(); -var a; - -class C { - static { - if (something) { - var a = true; - } - } - static { - f(); - var a; - } -} -``` - -Examples of **correct** code for this rule: - -```js -function doSomething() { - var first; - var second; - if (true) { - first = true; - } -} - -function doSomethingElse() { - var i; - for (i = 0; i < 10; i++) {} -} - -var a; -f(); - -class C { - static { - var a; - if (something) { - a = true; - } - } - static { - var a; - f(); - } -} -``` - -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny vars-on-top -``` - -```json [Config (.oxlintrc.json)] -{ - "rules": { - "vars-on-top": "error" - } -} -``` - -::: - -## References - -- Rule Source diff --git a/src/docs/guide/usage/linter/rules/eslint/yoda.md b/src/docs/guide/usage/linter/rules/eslint/yoda.md index 80a62b0a5ee..86607b7f222 100644 --- a/src/docs/guide/usage/linter/rules/eslint/yoda.md +++ b/src/docs/guide/usage/linter/rules/eslint/yoda.md @@ -1,10 +1,5 @@ - - # eslint/yoda
@@ -13,12 +8,12 @@ const source = `https://github.com/oxc-project/oxc/blob/${ data }/crates/oxc_lin
-### What it does +## What it does Require or disallow "Yoda" conditions. This rule aims to enforce consistent style of conditions which compare a variable to a literal value. -### Why is this bad? +## Why is this bad? Yoda conditions are so named because the literal value of the condition comes first while the variable comes second. For example, the following is a Yoda condition: @@ -39,7 +34,7 @@ This typically reads, "if the color equals red", which is arguably a more natura Proponents of Yoda conditions highlight that it is impossible to mistakenly use `=` instead of `==` because you cannot assign to a literal value. Doing so will cause a syntax error and you will be informed of the mistake early on. This practice was therefore very common in early programming where tools were not yet available. Opponents of Yoda conditions point out that tooling has made us better programmers because tools will catch the mistaken use of `=` instead of `==` (ESLint will catch this for you). Therefore, they argue, the utility of the pattern doesn't outweigh the readability hit the code takes while using Yoda conditions. -### Options +## Options This rule can take a string option: @@ -50,7 +45,7 @@ This rule can take a string option: - If the `"onlyEquality"` property is `true`, the rule reports yoda conditions _only_ for the equality operators `==` and `===`. The default value is `false`. The `onlyEquality` option allows a superset of the exceptions which `exceptRange` allows, thus both options are not useful together. -#### never +### never Examples of **incorrect** code for the default `"never"` option: @@ -93,20 +88,20 @@ if (`${value}` === `red`) { } ``` -#### exceptRange +### exceptRange Examples of **correct** code for the `"never", { "exceptRange": true }` options: ```js function isReddish(color) { - return (color.hue < 60 || 300 < color.hue); + return color.hue < 60 || 300 < color.hue; } if (x < -1 || 1 < x) { // ... } -if (count < 10 && (0 <= rand && rand < 1)) { +if (count < 10 && 0 <= rand && rand < 1) { // ... } @@ -115,11 +110,11 @@ if (`blue` < x && x < `green`) { } function howLong(arr) { - return (0 <= arr.length && arr.length < 10) ? "short" : "long"; + return 0 <= arr.length && arr.length < 10 ? "short" : "long"; } ``` -#### onlyEquality +### onlyEquality Examples of **correct** code for the `"never", { "onlyEquality": true }` options: @@ -134,7 +129,7 @@ if (x !== `foo` && `bar` != x) { } ``` -#### always +### always Examples of **incorrect** code for the `"always"` option: @@ -168,26 +163,6 @@ if (-1 < str.indexOf(substr)) { } ``` -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny yoda -``` - -```json [Config (.oxlintrc.json)] -{ - "rules": { - "yoda": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/eslint/yoda.rs) diff --git a/src/docs/guide/usage/linter/rules/import/consistent-type-specifier-style.md b/src/docs/guide/usage/linter/rules/import/consistent-type-specifier-style.md deleted file mode 100644 index a0f6375cb2f..00000000000 --- a/src/docs/guide/usage/linter/rules/import/consistent-type-specifier-style.md +++ /dev/null @@ -1,79 +0,0 @@ - - - - -# import/consistent-type-specifier-style - -
- -πŸ› οΈ An auto-fix is available for this rule for some violations. - -
- -### What it does - -This rule either enforces or bans the use of inline type-only markers for named imports. - -### Why is this bad? - -Mixing top-level `import type { Foo } from 'foo'` with inline `{ type Bar }` -forces readers to mentally switch contexts when scanning your imports. -Enforcing one style makes it immediately obvious which imports are types and which are value imports. - -### Examples - -Examples of incorrect code for the default `prefer-top-level` option: - -```typescript -import { type Foo } from "Foo"; -import Foo, { type Bar } from "Foo"; -``` - -Examples of correct code for the default option: - -```typescript -import type { Foo } from "Foo"; -import type Foo, { Bar } from "Foo"; -``` - -Examples of incorrect code for the `prefer-inline` option: - -```typescript -import type { Foo } from "Foo"; -import type Foo, { Bar } from "Foo"; -``` - -Examples of correct code for the `prefer-inline` option: - -```typescript -import { type Foo } from "Foo"; -import Foo, { type Bar } from "Foo"; -``` - -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny import/consistent-type-specifier-style --import-plugin -``` - -```json [Config (.oxlintrc.json)] -{ - "plugins": ["import"], - "rules": { - "import/consistent-type-specifier-style": "error" - } -} -``` - -::: - -## References - -- Rule Source diff --git a/src/docs/guide/usage/linter/rules/import/default.md b/src/docs/guide/usage/linter/rules/import/default.md index 7d80e6651ef..3cacb33b8c9 100644 --- a/src/docs/guide/usage/linter/rules/import/default.md +++ b/src/docs/guide/usage/linter/rules/import/default.md @@ -1,10 +1,5 @@ - - # import/default
@@ -48,27 +43,6 @@ export default function bar() { import { bar } from "./bar"; // correct usage of named import ``` -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny import/default --import-plugin -``` - -```json [Config (.oxlintrc.json)] -{ - "plugins": ["import"], - "rules": { - "import/default": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/import/default.rs) diff --git a/src/docs/guide/usage/linter/rules/import/export.md b/src/docs/guide/usage/linter/rules/import/export.md index 3102fae623b..09045feaa8b 100644 --- a/src/docs/guide/usage/linter/rules/import/export.md +++ b/src/docs/guide/usage/linter/rules/import/export.md @@ -1,10 +1,5 @@ - - # import/export
@@ -38,27 +33,6 @@ export { foo as foo1 }; // Renamed export to avoid conflict export * from "./export-all"; // No conflict if export-all.js also exports foo ``` -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny import/export --import-plugin -``` - -```json [Config (.oxlintrc.json)] -{ - "plugins": ["import"], - "rules": { - "import/export": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/import/export.rs) diff --git a/src/docs/guide/usage/linter/rules/import/exports-last.md b/src/docs/guide/usage/linter/rules/import/exports-last.md deleted file mode 100644 index 5f426a7de0c..00000000000 --- a/src/docs/guide/usage/linter/rules/import/exports-last.md +++ /dev/null @@ -1,67 +0,0 @@ - - - - -# import/exports-last - -
-
- -### What it does - -This rule enforces that all exports are declared at the bottom of the file. -This rule will report any export declarations that comes before any non-export statements. - -### Why is this bad? - -Exports scattered throughout the file can lead to poor code readability -and increase the cost of locating the export quickly - -### Examples - -Examples of **incorrect** code for this rule: - -```js -const bool = true; -export const foo = "bar"; -const str = "foo"; -``` - -Examples of **correct** code for this rule: - -```js -const arr = ["bar"]; -export const bool = true; -export const str = "foo"; -export function func() { - console.log("Hello World"); -} -``` - -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny import/exports-last --import-plugin -``` - -```json [Config (.oxlintrc.json)] -{ - "plugins": ["import"], - "rules": { - "import/exports-last": "error" - } -} -``` - -::: - -## References - -- Rule Source diff --git a/src/docs/guide/usage/linter/rules/import/extensions.md b/src/docs/guide/usage/linter/rules/import/extensions.md deleted file mode 100644 index a0524e4a634..00000000000 --- a/src/docs/guide/usage/linter/rules/import/extensions.md +++ /dev/null @@ -1,91 +0,0 @@ - - - - -# import/extensions - -
-
- -### What it does - -Some file resolve algorithms allow you to omit the file extension within the import source path. -For example the node resolver (which does not yet support ESM/import) can resolve ./foo/bar to the absolute path /User/someone/foo/bar.js because the .js extension is resolved automatically by default in CJS. -Depending on the resolver you can configure more extensions to get resolved automatically. -In order to provide a consistent use of file extensions across your code base, this rule can enforce or disallow the use of certain file extensions. - -### Why is this bad? - -ESM-based file resolve algorithms (e.g., the one that Vite provides) recommend specifying the file extension to improve performance. - -### Examples - -Examples of **incorrect** code for this rule: - -The following patterns are considered problems when configuration set to "always": - -```js -import foo from "@/foo"; -import bar from "./bar"; -import Component from "./Component"; -import foo from "./foo"; -``` - -The following patterns are considered problems when configuration set to "never": - -```js -import express from "express/index.js"; -import bar from "./bar.json"; -import Component from "./Component.jsx"; -import foo from "./foo.js"; -``` - -Examples of **correct** code for this rule: - -The following patterns are not considered problems when configuration set to "always": - -```js -import foo from "@/foo.js"; -import * as path from "path"; -import bar from "./bar.json"; -import Component from "./Component.jsx"; -import foo from "./foo.js"; -``` - -The following patterns are not considered problems when configuration set to "never": - -```js -import express from "express/index"; -import * as path from "path"; -import bar from "./bar"; -import Component from "./Component"; -import foo from "./foo"; -``` - -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny import/extensions --import-plugin -``` - -```json [Config (.oxlintrc.json)] -{ - "plugins": ["import"], - "rules": { - "import/extensions": "error" - } -} -``` - -::: - -## References - -- Rule Source diff --git a/src/docs/guide/usage/linter/rules/import/first.md b/src/docs/guide/usage/linter/rules/import/first.md index d88f349d039..733d3f8dbbf 100644 --- a/src/docs/guide/usage/linter/rules/import/first.md +++ b/src/docs/guide/usage/linter/rules/import/first.md @@ -1,10 +1,5 @@ - - # import/first
@@ -37,8 +32,8 @@ import { y } from "./bar"; Examples of **correct** code for this rule: ```js -import { y } from "./bar"; import { x } from "./foo"; +import { y } from "./bar"; export { x, y }; ``` @@ -49,8 +44,8 @@ with `"absolute-first"`: Examples of **incorrect** code for this rule: ```js -import { y } from "bar"; import { x } from "./foo"; +import { y } from "bar"; ``` Examples of **correct** code for this rule: @@ -60,27 +55,6 @@ import { y } from "bar"; import { x } from "./foo"; ``` -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny import/first --import-plugin -``` - -```json [Config (.oxlintrc.json)] -{ - "plugins": ["import"], - "rules": { - "import/first": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/import/first.rs) diff --git a/src/docs/guide/usage/linter/rules/import/group-exports.md b/src/docs/guide/usage/linter/rules/import/group-exports.md deleted file mode 100644 index b4ba2489784..00000000000 --- a/src/docs/guide/usage/linter/rules/import/group-exports.md +++ /dev/null @@ -1,65 +0,0 @@ - - - - -# import/group-exports - -
-
- -### What it does - -Reports when named exports are not grouped together in a single export declaration -or when multiple assignments to CommonJS module.exports -or exports object are present in a single file. - -### Why is this bad? - -An export declaration or module.exports assignment can appear anywhere in the code. -By requiring a single export declaration all your exports will remain at one place, -making it easier to see what exports a module provides. - -### Examples - -Examples of **incorrect** code for this rule: - -```js -export const first = true; -export const second = true; -``` - -Examples of **correct** code for this rule: - -```js -const first = true; -const second = true; -export { first, second }; -``` - -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny import/group-exports --import-plugin -``` - -```json [Config (.oxlintrc.json)] -{ - "plugins": ["import"], - "rules": { - "import/group-exports": "error" - } -} -``` - -::: - -## References - -- Rule Source diff --git a/src/docs/guide/usage/linter/rules/import/max-dependencies.md b/src/docs/guide/usage/linter/rules/import/max-dependencies.md index f3d7b1e5445..ae874f283fa 100644 --- a/src/docs/guide/usage/linter/rules/import/max-dependencies.md +++ b/src/docs/guide/usage/linter/rules/import/max-dependencies.md @@ -1,10 +1,5 @@ - - # import/max-dependencies
@@ -39,27 +34,6 @@ import a from "./a"; import b from "./b"; // Allowed: 2 dependencies (max: 2) ``` -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny import/max-dependencies --import-plugin -``` - -```json [Config (.oxlintrc.json)] -{ - "plugins": ["import"], - "rules": { - "import/max-dependencies": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/import/max_dependencies.rs) diff --git a/src/docs/guide/usage/linter/rules/import/named.md b/src/docs/guide/usage/linter/rules/import/named.md index 2bc394f651c..0e26c5c7b9c 100644 --- a/src/docs/guide/usage/linter/rules/import/named.md +++ b/src/docs/guide/usage/linter/rules/import/named.md @@ -1,11 +1,6 @@ - - -# import/named +# import/named
@@ -71,27 +66,6 @@ export { foo as bar } from "./foo"; import { SomeNonsenseThatDoesntExist } from "react"; ``` -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny import/named --import-plugin -``` - -```json [Config (.oxlintrc.json)] -{ - "plugins": ["import"], - "rules": { - "import/named": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/import/named.rs) diff --git a/src/docs/guide/usage/linter/rules/import/namespace.md b/src/docs/guide/usage/linter/rules/import/namespace.md index 7ed0ea81d90..c75d5708f18 100644 --- a/src/docs/guide/usage/linter/rules/import/namespace.md +++ b/src/docs/guide/usage/linter/rules/import/namespace.md @@ -1,10 +1,5 @@ - - # import/namespace
@@ -63,39 +58,6 @@ const method = "bar"; foo[method](); // Valid: method refers to an exported function ``` -## Configuration - -This rule accepts a configuration object with the following properties: - -### allowComputed - -type: `boolean` - -default: `false` - -Whether to allow computed references to an imported namespace. - -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny import/namespace --import-plugin -``` - -```json [Config (.oxlintrc.json)] -{ - "plugins": ["import"], - "rules": { - "import/namespace": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/import/namespace.rs) diff --git a/src/docs/guide/usage/linter/rules/import/no-absolute-path.md b/src/docs/guide/usage/linter/rules/import/no-absolute-path.md deleted file mode 100644 index 6e29a03ebf7..00000000000 --- a/src/docs/guide/usage/linter/rules/import/no-absolute-path.md +++ /dev/null @@ -1,105 +0,0 @@ - - - - -# import/no-absolute-path - -
- -🚧 An auto-fix is still under development. - -
- -### What it does - -This rule forbids the import of modules using absolute paths. - -### Why is this bad? - -Node.js allows the import of modules using an absolute path such as `/home/xyz/file.js`. -That is a bad practice as it ties the code using it to your computer, -and therefore makes it unusable in packages distributed on npm for instance. - -### Examples - -Examples of **incorrect** code for this rule: - -```js -import f from "/foo"; -import f from "/some/path"; -var f = require("/foo"); -var f = require("/some/path"); -``` - -Examples of **correct** code for this rule: - -```js -import foo from "foo"; -import _ from "lodash"; -import foo from "./foo"; - -var _ = require("lodash"); -var foo = require("foo"); -var foo = require("./foo"); -``` - -Examples of **incorrect** code for the `{ amd: true }` option: - -```js -define("/foo", function(foo) {}); -require("/foo", function(foo) {}); -``` - -Examples of **correct** code for the `{ amd: true }` option: - -```js -define("./foo", function(foo) {}); -require("./foo", function(foo) {}); -``` - -### Options - -By default, only ES6 imports and `CommonJS` require calls will have this rule enforced. -You may provide an options object providing true/false for any of - -- `esmodule`: defaults to `true` -- `commonjs`: defaults to `true` -- `amd`: defaults to `false` - -If `{ amd: true }` is provided, dependency paths for AMD-style define and require calls will be resolved: - -```js -/*eslint import/no-absolute-path: ['error', { commonjs: false, amd: true }]*/ -define(["/foo"], function(foo) {/*...*/}); // reported -require(["/foo"], function(foo) {/*...*/}); // reported - -const foo = require("/foo"); // ignored because of explicit `commonjs: false` -``` - -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny import/no-absolute-path --import-plugin -``` - -```json [Config (.oxlintrc.json)] -{ - "plugins": ["import"], - "rules": { - "import/no-absolute-path": "error" - } -} -``` - -::: - -## References - -- Rule Source diff --git a/src/docs/guide/usage/linter/rules/import/no-amd.md b/src/docs/guide/usage/linter/rules/import/no-amd.md index de9130a51fc..6debbbd48ae 100644 --- a/src/docs/guide/usage/linter/rules/import/no-amd.md +++ b/src/docs/guide/usage/linter/rules/import/no-amd.md @@ -1,10 +1,5 @@ - - # import/no-amd
@@ -28,7 +23,7 @@ maintainability and consistency across the codebase. Examples of **incorrect** code for this rule: ```javascript -require([a, b], function() {}); +require([a, b], function () {}); ``` Examples of **correct** code for this rule: @@ -38,27 +33,6 @@ require("../name"); require(`../name`); ``` -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny import/no-amd --import-plugin -``` - -```json [Config (.oxlintrc.json)] -{ - "plugins": ["import"], - "rules": { - "import/no-amd": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/import/no_amd.rs) diff --git a/src/docs/guide/usage/linter/rules/import/no-anonymous-default-export.md b/src/docs/guide/usage/linter/rules/import/no-anonymous-default-export.md deleted file mode 100644 index 77a8f35feb9..00000000000 --- a/src/docs/guide/usage/linter/rules/import/no-anonymous-default-export.md +++ /dev/null @@ -1,121 +0,0 @@ - - - - -# import/no-anonymous-default-export - -
-
- -### What it does - -Reports if a module's default export is unnamed. -This includes several types of unnamed data types; -literals, object expressions, arrays, anonymous functions, arrow functions, -and anonymous class declarations. - -### Why is this bad? - -Ensuring that default exports are named helps improve the grepability of -the codebase by encouraging the re-use of the same identifier for -the module's default export at its declaration site and at its import sites. - -### Examples - -Examples of **incorrect** code for this rule: - -```js -export default []; -export default () => {}; -export default class {} -export default function() {} -export default foo(bar); -export default 123; -export default {}; -export default new Foo(); -export default `foo`; -export default /^123/; -``` - -Examples of **correct** code for this rule: - -```js -const foo = 123; -export default foo; -export default function foo() {} -export default class MyClass {} -export default function foo() {} -export default foo(bar); -/* eslint import/no-anonymous-default-export: ['error', {"allowLiteral": true}] */ -export default 123; -/* eslint import/no-anonymous-default-export: ['error, {"allowArray": true}] */ -export default []; -/* eslint import/no-anonymous-default-export: ['error, {"allowArrowFunction": true}] */ -export default () => {}; -/* eslint import/no-anonymous-default-export: ['error, {"allowAnonymousClass": true}] */ -export default class {} -/* eslint import/no-anonymous-default-export: ['error, {"allowAnonymousFunction": true}] */ -export default function() {} -/* eslint import/no-anonymous-default-export: ['error, {"allowObject": true}] */ -export default {}; -/* eslint import/no-anonymous-default-export: ['error, {"allowNew": true}] */ -export default new Foo(); -/* eslint import/no-anonymous-default-export: ['error, {"allowCallExpression": true}] */ -export default foo(bar); -``` - -### Options - -This rule takes an object with the following properties: - -- `allowArray`: `boolean` (default: `false`) - Allow anonymous array as default export. -- `allowArrowFunction`: `boolean` (default: `false`) - Allow anonymous arrow function as default export. -- `allowAnonymousClass`: `boolean` (default: `false`) - Allow anonymous class as default export. -- `allowAnonymousFunction`: `boolean` (default: `false`) - Allow anonymous function as default export. -- `allowCallExpression`: `boolean` (default: `true`) - Allow anonymous call expression as default export. -- `allowNew`: `boolean` (default: `false`) - Allow anonymous new expression as default export. -- `allowLiteral`: `boolean` (default: `false`) - Allow anonymous literal as default export. -- `allowObject`: `boolean` (default: `false`) - Allow anonymous object as default export. - -By default, all types of anonymous default exports are forbidden, -but any types can be selectively allowed by toggling them on in the options. - -```json -"import/no-anonymous-default-export": ["error", { - "allowArray": false, - "allowArrowFunction": false, - "allowAnonymousClass": false, - "allowAnonymousFunction": false, - "allowCallExpression": true, - "allowNew": false, - "allowLiteral": false, - "allowObject": false -``` - -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny import/no-anonymous-default-export --import-plugin -``` - -```json [Config (.oxlintrc.json)] -{ - "plugins": ["import"], - "rules": { - "import/no-anonymous-default-export": "error" - } -} -``` - -::: - -## References - -- Rule Source diff --git a/src/docs/guide/usage/linter/rules/import/no-commonjs.md b/src/docs/guide/usage/linter/rules/import/no-commonjs.md index f98c3e0a438..dd1f1a4d531 100644 --- a/src/docs/guide/usage/linter/rules/import/no-commonjs.md +++ b/src/docs/guide/usage/linter/rules/import/no-commonjs.md @@ -1,10 +1,5 @@ - - # import/no-commonjs
@@ -28,7 +23,7 @@ var mod = require("fs"); var exports = (module.exports = {}); -exports.sayHello = function() { +exports.sayHello = function () { return "Hello"; }; @@ -71,7 +66,9 @@ If `allowPrimitiveModules` option is set to true, the following is valid: ```js module.exports = "foo"; module.exports = function rule(context) { - return {/* ... */}; + return { + /* ... */ + }; }; ``` @@ -79,30 +76,11 @@ but this is still reported: ```js module.exports = { x: "y" }; -exports.z = function bark() {/* ... */}; -``` - -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny import/no-commonjs --import-plugin -``` - -```json [Config (.oxlintrc.json)] -{ - "plugins": ["import"], - "rules": { - "import/no-commonjs": "error" - } -} +exports.z = function bark() { + /* ... */ +}; ``` -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/import/no_commonjs.rs) diff --git a/src/docs/guide/usage/linter/rules/import/no-cycle.md b/src/docs/guide/usage/linter/rules/import/no-cycle.md index ab6b94d0faa..018e3120d16 100644 --- a/src/docs/guide/usage/linter/rules/import/no-cycle.md +++ b/src/docs/guide/usage/linter/rules/import/no-cycle.md @@ -1,10 +1,5 @@ - - # import/no-cycle
@@ -29,13 +24,17 @@ Examples of **incorrect** code for this rule: ```javascript // dep-b.js import "./dep-a.js"; -export function b() {/* ... */} +export function b() { + /* ... */ +} ``` ```javascript // dep-a.js import { b } from "./dep-b.js"; // reported: Dependency cycle detected. -export function a() {/* ... */} +export function a() { + /* ... */ +} ``` In this example, `dep-a.js` and `dep-b.js` import each other, creating a circular @@ -45,38 +44,21 @@ Examples of **correct** code for this rule: ```javascript // dep-b.js -export function b() {/* ... */} +export function b() { + /* ... */ +} ``` ```javascript // dep-a.js import { b } from "./dep-b.js"; // no circular dependency -export function a() {/* ... */} -``` - -In this corrected version, `dep-b.js` no longer imports `dep-a.js`, breaking the cycle. - -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny import/no-cycle --import-plugin -``` - -```json [Config (.oxlintrc.json)] -{ - "plugins": ["import"], - "rules": { - "import/no-cycle": "error" - } +export function a() { + /* ... */ } ``` -::: +In this corrected version, `dep-b.js` no longer imports `dep-a.js`, breaking the cycle. ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/import/no_cycle.rs) diff --git a/src/docs/guide/usage/linter/rules/import/no-default-export.md b/src/docs/guide/usage/linter/rules/import/no-default-export.md index 0802d44f3cd..ab27e3bad0f 100644 --- a/src/docs/guide/usage/linter/rules/import/no-default-export.md +++ b/src/docs/guide/usage/linter/rules/import/no-default-export.md @@ -1,10 +1,5 @@ - - # import/no-default-export
@@ -27,10 +22,10 @@ auto-imports less reliable. Examples of **incorrect** code for this rule: ```javascript -export default "bar"; +export default 'bar'; -const foo = "foo"; -export { foo as default }; +const foo = 'foo'; +export { foo as default } ``` Examples of **correct** code for this rule: @@ -40,27 +35,6 @@ export const foo = "foo"; export const bar = "bar"; ``` -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny import/no-default-export --import-plugin -``` - -```json [Config (.oxlintrc.json)] -{ - "plugins": ["import"], - "rules": { - "import/no-default-export": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/import/no_default_export.rs) diff --git a/src/docs/guide/usage/linter/rules/import/no-duplicates.md b/src/docs/guide/usage/linter/rules/import/no-duplicates.md index a0d240abf5a..0fc17f7b159 100644 --- a/src/docs/guide/usage/linter/rules/import/no-duplicates.md +++ b/src/docs/guide/usage/linter/rules/import/no-duplicates.md @@ -1,11 +1,6 @@ - - -# import/no-duplicates +# import/no-duplicates
@@ -36,7 +31,7 @@ import { b } from "./module"; Examples of **correct** code for this rule: ```typescript -import { bar, foo } from "./module"; +import { foo, bar } from "./module"; import * as a from "foo"; // separate statements for namespace imports import { b } from "foo"; @@ -45,27 +40,6 @@ import { c } from "foo"; // separate type imports, unless import type { d } from "foo"; // `preferInline` is true ``` -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny import/no-duplicates --import-plugin -``` - -```json [Config (.oxlintrc.json)] -{ - "plugins": ["import"], - "rules": { - "import/no-duplicates": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/import/no_duplicates.rs) diff --git a/src/docs/guide/usage/linter/rules/import/no-dynamic-require.md b/src/docs/guide/usage/linter/rules/import/no-dynamic-require.md index b950ee83345..7c1795fc954 100644 --- a/src/docs/guide/usage/linter/rules/import/no-dynamic-require.md +++ b/src/docs/guide/usage/linter/rules/import/no-dynamic-require.md @@ -1,10 +1,5 @@ - - # import/no-dynamic-require
@@ -38,27 +33,6 @@ require("../name"); require(`../name`); ``` -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny import/no-dynamic-require --import-plugin -``` - -```json [Config (.oxlintrc.json)] -{ - "plugins": ["import"], - "rules": { - "import/no-dynamic-require": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/import/no_dynamic_require.rs) diff --git a/src/docs/guide/usage/linter/rules/import/no-empty-named-blocks.md b/src/docs/guide/usage/linter/rules/import/no-empty-named-blocks.md deleted file mode 100644 index 94b5a427b0a..00000000000 --- a/src/docs/guide/usage/linter/rules/import/no-empty-named-blocks.md +++ /dev/null @@ -1,64 +0,0 @@ - - - - -# import/no-empty-named-blocks - -
- -πŸ› οΈ An auto-fix is available for this rule. - -
- -### What it does - -Enforces that named import blocks are not empty. - -### Why is this bad? - -Empty named imports serve no practical purpose and often -result from accidental deletions or tool-generated code. - -### Examples - -Examples of **incorrect** code for this rule: - -```js -import {} from "mod"; -import Default, {} from "mod"; -``` - -Examples of **correct** code for this rule: - -```js -import { mod } from "mod"; -import Default, { mod } from "mod"; -``` - -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny import/no-empty-named-blocks --import-plugin -``` - -```json [Config (.oxlintrc.json)] -{ - "plugins": ["import"], - "rules": { - "import/no-empty-named-blocks": "error" - } -} -``` - -::: - -## References - -- Rule Source diff --git a/src/docs/guide/usage/linter/rules/import/no-mutable-exports.md b/src/docs/guide/usage/linter/rules/import/no-mutable-exports.md deleted file mode 100644 index 2bbb6df5845..00000000000 --- a/src/docs/guide/usage/linter/rules/import/no-mutable-exports.md +++ /dev/null @@ -1,69 +0,0 @@ - - - - -# import/no-mutable-exports - -
-
- -### What it does - -Forbids the use of mutable exports with var or let. - -### Why is this bad? - -In general, we should always export constants - -### Examples - -Examples of **incorrect** code for this rule: - -```js -export let count = 2; -export var count = 3; - -let count = 4; -export { count }; -``` - -Examples of **correct** code for this rule: - -```js -export const count = 1; -export function getCount() {} -export class Counter {} -``` - -### Functions/Classes - -Note that exported function/class declaration identifiers may be reassigned, -but are not flagged by this rule at this time. They may be in the future. - -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny import/no-mutable-exports --import-plugin -``` - -```json [Config (.oxlintrc.json)] -{ - "plugins": ["import"], - "rules": { - "import/no-mutable-exports": "error" - } -} -``` - -::: - -## References - -- Rule Source diff --git a/src/docs/guide/usage/linter/rules/import/no-named-as-default-member.md b/src/docs/guide/usage/linter/rules/import/no-named-as-default-member.md index e0882baccda..410945aed32 100644 --- a/src/docs/guide/usage/linter/rules/import/no-named-as-default-member.md +++ b/src/docs/guide/usage/linter/rules/import/no-named-as-default-member.md @@ -1,10 +1,5 @@ - - # import/no-named-as-default-member
@@ -52,27 +47,6 @@ Examples of **correct** code for this rule: import { bar } from "./bar"; // Correct: accessing named export directly ``` -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny import/no-named-as-default-member --import-plugin -``` - -```json [Config (.oxlintrc.json)] -{ - "plugins": ["import"], - "rules": { - "import/no-named-as-default-member": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/import/no_named_as_default_member.rs) diff --git a/src/docs/guide/usage/linter/rules/import/no-named-as-default.md b/src/docs/guide/usage/linter/rules/import/no-named-as-default.md index 35931089779..6e38e0a9b44 100644 --- a/src/docs/guide/usage/linter/rules/import/no-named-as-default.md +++ b/src/docs/guide/usage/linter/rules/import/no-named-as-default.md @@ -1,10 +1,5 @@ - - # import/no-named-as-default
@@ -47,27 +42,6 @@ Examples of **correct** code for this rule: import foo from "./foo.js"; ``` -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny import/no-named-as-default --import-plugin -``` - -```json [Config (.oxlintrc.json)] -{ - "plugins": ["import"], - "rules": { - "import/no-named-as-default": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/import/no_named_as_default.rs) diff --git a/src/docs/guide/usage/linter/rules/import/no-named-default.md b/src/docs/guide/usage/linter/rules/import/no-named-default.md deleted file mode 100644 index b808539e18e..00000000000 --- a/src/docs/guide/usage/linter/rules/import/no-named-default.md +++ /dev/null @@ -1,61 +0,0 @@ - - - - -# import/no-named-default - -
-
- -### What it does - -Reports use of a default export as a locally named import. - -### Why is this bad? - -Rationale: the syntax exists to import default exports expressively, let's use it. - -### Examples - -Examples of **incorrect** code for this rule: - -```js -// message: Using exported name 'bar' as identifier for default export. -import { default as foo } from "./foo.js"; -import { bar, default as foo } from "./foo.js"; -``` - -Examples of **correct** code for this rule: - -```js -import foo from "./foo.js"; -import foo, { bar } from "./foo.js"; -``` - -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny import/no-named-default --import-plugin -``` - -```json [Config (.oxlintrc.json)] -{ - "plugins": ["import"], - "rules": { - "import/no-named-default": "error" - } -} -``` - -::: - -## References - -- Rule Source diff --git a/src/docs/guide/usage/linter/rules/import/no-named-export.md b/src/docs/guide/usage/linter/rules/import/no-named-export.md deleted file mode 100644 index 020e41aed97..00000000000 --- a/src/docs/guide/usage/linter/rules/import/no-named-export.md +++ /dev/null @@ -1,65 +0,0 @@ - - - - -# import/no-named-export - -
-
- -### What it does - -Prohibit named exports. - -### Why is this bad? - -Named exports require strict identifier matching and can lead to fragile imports, -while default exports enforce a single, consistent module entry point. - -### Examples - -Examples of **incorrect** code for this rule: - -```js -export const foo = "foo"; - -const bar = "bar"; -export { bar }; -``` - -Examples of **correct** code for this rule: - -```js -export default "bar"; - -const foo = "foo"; -export { foo as default }; -``` - -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny import/no-named-export --import-plugin -``` - -```json [Config (.oxlintrc.json)] -{ - "plugins": ["import"], - "rules": { - "import/no-named-export": "error" - } -} -``` - -::: - -## References - -- Rule Source diff --git a/src/docs/guide/usage/linter/rules/import/no-namespace.md b/src/docs/guide/usage/linter/rules/import/no-namespace.md index 50c9683ec85..64a7267eddc 100644 --- a/src/docs/guide/usage/linter/rules/import/no-namespace.md +++ b/src/docs/guide/usage/linter/rules/import/no-namespace.md @@ -1,10 +1,5 @@ - - # import/no-namespace
@@ -15,7 +10,7 @@ const source = `https://github.com/oxc-project/oxc/blob/${ data }/crates/oxc_lin ### What it does -Enforce a convention of not using namespaced (a.k.a. "wildcard" *) imports. +Enforce a convention of not using namespaced (a.k.a. "wildcard" \*) imports. ### Why is this bad? @@ -42,7 +37,7 @@ Namespaced imports, while sometimes used, are generally considered less ideal in ```json { - "ignore": ["*.json"] + "ignores": ["*.json"] } ``` @@ -65,27 +60,6 @@ import user from "user-lib"; import defaultExport, { isUser } from "./user"; ``` -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny import/no-namespace --import-plugin -``` - -```json [Config (.oxlintrc.json)] -{ - "plugins": ["import"], - "rules": { - "import/no-namespace": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/import/no_namespace.rs) diff --git a/src/docs/guide/usage/linter/rules/import/no-self-import.md b/src/docs/guide/usage/linter/rules/import/no-self-import.md index f8b0e71735c..a3cd7da26f5 100644 --- a/src/docs/guide/usage/linter/rules/import/no-self-import.md +++ b/src/docs/guide/usage/linter/rules/import/no-self-import.md @@ -1,10 +1,5 @@ - - # import/no-self-import
@@ -37,27 +32,6 @@ Examples of **correct** code for this rule: import bar from "./bar.js"; // Correct: module imports another module ``` -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny import/no-self-import --import-plugin -``` - -```json [Config (.oxlintrc.json)] -{ - "plugins": ["import"], - "rules": { - "import/no-self-import": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/import/no_self_import.rs) diff --git a/src/docs/guide/usage/linter/rules/import/no-unassigned-import.md b/src/docs/guide/usage/linter/rules/import/no-unassigned-import.md deleted file mode 100644 index baa1ccbc2e2..00000000000 --- a/src/docs/guide/usage/linter/rules/import/no-unassigned-import.md +++ /dev/null @@ -1,73 +0,0 @@ - - - - -# import/no-unassigned-import - -
-
- -### What it does - -This rule aims to remove modules with side-effects by reporting when a module is imported but not assigned. - -### Why is this bad? - -With both CommonJS' require and the ES6 modules' import syntax, -it is possible to import a module but not to use its result. -This can be done explicitly by not assigning the module to a variable. -Doing so can mean either of the following things: - -- The module is imported but not used -- The module has side-effects. Having side-effects, - makes it hard to know whether the module is actually used or can be removed. - It can also make it harder to test or mock parts of your application. - -### Examples - -Examples of **incorrect** code for this rule: - -```js -import "should"; -require("should"); -``` - -Examples of **correct** code for this rule: - -```js -import _ from "foo"; -import _, { foo } from "foo"; -import _, { foo as bar } from "foo"; -const _ = require("foo"); -const { foo } = require("foo"); -const { foo: bar } = require("foo"); -bar(require("foo")); -``` - -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny import/no-unassigned-import --import-plugin -``` - -```json [Config (.oxlintrc.json)] -{ - "plugins": ["import"], - "rules": { - "import/no-unassigned-import": "error" - } -} -``` - -::: - -## References - -- Rule Source diff --git a/src/docs/guide/usage/linter/rules/import/no-webpack-loader-syntax.md b/src/docs/guide/usage/linter/rules/import/no-webpack-loader-syntax.md index 58c77a606ec..8954779aa2c 100644 --- a/src/docs/guide/usage/linter/rules/import/no-webpack-loader-syntax.md +++ b/src/docs/guide/usage/linter/rules/import/no-webpack-loader-syntax.md @@ -1,10 +1,5 @@ - - # import/no-webpack-loader-syntax
@@ -41,27 +36,6 @@ var myModule = require("./my-module"); var theme = require("./theme.css"); ``` -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny import/no-webpack-loader-syntax --import-plugin -``` - -```json [Config (.oxlintrc.json)] -{ - "plugins": ["import"], - "rules": { - "import/no-webpack-loader-syntax": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/import/no_webpack_loader_syntax.rs) diff --git a/src/docs/guide/usage/linter/rules/import/prefer-default-export.md b/src/docs/guide/usage/linter/rules/import/prefer-default-export.md deleted file mode 100644 index 0866f680612..00000000000 --- a/src/docs/guide/usage/linter/rules/import/prefer-default-export.md +++ /dev/null @@ -1,74 +0,0 @@ - - - - -# import/prefer-default-export - -
-
- -### What it does - -In exporting files, this rule checks if there is default export or not. - -### Why is this bad? - -This rule exists to standardize module exports by preferring default exports -when a module only has one export, enhancing readability, maintainability. - -### Examples - -Examples of **incorrect** code for the `{ target: "single" }` option: - -```js -export const foo = "foo"; -``` - -Examples of **correct** code for the `{ target: "single" }` option: - -```js -export const foo = "foo"; -const bar = "bar"; -export default bar; -``` - -Examples of **incorrect** code for the `{ target: "any" }` option: - -```js -export const foo = "foo"; -export const baz = "baz"; -``` - -Examples of **correct** code for the `{ target: "any" }` option: - -```js -export default function bar() {} -``` - -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny import/prefer-default-export --import-plugin -``` - -```json [Config (.oxlintrc.json)] -{ - "plugins": ["import"], - "rules": { - "import/prefer-default-export": "error" - } -} -``` - -::: - -## References - -- Rule Source diff --git a/src/docs/guide/usage/linter/rules/import/unambiguous.md b/src/docs/guide/usage/linter/rules/import/unambiguous.md index 5a208726415..0663e6dafff 100644 --- a/src/docs/guide/usage/linter/rules/import/unambiguous.md +++ b/src/docs/guide/usage/linter/rules/import/unambiguous.md @@ -1,10 +1,5 @@ - - # import/unambiguous
@@ -48,27 +43,6 @@ export function x() { export {}; // simple way to mark side-effects-only file as 'module' without any imports/exports ``` -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny import/unambiguous --import-plugin -``` - -```json [Config (.oxlintrc.json)] -{ - "plugins": ["import"], - "rules": { - "import/unambiguous": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/import/unambiguous.rs) diff --git a/src/docs/guide/usage/linter/rules/jest/consistent-test-it.md b/src/docs/guide/usage/linter/rules/jest/consistent-test-it.md index f891d981539..bff08ed289b 100644 --- a/src/docs/guide/usage/linter/rules/jest/consistent-test-it.md +++ b/src/docs/guide/usage/linter/rules/jest/consistent-test-it.md @@ -1,10 +1,5 @@ - - # jest/consistent-test-it
@@ -25,7 +20,7 @@ the `test` keywords, with multiple permutations for each: It's a good practice to be consistent in your test suite, so that all tests are written in the same way. -### Examples +### Example ```javascript /*eslint jest/consistent-test-it: ["error", {"fn": "test"}]*/ @@ -47,12 +42,12 @@ test.only("foo"); // invalid ```javascript /*eslint jest/consistent-test-it: ["error", {"fn": "it", "withinDescribe": "test"}]*/ it("foo"); // valid -describe("foo", function() { +describe("foo", function () { test("bar"); // valid }); test("foo"); // invalid -describe("foo", function() { +describe("foo", function () { it("bar"); // invalid }); ``` @@ -63,16 +58,16 @@ This rule can be configured as follows ```json5 { - type: 'object', - properties: { - fn: { - enum: ['it', 'test'], - }, - withinDescribe: { - enum: ['it', 'test'], - }, + type: "object", + properties: { + fn: { + enum: ["it", "test"], + }, + withinDescribe: { + enum: ["it", "test"], }, - additionalProperties: false, + }, + additionalProperties: false, } ``` @@ -90,32 +85,11 @@ to use it, add the following configuration to your `.eslintrc.json`: ```json { "rules": { - "vitest/consistent-test-it": "error" - } -} -``` - -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny jest/consistent-test-it --jest-plugin -``` - -```json [Config (.oxlintrc.json)] -{ - "plugins": ["jest"], - "rules": { - "jest/consistent-test-it": "error" + "vitest/consistent-test-it": "error" } } -``` -::: ## References - -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/jest/consistent_test_it.rs) +``` diff --git a/src/docs/guide/usage/linter/rules/jest/expect-expect.md b/src/docs/guide/usage/linter/rules/jest/expect-expect.md index 350c9622361..49600e612f7 100644 --- a/src/docs/guide/usage/linter/rules/jest/expect-expect.md +++ b/src/docs/guide/usage/linter/rules/jest/expect-expect.md @@ -1,10 +1,5 @@ - - # jest/expect-expect
@@ -18,9 +13,7 @@ This rule triggers when there is no call made to `expect` in a test, ensure that People may forget to add assertions. -### Examples - -Examples of **incorrect** code for this rule: +### Example ```javascript it("should be a test", () => { @@ -40,27 +33,6 @@ to use it, add the following configuration to your `.eslintrc.json`: } ``` -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny jest/expect-expect --jest-plugin -``` - -```json [Config (.oxlintrc.json)] -{ - "plugins": ["jest"], - "rules": { - "jest/expect-expect": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/jest/expect_expect.rs) diff --git a/src/docs/guide/usage/linter/rules/jest/max-expects.md b/src/docs/guide/usage/linter/rules/jest/max-expects.md index e13adf09e5d..41570f149c4 100644 --- a/src/docs/guide/usage/linter/rules/jest/max-expects.md +++ b/src/docs/guide/usage/linter/rules/jest/max-expects.md @@ -1,10 +1,5 @@ - - # jest/max-expects
@@ -19,11 +14,9 @@ the maximum number of assertions is exceeded. ### Why is this bad? This rule enforces a maximum number of `expect()` calls. -The following patterns are considered warnings (with the default option of `{ "max": 5 }`): - -### Examples +The following patterns are considered warnings (with the default option of `{ "max": 5 } `): -Examples of **incorrect** code for this rule: +### Example ```javascript test("should not pass", () => { @@ -45,27 +38,6 @@ it("should not pass", () => { }); ``` -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny jest/max-expects --jest-plugin -``` - -```json [Config (.oxlintrc.json)] -{ - "plugins": ["jest"], - "rules": { - "jest/max-expects": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/jest/max_expects.rs) diff --git a/src/docs/guide/usage/linter/rules/jest/max-nested-describe.md b/src/docs/guide/usage/linter/rules/jest/max-nested-describe.md index 3b3380e5e90..4100af57059 100644 --- a/src/docs/guide/usage/linter/rules/jest/max-nested-describe.md +++ b/src/docs/guide/usage/linter/rules/jest/max-nested-describe.md @@ -1,10 +1,5 @@ - - # jest/max-nested-describe
@@ -21,9 +16,9 @@ Nesting `describe()` blocks too deeply can make the test suite hard to read and ### Example The following patterns are considered warnings (with the default option of -`{ "max": 5 }`): +`{ "max": 5 } `): -Examples of **incorrect** code for this rule: +/// /// Examples of **incorrect** code for this rule: ```javascript describe("foo", () => { @@ -42,12 +37,12 @@ describe("foo", () => { }); }); -describe("foo", function() { - describe("bar", function() { - describe("baz", function() { - describe("qux", function() { - describe("quxx", function() { - describe("too many", function() { +describe("foo", function () { + describe("bar", function () { + describe("baz", function () { + describe("qux", function () { + describe("quxx", function () { + describe("too many", function () { it("should get something", () => { expect(getSomething()).toBe("Something"); }); @@ -75,17 +70,17 @@ describe("foo", () => { }); }); -describe("foo2", function() { +describe("foo2", function () { it("should get something", () => { expect(getSomething()).toBe("Something"); }); }); -describe("foo", function() { - describe("bar", function() { - describe("baz", function() { - describe("qux", function() { - describe("this is the limit", function() { +describe("foo", function () { + describe("bar", function () { + describe("baz", function () { + describe("qux", function () { + describe("this is the limit", function () { it("should get something", () => { expect(getSomething()).toBe("Something"); }); @@ -96,39 +91,6 @@ describe("foo", function() { }); ``` -## Configuration - -This rule accepts a configuration object with the following properties: - -### max - -type: `integer` - -default: `5` - -Maximum allowed depth of nested describe calls. - -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny jest/max-nested-describe --jest-plugin -``` - -```json [Config (.oxlintrc.json)] -{ - "plugins": ["jest"], - "rules": { - "jest/max-nested-describe": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/jest/max_nested_describe.rs) diff --git a/src/docs/guide/usage/linter/rules/jest/no-alias-methods.md b/src/docs/guide/usage/linter/rules/jest/no-alias-methods.md index 954f55b133c..a8c650f581a 100644 --- a/src/docs/guide/usage/linter/rules/jest/no-alias-methods.md +++ b/src/docs/guide/usage/linter/rules/jest/no-alias-methods.md @@ -1,10 +1,5 @@ - - # jest/no-alias-methods
@@ -20,11 +15,9 @@ This rule ensures that only the canonical name as used in the Jest documentation ### Why is this bad? These aliases are going to be removed in the next major version of Jest - see [jestjs/jest#13164](https://github.com/jestjs/jest/issues/13164) for more. -This rule will make it easier to search for all occurrences of the method within code, and it ensures consistency among the method names used. - -### Examples +This rule will makes it easier to search for all occurrences of the method within code, and it ensures consistency among the method names used. -Examples of **incorrect** code for this rule: +### Example ```javascript expect(a).toBeCalled(); @@ -40,22 +33,6 @@ expect(a).nthReturnedWith(); expect(a).toThrowError(); ``` -Examples of **correct** code for this rule: - -```javascript -expect(a).toHaveBeenCalled(); -expect(a).toHaveBeenCalledTimes(); -expect(a).toHaveBeenCalledWith(); -expect(a).toHaveBeenLastCalledWith(); -expect(a).toHaveBeenNthCalledWith(); -expect(a).toHaveReturned(); -expect(a).toHaveReturnedTimes(); -expect(a).toHaveReturnedWith(); -expect(a).toHaveLastReturnedWith(); -expect(a).toHaveNthReturnedWith(); -expect(a).toThrow(); -``` - This rule is compatible with [eslint-plugin-vitest](https://github.com/veritem/eslint-plugin-vitest/blob/v1.1.9/docs/rules/no-alias-methods.md), to use it, add the following configuration to your `.eslintrc.json`: @@ -67,53 +44,6 @@ to use it, add the following configuration to your `.eslintrc.json`: } ``` -Examples of **incorrect** code for this rule with vitest: - -```javascript -expect(a).toBeCalled(); -expect(a).toBeCalledTimes(); -expect(a).not["toThrowError"](); -``` - -Examples of **correct** code for this rule with vitest: - -```javascript -expect(a).toHaveBeenCalled(); -expect(a).toHaveBeenCalledTimes(); -expect(a).toHaveBeenCalledWith(); -expect(a).toHaveBeenLastCalledWith(); -expect(a).toHaveBeenNthCalledWith(); -expect(a).toHaveReturned(); -expect(a).toHaveReturnedTimes(); -expect(a).toHaveReturnedWith(); -expect(a).toHaveLastReturnedWith(); -expect(a).toHaveNthReturnedWith(); -expect(a).toThrow(); -expect(a).rejects; -expect(a); -``` - -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny jest/no-alias-methods --jest-plugin -``` - -```json [Config (.oxlintrc.json)] -{ - "plugins": ["jest"], - "rules": { - "jest/no-alias-methods": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/jest/no_alias_methods.rs) diff --git a/src/docs/guide/usage/linter/rules/jest/no-commented-out-tests.md b/src/docs/guide/usage/linter/rules/jest/no-commented-out-tests.md index d4e261dbb98..8b3ce384a96 100644 --- a/src/docs/guide/usage/linter/rules/jest/no-commented-out-tests.md +++ b/src/docs/guide/usage/linter/rules/jest/no-commented-out-tests.md @@ -1,10 +1,5 @@ - - # jest/no-commented-out-tests
@@ -20,9 +15,7 @@ no-disabled-tests rule. You may forget to uncomment some tests. This rule raises a warning about commented out tests. It's similar to no-disabled-tests rule. -### Examples - -Examples of **incorrect** code for this rule: +### Example ```javascript // describe('foo', () => {}); @@ -45,27 +38,6 @@ to use it, add the following configuration to your `.eslintrc.json`: } ``` -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny jest/no-commented-out-tests --jest-plugin -``` - -```json [Config (.oxlintrc.json)] -{ - "plugins": ["jest"], - "rules": { - "jest/no-commented-out-tests": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/jest/no_commented_out_tests.rs) diff --git a/src/docs/guide/usage/linter/rules/jest/no-conditional-expect.md b/src/docs/guide/usage/linter/rules/jest/no-conditional-expect.md index 2df0023e22e..4d708eb44e9 100644 --- a/src/docs/guide/usage/linter/rules/jest/no-conditional-expect.md +++ b/src/docs/guide/usage/linter/rules/jest/no-conditional-expect.md @@ -1,10 +1,5 @@ - - # jest/no-conditional-expect
@@ -17,17 +12,12 @@ This includes using expect in callbacks to functions named catch, which are assu ### Why is this bad? -Jest only considers a test to have failed if it throws an error, meaning if calls to -assertion functions like expect occur in conditional code such as a catch statement, -tests can end up passing but not actually test anything. Additionally, conditionals -tend to make tests more brittle and complex, as they increase the amount of mental -thinking needed to understand what is actually being tested. - -### Examples +Jest only considers a test to have failed if it throws an error, meaning if calls to assertion functions like expect occur in conditional code such as a catch statement, tests can end up passing but not actually test anything. +Additionally, conditionals tend to make tests more brittle and complex, as they increase the amount of mental thinking needed to understand what is actually being tested. -Examples of **incorrect** code for this rule: +### Example -```js +```javascript it("foo", () => { doTest && expect(1).toBe(2); }); @@ -38,72 +28,22 @@ it("bar", () => { } }); -it("baz", async () => { - try { - await foo(); - } catch (err) { - expect(err).toMatchObject({ code: "MODULE_NOT_FOUND" }); - } -}); - it("throws an error", async () => { - await foo().catch(error => expect(error).toBeInstanceOf(error)); + await foo().catch((error) => expect(error).toBeInstanceOf(error)); }); ``` -Examples of **correct** code for this rule: - -```js -it("foo", () => { - expect(!value).toBe(false); -}); - -function getValue() { - if (process.env.FAIL) { - return 1; - } - return 2; -} - -it("foo", () => { - expect(getValue()).toBe(2); -}); +This rule is compatible with [eslint-plugin-vitest](https://github.com/veritem/eslint-plugin-vitest/blob/v1.1.9/docs/rules/no-conditional-expect.md), +to use it, add the following configuration to your `.eslintrc.json`: -it("validates the request", () => { - try { - processRequest(request); - } catch { - } finally { - expect(validRequest).toHaveBeenCalledWith(request); - } -}); - -it("throws an error", async () => { - await expect(foo).rejects.toThrow(Error); -}); -``` - -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny jest/no-conditional-expect --jest-plugin -``` - -```json [Config (.oxlintrc.json)] +```json { - "plugins": ["jest"], "rules": { - "jest/no-conditional-expect": "error" + "vitest/no-conditional-expect": "error" } } ``` -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/jest/no_conditional_expect.rs) diff --git a/src/docs/guide/usage/linter/rules/jest/no-conditional-in-test.md b/src/docs/guide/usage/linter/rules/jest/no-conditional-in-test.md index be03f6c5c05..53e34461702 100644 --- a/src/docs/guide/usage/linter/rules/jest/no-conditional-in-test.md +++ b/src/docs/guide/usage/linter/rules/jest/no-conditional-in-test.md @@ -1,10 +1,5 @@ - - # jest/no-conditional-in-test
@@ -44,9 +39,7 @@ it("bar", () => { it("baz", async () => { const promiseValue = () => { - return something instanceof Promise - ? something - : Promise.resolve(something); + return something instanceof Promise ? something : Promise.resolve(something); }; await expect(promiseValue()).resolves.toBe(1); @@ -79,7 +72,7 @@ it("bar", () => { expect(fixtures.length).toBeGreaterThan(-1); }); -const promiseValue = something => { +const promiseValue = (something) => { return something instanceof Promise ? something : Promise.resolve(something); }; @@ -88,27 +81,6 @@ it("baz", async () => { }); ``` -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny jest/no-conditional-in-test --jest-plugin -``` - -```json [Config (.oxlintrc.json)] -{ - "plugins": ["jest"], - "rules": { - "jest/no-conditional-in-test": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/jest/no_conditional_in_test.rs) diff --git a/src/docs/guide/usage/linter/rules/jest/no-confusing-set-timeout.md b/src/docs/guide/usage/linter/rules/jest/no-confusing-set-timeout.md index 1afd9a3ed4e..23e2d01544d 100644 --- a/src/docs/guide/usage/linter/rules/jest/no-confusing-set-timeout.md +++ b/src/docs/guide/usage/linter/rules/jest/no-confusing-set-timeout.md @@ -1,10 +1,5 @@ - - # jest/no-confusing-set-timeout
@@ -50,27 +45,6 @@ describe("unit test", () => { }); ``` -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny jest/no-confusing-set-timeout --jest-plugin -``` - -```json [Config (.oxlintrc.json)] -{ - "plugins": ["jest"], - "rules": { - "jest/no-confusing-set-timeout": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/jest/no_confusing_set_timeout.rs) diff --git a/src/docs/guide/usage/linter/rules/jest/no-deprecated-functions.md b/src/docs/guide/usage/linter/rules/jest/no-deprecated-functions.md index e346c0ea448..ffe6ecc1a6a 100644 --- a/src/docs/guide/usage/linter/rules/jest/no-deprecated-functions.md +++ b/src/docs/guide/usage/linter/rules/jest/no-deprecated-functions.md @@ -1,10 +1,5 @@ - - # jest/no-deprecated-functions
@@ -52,36 +47,13 @@ This function was renamed to `createMockFromModule` in Jest 26, and is scheduled While typically these deprecated functions are kept in the codebase for a number of majors, eventually they are removed completely. -### Examples - -Examples of **incorrect** code for this rule: +### Example ```javascript jest.resetModuleRegistry; // since Jest 15 jest.addMatchers; // since Jest 17 ``` -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny jest/no-deprecated-functions --jest-plugin -``` - -```json [Config (.oxlintrc.json)] -{ - "plugins": ["jest"], - "rules": { - "jest/no-deprecated-functions": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/jest/no_deprecated_functions.rs) diff --git a/src/docs/guide/usage/linter/rules/jest/no-disabled-tests.md b/src/docs/guide/usage/linter/rules/jest/no-disabled-tests.md index 4cac9967ddd..6c7ebac2a1b 100644 --- a/src/docs/guide/usage/linter/rules/jest/no-disabled-tests.md +++ b/src/docs/guide/usage/linter/rules/jest/no-disabled-tests.md @@ -1,10 +1,5 @@ - - # jest/no-disabled-tests
@@ -55,27 +50,6 @@ to use it, add the following configuration to your `.eslintrc.json`: } ``` -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny jest/no-disabled-tests --jest-plugin -``` - -```json [Config (.oxlintrc.json)] -{ - "plugins": ["jest"], - "rules": { - "jest/no-disabled-tests": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/jest/no_disabled_tests.rs) diff --git a/src/docs/guide/usage/linter/rules/jest/no-done-callback.md b/src/docs/guide/usage/linter/rules/jest/no-done-callback.md index c7d6de61884..7de077feb8e 100644 --- a/src/docs/guide/usage/linter/rules/jest/no-done-callback.md +++ b/src/docs/guide/usage/linter/rules/jest/no-done-callback.md @@ -1,10 +1,5 @@ - - # jest/no-done-callback
@@ -20,7 +15,7 @@ When calling asynchronous code in hooks and tests, jest needs to know when the a Originally the most common pattern to achieve this was to use callbacks: ```javascript -test("the data is peanut butter", done => { +test("the data is peanut butter", (done) => { function callback(data) { try { expect(data).toBe("peanut butter"); @@ -36,45 +31,22 @@ test("the data is peanut butter", done => { This can be very error-prone however, as it requires careful understanding of how assertions work in tests or otherwise tests won't behave as expected. -### Examples - -Examples of **incorrect** code for this rule: +### Example ```javascript -beforeEach(done => { +beforeEach((done) => { // ... }); -test("myFunction()", done => { +test("myFunction()", (done) => { // ... }); -test("myFunction()", function(done) { +test("myFunction()", function (done) { // ... }); ``` -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny jest/no-done-callback --jest-plugin -``` - -```json [Config (.oxlintrc.json)] -{ - "plugins": ["jest"], - "rules": { - "jest/no-done-callback": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/jest/no_done_callback.rs) diff --git a/src/docs/guide/usage/linter/rules/jest/no-duplicate-hooks.md b/src/docs/guide/usage/linter/rules/jest/no-duplicate-hooks.md index 2b104085ef2..e7aa8d0012f 100644 --- a/src/docs/guide/usage/linter/rules/jest/no-duplicate-hooks.md +++ b/src/docs/guide/usage/linter/rules/jest/no-duplicate-hooks.md @@ -1,10 +1,5 @@ - - # jest/no-duplicate-hooks
@@ -17,11 +12,8 @@ Disallows duplicate hooks in describe blocks. ### Why is this bad? Having duplicate hooks in a describe block can lead to confusion and unexpected behavior. -When multiple hooks of the same type exist, they all execute in order, which can make it -difficult to understand the test setup flow and may result in redundant or conflicting -operations. This makes tests harder to maintain and debug. -### Examples +### Example Examples of **incorrect** code for this rule: @@ -89,27 +81,6 @@ describe("foo", () => { }); ``` -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny jest/no-duplicate-hooks --jest-plugin -``` - -```json [Config (.oxlintrc.json)] -{ - "plugins": ["jest"], - "rules": { - "jest/no-duplicate-hooks": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/jest/no_duplicate_hooks.rs) diff --git a/src/docs/guide/usage/linter/rules/jest/no-export.md b/src/docs/guide/usage/linter/rules/jest/no-export.md index 5fd6d5c23f6..f44f1f8f1f6 100644 --- a/src/docs/guide/usage/linter/rules/jest/no-export.md +++ b/src/docs/guide/usage/linter/rules/jest/no-export.md @@ -1,10 +1,5 @@ - - # jest/no-export
@@ -20,9 +15,7 @@ This rule aims to eliminate duplicate runs of tests by exporting things from tes If you import from a test file, then all the tests in that file will be run in each imported instance. so bottom line, don't export from a test, but instead move helper functions into a separate file when they need to be shared across tests. -### Examples - -Examples of **incorrect** code for this rule: +### Example ```javascript export function myHelper() {} @@ -31,27 +24,6 @@ describe("a test", () => { }); ``` -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny jest/no-export --jest-plugin -``` - -```json [Config (.oxlintrc.json)] -{ - "plugins": ["jest"], - "rules": { - "jest/no-export": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/jest/no_export.rs) diff --git a/src/docs/guide/usage/linter/rules/jest/no-focused-tests.md b/src/docs/guide/usage/linter/rules/jest/no-focused-tests.md index ff44d6f87db..88ff09dc187 100644 --- a/src/docs/guide/usage/linter/rules/jest/no-focused-tests.md +++ b/src/docs/guide/usage/linter/rules/jest/no-focused-tests.md @@ -1,10 +1,5 @@ - - # jest/no-focused-tests
@@ -26,9 +21,7 @@ debug a failing test, so you don’t have to execute all of your tests. After yo have fixed your test and before committing the changes you have to remove `.only` to ensure all tests are executed on your build system. -### Examples - -Examples of **incorrect** code for this rule: +### Example ```javascript describe.only("foo", () => {}); @@ -40,7 +33,7 @@ test["only"]("bar", () => {}); fdescribe("foo", () => {}); fit("foo", () => {}); fit.each` -table + table `(); ``` @@ -55,27 +48,6 @@ to use it, add the following configuration to your `.eslintrc.json`: } ``` -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny jest/no-focused-tests --jest-plugin -``` - -```json [Config (.oxlintrc.json)] -{ - "plugins": ["jest"], - "rules": { - "jest/no-focused-tests": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/jest/no_focused_tests.rs) diff --git a/src/docs/guide/usage/linter/rules/jest/no-hooks.md b/src/docs/guide/usage/linter/rules/jest/no-hooks.md index 69539aed79c..3024b389fc5 100644 --- a/src/docs/guide/usage/linter/rules/jest/no-hooks.md +++ b/src/docs/guide/usage/linter/rules/jest/no-hooks.md @@ -1,10 +1,5 @@ - - # jest/no-hooks
@@ -27,13 +22,15 @@ This rule reports for the following function calls: - `afterAll` - `afterEach` -### Examples - -Examples of **incorrect** code for this rule: +### Example ```javascript -function setupFoo(options) {/* ... */} -function setupBar(options) {/* ... */} +function setupFoo(options) { + /* ... */ +} +function setupBar(options) { + /* ... */ +} describe("foo", () => { let foo; @@ -61,27 +58,6 @@ describe("foo", () => { }); ``` -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny jest/no-hooks --jest-plugin -``` - -```json [Config (.oxlintrc.json)] -{ - "plugins": ["jest"], - "rules": { - "jest/no-hooks": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/jest/no_hooks.rs) diff --git a/src/docs/guide/usage/linter/rules/jest/no-identical-title.md b/src/docs/guide/usage/linter/rules/jest/no-identical-title.md index 7fd850e80d6..32c80635351 100644 --- a/src/docs/guide/usage/linter/rules/jest/no-identical-title.md +++ b/src/docs/guide/usage/linter/rules/jest/no-identical-title.md @@ -1,10 +1,5 @@ - - # jest/no-identical-title
@@ -20,13 +15,11 @@ It will report when two test suites or two test cases at the same level of a tes Having identical titles for two different tests or test suites may create confusion. For example, when a test with the same title as another test in the same test suite fails, it is harder to know which one failed and thus harder to fix. -### Examples - -Examples of **incorrect** code for this rule: +### Example ```javascript describe("baz", () => { - // ... + //... }); describe("baz", () => { @@ -46,27 +39,6 @@ to use it, add the following configuration to your `.eslintrc.json`: } ``` -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny jest/no-identical-title --jest-plugin -``` - -```json [Config (.oxlintrc.json)] -{ - "plugins": ["jest"], - "rules": { - "jest/no-identical-title": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/jest/no_identical_title.rs) diff --git a/src/docs/guide/usage/linter/rules/jest/no-interpolation-in-snapshots.md b/src/docs/guide/usage/linter/rules/jest/no-interpolation-in-snapshots.md index ebc8273046d..87f9eb9ad6a 100644 --- a/src/docs/guide/usage/linter/rules/jest/no-interpolation-in-snapshots.md +++ b/src/docs/guide/usage/linter/rules/jest/no-interpolation-in-snapshots.md @@ -1,10 +1,5 @@ - - # jest/no-interpolation-in-snapshots
@@ -20,9 +15,7 @@ Interpolation prevents snapshots from being updated. Instead, properties should be overloaded with a matcher by using [property matchers](https://jestjs.io/docs/en/snapshot-testing#property-matchers). -### Examples - -Examples of **incorrect** code for this rule: +### Example ```javascript expect(something).toMatchInlineSnapshot( @@ -39,32 +32,9 @@ expect(something).toMatchInlineSnapshot( }`, ); -expect(errorThrowingFunction).toThrowErrorMatchingInlineSnapshot( - `${interpolated}`, -); +expect(errorThrowingFunction).toThrowErrorMatchingInlineSnapshot(`${interpolated}`); ``` -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny jest/no-interpolation-in-snapshots --jest-plugin -``` - -```json [Config (.oxlintrc.json)] -{ - "plugins": ["jest"], - "rules": { - "jest/no-interpolation-in-snapshots": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/jest/no_interpolation_in_snapshots.rs) diff --git a/src/docs/guide/usage/linter/rules/jest/no-jasmine-globals.md b/src/docs/guide/usage/linter/rules/jest/no-jasmine-globals.md index c81b0890fa4..7d0fe2c61fa 100644 --- a/src/docs/guide/usage/linter/rules/jest/no-jasmine-globals.md +++ b/src/docs/guide/usage/linter/rules/jest/no-jasmine-globals.md @@ -1,10 +1,5 @@ - - # jest/no-jasmine-globals
@@ -15,18 +10,9 @@ const source = `https://github.com/oxc-project/oxc/blob/${ data }/crates/oxc_lin ### What it does -This rule reports on any usage of Jasmine globals, which is not ported to -Jest, and suggests alternatives from Jest's own API. - -### Why is this bad? - -When migrating from Jasmine to Jest, relying on Jasmine-specific globals -creates compatibility issues and prevents taking advantage of Jest's -improved testing features and better error reporting. +This rule reports on any usage of Jasmine globals, which is not ported to Jest, and suggests alternatives from Jest's own API. -### Examples - -Examples of **incorrect** code for this rule: +### Example ```javascript jasmine.DEFAULT_TIMEOUT_INTERVAL = 5000; @@ -38,42 +24,6 @@ test("my test", () => { }); ``` -Examples of **correct** code for this rule: - -```javascript -jest.setTimeout(5000); -test("my test", () => { - // Use test.skip() instead of pending() -}); -test.skip("my test", () => { - // Skipped test -}); -test("my test", () => { - jest.fn(); // Use jest.fn() instead of jasmine.createSpy() -}); -``` - -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny jest/no-jasmine-globals --jest-plugin -``` - -```json [Config (.oxlintrc.json)] -{ - "plugins": ["jest"], - "rules": { - "jest/no-jasmine-globals": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/jest/no_jasmine_globals.rs) diff --git a/src/docs/guide/usage/linter/rules/jest/no-large-snapshots.md b/src/docs/guide/usage/linter/rules/jest/no-large-snapshots.md index c925c348c49..836a8228eaf 100644 --- a/src/docs/guide/usage/linter/rules/jest/no-large-snapshots.md +++ b/src/docs/guide/usage/linter/rules/jest/no-large-snapshots.md @@ -1,10 +1,5 @@ - - # jest/no-large-snapshots
@@ -93,27 +88,6 @@ line 4 `; ``` -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny jest/no-large-snapshots --jest-plugin -``` - -```json [Config (.oxlintrc.json)] -{ - "plugins": ["jest"], - "rules": { - "jest/no-large-snapshots": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/jest/no_large_snapshots.rs) diff --git a/src/docs/guide/usage/linter/rules/jest/no-mocks-import.md b/src/docs/guide/usage/linter/rules/jest/no-mocks-import.md index 53b405800a1..e1b24208661 100644 --- a/src/docs/guide/usage/linter/rules/jest/no-mocks-import.md +++ b/src/docs/guide/usage/linter/rules/jest/no-mocks-import.md @@ -1,10 +1,5 @@ - - # jest/no-mocks-import
@@ -16,13 +11,9 @@ This rule reports imports from a path containing a **mocks** component. ### Why is this bad? -Manually importing mocks from a `__mocks__` directory can lead to unexpected behavior -and breaks Jest's automatic mocking system. Jest is designed to automatically resolve -and use mocks from `__mocks__` directories when `jest.mock()` is called. Directly -importing from these directories bypasses Jest's module resolution system and can cause -inconsistencies between test and production environments. +Manually importing mocks from a `__mocks__` directory can lead to unexpected behavior. -### Examples +### Example Examples of **incorrect** code for this rule: @@ -38,27 +29,6 @@ import thing from "thing"; require("thing"); ``` -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny jest/no-mocks-import --jest-plugin -``` - -```json [Config (.oxlintrc.json)] -{ - "plugins": ["jest"], - "rules": { - "jest/no-mocks-import": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/jest/no_mocks_import.rs) diff --git a/src/docs/guide/usage/linter/rules/jest/no-restricted-jest-methods.md b/src/docs/guide/usage/linter/rules/jest/no-restricted-jest-methods.md index 7cbaec0d761..b33a8362fc1 100644 --- a/src/docs/guide/usage/linter/rules/jest/no-restricted-jest-methods.md +++ b/src/docs/guide/usage/linter/rules/jest/no-restricted-jest-methods.md @@ -1,10 +1,5 @@ - - # jest/no-restricted-jest-methods
@@ -14,15 +9,7 @@ const source = `https://github.com/oxc-project/oxc/blob/${ data }/crates/oxc_lin Restrict the use of specific `jest` and `vi` methods. -### Why is this bad? - -Certain Jest methods may be deprecated, discouraged in specific -contexts, or incompatible with your testing environment. Restricting -them helps maintain consistent and reliable test practices. - -### Examples - -Examples of **incorrect** code for this rule: +### Example ```javascript jest.useFakeTimers(); @@ -41,27 +28,6 @@ test("plays video", () => { }); ``` -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny jest/no-restricted-jest-methods --jest-plugin -``` - -```json [Config (.oxlintrc.json)] -{ - "plugins": ["jest"], - "rules": { - "jest/no-restricted-jest-methods": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/jest/no_restricted_jest_methods.rs) diff --git a/src/docs/guide/usage/linter/rules/jest/no-restricted-matchers.md b/src/docs/guide/usage/linter/rules/jest/no-restricted-matchers.md index bebb14e2183..7ef3b9c713d 100644 --- a/src/docs/guide/usage/linter/rules/jest/no-restricted-matchers.md +++ b/src/docs/guide/usage/linter/rules/jest/no-restricted-matchers.md @@ -1,10 +1,5 @@ - - # jest/no-restricted-matchers
@@ -14,43 +9,7 @@ const source = `https://github.com/oxc-project/oxc/blob/${ data }/crates/oxc_lin Ban specific matchers & modifiers from being used, and can suggest alternatives. -### Why is this bad? - -Some matchers or modifiers might be discouraged in your codebase for various reasons: -they might be deprecated, cause confusion, have performance implications, or there -might be better alternatives available. This rule allows you to enforce consistent -testing patterns by restricting certain Jest matchers and providing guidance on -preferred alternatives. - -### Examples - -Bans are expressed in the form of a map, with the value being either a string message to be shown, -or null if only the default rule message should be used. Bans are checked against the start of -the expect chain - this means that to ban a specific matcher entirely you must specify all -six permutations, but allows you to ban modifiers as well. By default, this map is empty, meaning -no matchers or modifiers are banned. - -Example configuration: - -```json -{ - "jest/no-restricted-matchers": [ - "error", - { - "toBeFalsy": null, - "resolves": "Use `expect(await promise)` instead.", - "toHaveBeenCalledWith": null, - "not.toHaveBeenCalledWith": null, - "resolves.toHaveBeenCalledWith": null, - "rejects.toHaveBeenCalledWith": null, - "resolves.not.toHaveBeenCalledWith": null, - "rejects.not.toHaveBeenCalledWith": null - } - ] -} -``` - -Examples of **incorrect** code for this rule with the above configuration: +### Example ```javascript it("is false", () => { @@ -71,27 +30,6 @@ describe("when an error happens", () => { }); ``` -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny jest/no-restricted-matchers --jest-plugin -``` - -```json [Config (.oxlintrc.json)] -{ - "plugins": ["jest"], - "rules": { - "jest/no-restricted-matchers": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/jest/no_restricted_matchers.rs) diff --git a/src/docs/guide/usage/linter/rules/jest/no-standalone-expect.md b/src/docs/guide/usage/linter/rules/jest/no-standalone-expect.md index 0e9119175f4..57b1ebfd910 100644 --- a/src/docs/guide/usage/linter/rules/jest/no-standalone-expect.md +++ b/src/docs/guide/usage/linter/rules/jest/no-standalone-expect.md @@ -1,10 +1,5 @@ - - # jest/no-standalone-expect
@@ -19,16 +14,7 @@ trigger this rule. Statements like `expect.hasAssertions()` will NOT trigger this rule since these calls will execute if they are not in a test block. -### Why is this bad? - -`expect` statements outside of test blocks will not be executed by the Jest -test runner, which means they won't actually test anything. This can lead to -false confidence in test coverage and may hide bugs that would otherwise be -caught by proper testing. - -### Examples - -Examples of **incorrect** code for this rule: +### Example ```javascript describe("a test", () => { @@ -36,27 +22,6 @@ describe("a test", () => { }); ``` -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny jest/no-standalone-expect --jest-plugin -``` - -```json [Config (.oxlintrc.json)] -{ - "plugins": ["jest"], - "rules": { - "jest/no-standalone-expect": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/jest/no_standalone_expect.rs) diff --git a/src/docs/guide/usage/linter/rules/jest/no-test-prefixes.md b/src/docs/guide/usage/linter/rules/jest/no-test-prefixes.md index 952a7637ae8..4d7fdfecabe 100644 --- a/src/docs/guide/usage/linter/rules/jest/no-test-prefixes.md +++ b/src/docs/guide/usage/linter/rules/jest/no-test-prefixes.md @@ -1,10 +1,5 @@ - - # jest/no-test-prefixes
@@ -27,9 +22,7 @@ with multiple permutations for each: This rule enforces usages from the only & skip list. -### Examples - -Examples of **incorrect** code for this rule: +### Example ```javascript fit("foo"); // invalid @@ -50,27 +43,6 @@ to use it, add the following configuration to your `.eslintrc.json`: } ``` -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny jest/no-test-prefixes --jest-plugin -``` - -```json [Config (.oxlintrc.json)] -{ - "plugins": ["jest"], - "rules": { - "jest/no-test-prefixes": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/jest/no_test_prefixes.rs) diff --git a/src/docs/guide/usage/linter/rules/jest/no-test-return-statement.md b/src/docs/guide/usage/linter/rules/jest/no-test-return-statement.md index f924119e490..17ac6b245d6 100644 --- a/src/docs/guide/usage/linter/rules/jest/no-test-return-statement.md +++ b/src/docs/guide/usage/linter/rules/jest/no-test-return-statement.md @@ -1,10 +1,5 @@ - - # jest/no-test-return-statement
@@ -20,9 +15,7 @@ Tests in Jest should be void and not return values. If you are returning Promises then you should update the test to use `async/await`. -### Examples - -Examples of **incorrect** code for this rule: +### Example ```javascript test("one", () => { @@ -30,35 +23,6 @@ test("one", () => { }); ``` -Examples of **correct** code for this rule: - -```javascript -test("one", () => { - expect(1).toBe(1); -}); -``` - -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny jest/no-test-return-statement --jest-plugin -``` - -```json [Config (.oxlintrc.json)] -{ - "plugins": ["jest"], - "rules": { - "jest/no-test-return-statement": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/jest/no_test_return_statement.rs) diff --git a/src/docs/guide/usage/linter/rules/jest/no-untyped-mock-factory.md b/src/docs/guide/usage/linter/rules/jest/no-untyped-mock-factory.md index eb6004093cb..794ff780011 100644 --- a/src/docs/guide/usage/linter/rules/jest/no-untyped-mock-factory.md +++ b/src/docs/guide/usage/linter/rules/jest/no-untyped-mock-factory.md @@ -1,10 +1,5 @@ - - # jest/no-untyped-mock-factory
@@ -26,9 +21,9 @@ returns an object with the same shape as the original module, or some other strict type. Requiring a type makes it easier to use TypeScript to catch changes needed in test mocks when the source module changes. -### Examples +### Example -Examples of **incorrect** code for this rule: +// invalid ```typescript jest.mock("../moduleName", () => { @@ -45,7 +40,7 @@ jest.mock("random-num", () => { }); ``` -Examples of **correct** code for this rule: +// valid ```typescript // Uses typeof import() @@ -76,27 +71,6 @@ jest.mock( ); ``` -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny jest/no-untyped-mock-factory --jest-plugin -``` - -```json [Config (.oxlintrc.json)] -{ - "plugins": ["jest"], - "rules": { - "jest/no-untyped-mock-factory": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/jest/no_untyped_mock_factory.rs) diff --git a/src/docs/guide/usage/linter/rules/jest/padding-around-test-blocks.md b/src/docs/guide/usage/linter/rules/jest/padding-around-test-blocks.md deleted file mode 100644 index df0711881d6..00000000000 --- a/src/docs/guide/usage/linter/rules/jest/padding-around-test-blocks.md +++ /dev/null @@ -1,77 +0,0 @@ - - - - -# jest/padding-around-test-blocks - -
- -πŸ› οΈ An auto-fix is available for this rule. - -
- -### What it does - -This rule enforces a line of padding before and after 1 or more test/it statements - -### Examples - -Examples of **incorrect** code for this rule: - -```js -const thing = 123; -test("foo", () => {}); -test("bar", () => {}); -``` - -```js -const thing = 123; -it("foo", () => {}); -it("bar", () => {}); -``` - -Examples of **correct** code for this rule: - -```js -const thing = 123; - -test("foo", () => {}); - -test("bar", () => {}); -``` - -```js -const thing = 123; - -it("foo", () => {}); - -it("bar", () => {}); -``` - -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny jest/padding-around-test-blocks --jest-plugin -``` - -```json [Config (.oxlintrc.json)] -{ - "plugins": ["jest"], - "rules": { - "jest/padding-around-test-blocks": "error" - } -} -``` - -::: - -## References - -- Rule Source diff --git a/src/docs/guide/usage/linter/rules/jest/prefer-called-with.md b/src/docs/guide/usage/linter/rules/jest/prefer-called-with.md index 5c8297b3b9d..fd397d1971d 100644 --- a/src/docs/guide/usage/linter/rules/jest/prefer-called-with.md +++ b/src/docs/guide/usage/linter/rules/jest/prefer-called-with.md @@ -1,10 +1,5 @@ - - # jest/prefer-called-with
@@ -14,53 +9,20 @@ const source = `https://github.com/oxc-project/oxc/blob/${ data }/crates/oxc_lin Suggest using `toBeCalledWith()` or `toHaveBeenCalledWith()` -### Why is this bad? - -When testing function calls, it's often more valuable to assert both -that a function was called AND what arguments it was called with. -Using `toBeCalled()` or `toHaveBeenCalled()` only verifies the function -was invoked, but doesn't validate the arguments, potentially missing -bugs where functions are called with incorrect parameters. - -### Examples - -Examples of **incorrect** code for this rule: - -```javascript -expect(someFunction).toBeCalled(); -expect(someFunction).toHaveBeenCalled(); -``` - -Examples of **correct** code for this rule: +### Example ```javascript +// valid expect(noArgsFunction).toBeCalledWith(); expect(roughArgsFunction).toBeCalledWith(expect.anything(), expect.any(Date)); expect(anyArgsFunction).toBeCalledTimes(1); expect(uncalledFunction).not.toBeCalled(); -``` - -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: -::: code-group - -```bash [CLI] -oxlint --deny jest/prefer-called-with --jest-plugin -``` - -```json [Config (.oxlintrc.json)] -{ - "plugins": ["jest"], - "rules": { - "jest/prefer-called-with": "error" - } -} +// invalid +expect(someFunction).toBeCalled(); +expect(someFunction).toHaveBeenCalled(); ``` -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/jest/prefer_called_with.rs) diff --git a/src/docs/guide/usage/linter/rules/jest/prefer-comparison-matcher.md b/src/docs/guide/usage/linter/rules/jest/prefer-comparison-matcher.md index 73a64581ffd..fa62cb31586 100644 --- a/src/docs/guide/usage/linter/rules/jest/prefer-comparison-matcher.md +++ b/src/docs/guide/usage/linter/rules/jest/prefer-comparison-matcher.md @@ -1,10 +1,5 @@ - - # jest/prefer-comparison-matcher
@@ -23,26 +18,17 @@ following built-in comparison matchers: - `toBeLessThan` - `toBeLessThanOrEqual` -### Why is this bad? - -Using generic matchers like `toBe(true)` with comparison expressions -makes tests less readable and provides less helpful error messages when -they fail. Jest's specific comparison matchers offer clearer intent and -better error output that shows the actual values being compared. - ### Examples -Examples of **incorrect** code for this rule: - ```js +// invalid expect(x > 5).toBe(true); expect(x < 7).not.toEqual(true); expect(x <= y).toStrictEqual(true); ``` -Examples of **correct** code for this rule: - -```js +```js /// +// valid expect(x).toBeGreaterThan(5); expect(x).not.toBeLessThanOrEqual(7); expect(x).toBeLessThanOrEqual(y); @@ -50,27 +36,6 @@ expect(x).toBeLessThanOrEqual(y); expect(x < "Carl").toBe(true); ``` -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny jest/prefer-comparison-matcher --jest-plugin -``` - -```json [Config (.oxlintrc.json)] -{ - "plugins": ["jest"], - "rules": { - "jest/prefer-comparison-matcher": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/jest/prefer_comparison_matcher.rs) diff --git a/src/docs/guide/usage/linter/rules/jest/prefer-each.md b/src/docs/guide/usage/linter/rules/jest/prefer-each.md deleted file mode 100644 index f004ebec8e3..00000000000 --- a/src/docs/guide/usage/linter/rules/jest/prefer-each.md +++ /dev/null @@ -1,66 +0,0 @@ - - - - -# jest/prefer-each - -
-
- -### What it does - -This rule enforces using `each` rather than manual loops. - -### Why is this bad? - -Manual loops for tests can be less readable and more error-prone. Using -`each` provides a clearer and more concise way to run parameterized tests, -improving readability and maintainability. - -### Examples - -Examples of **incorrect** code for this rule: - -```js -for (const item of items) { - describe(item, () => { - expect(item).toBe("foo"); - }); -} -``` - -Examples of **correct** code for this rule: - -```js -describe.each(items)("item", (item) => { - expect(item).toBe("foo"); -}); -``` - -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny jest/prefer-each --jest-plugin -``` - -```json [Config (.oxlintrc.json)] -{ - "plugins": ["jest"], - "rules": { - "jest/prefer-each": "error" - } -} -``` - -::: - -## References - -- Rule Source diff --git a/src/docs/guide/usage/linter/rules/jest/prefer-equality-matcher.md b/src/docs/guide/usage/linter/rules/jest/prefer-equality-matcher.md index 90ad870d2b4..562c49a4fec 100644 --- a/src/docs/guide/usage/linter/rules/jest/prefer-equality-matcher.md +++ b/src/docs/guide/usage/linter/rules/jest/prefer-equality-matcher.md @@ -1,10 +1,5 @@ - - # jest/prefer-equality-matcher
@@ -15,53 +10,20 @@ const source = `https://github.com/oxc-project/oxc/blob/${ data }/crates/oxc_lin Jest has built-in matchers for expecting equality, which allow for more readable tests and error messages if an expectation fails. -### Why is this bad? - -Testing equality expressions with generic matchers like `toBe(true)` -makes tests harder to read and understand. When tests fail, the error -messages are less helpful because they don't show what the actual values -were. Using specific equality matchers provides clearer test intent and -better debugging information. - -### Examples - -Examples of **incorrect** code for this rule: +### Example ```javascript +// invalid expect(x === 5).toBe(true); expect(name === "Carl").not.toEqual(true); expect(myObj !== thatObj).toStrictEqual(true); -``` - -Examples of **correct** code for this rule: -```javascript +// valid expect(x).toBe(5); expect(name).not.toEqual("Carl"); expect(myObj).toStrictEqual(thatObj); ``` -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny jest/prefer-equality-matcher --jest-plugin -``` - -```json [Config (.oxlintrc.json)] -{ - "plugins": ["jest"], - "rules": { - "jest/prefer-equality-matcher": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/jest/prefer_equality_matcher.rs) diff --git a/src/docs/guide/usage/linter/rules/jest/prefer-expect-resolves.md b/src/docs/guide/usage/linter/rules/jest/prefer-expect-resolves.md index 77cd146a255..e728ebe86f7 100644 --- a/src/docs/guide/usage/linter/rules/jest/prefer-expect-resolves.md +++ b/src/docs/guide/usage/linter/rules/jest/prefer-expect-resolves.md @@ -1,10 +1,5 @@ - - # jest/prefer-expect-resolves
@@ -15,79 +10,48 @@ const source = `https://github.com/oxc-project/oxc/blob/${ data }/crates/oxc_lin ### What it does -Prefer `await expect(...).resolves` over `expect(await ...)` when testing -promises. - -### Why is this bad? - -When working with promises, there are two primary ways you can test the -resolved value: +When working with promises, there are two primary ways you can test the resolved +value: 1. use the `resolve` modifier on `expect` (`await expect(...).resolves.` style) 2. `await` the promise and assert against its result (`expect(await ...).` style) -While the second style is arguably less dependent on `jest`, if the -promise rejects it will be treated as a general error, resulting in less -predictable behaviour and output from `jest`. - -Additionally, favoring the first style ensures consistency with its -`rejects` counterpart, as there is no way of "awaiting" a rejection. +While the second style is arguably less dependent on `jest`, if the promise +rejects it will be treated as a general error, resulting in less predictable +behaviour and output from `jest`. -### Examples +Additionally, favoring the first style ensures consistency with its `rejects` +counterpart, as there is no way of "awaiting" a rejection. -Examples of **incorrect** code for this rule: +### Example ```javascript +// valid it("passes", async () => { - expect(await someValue()).toBe(true); + await expect(someValue()).resolves.toBe(true); }); it("is true", async () => { const myPromise = Promise.resolve(true); - expect(await myPromise).toBe(true); + + await expect(myPromise).resolves.toBe(true); }); -``` -Examples of **correct** code for this rule: +it("errors", async () => { + await expect(Promise.reject(new Error("oh noes!"))).rejects.toThrowError("oh noes!"); +}); -```javascript +// invalid it("passes", async () => { - await expect(someValue()).resolves.toBe(true); + expect(await someValue()).toBe(true); }); it("is true", async () => { const myPromise = Promise.resolve(true); - - await expect(myPromise).resolves.toBe(true); -}); -it("errors", async () => { - await expect(Promise.reject(new Error("oh noes!"))).rejects.toThrowError( - "oh noes!", - ); + expect(await myPromise).toBe(true); }); ``` -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny jest/prefer-expect-resolves --jest-plugin -``` - -```json [Config (.oxlintrc.json)] -{ - "plugins": ["jest"], - "rules": { - "jest/prefer-expect-resolves": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/jest/prefer_expect_resolves.rs) diff --git a/src/docs/guide/usage/linter/rules/jest/prefer-hooks-in-order.md b/src/docs/guide/usage/linter/rules/jest/prefer-hooks-in-order.md index 1180e0d3247..e838a76ef86 100644 --- a/src/docs/guide/usage/linter/rules/jest/prefer-hooks-in-order.md +++ b/src/docs/guide/usage/linter/rules/jest/prefer-hooks-in-order.md @@ -1,10 +1,5 @@ - - # jest/prefer-hooks-in-order
@@ -12,10 +7,6 @@ const source = `https://github.com/oxc-project/oxc/blob/${ data }/crates/oxc_lin ### What it does -Ensures that hooks are in the order that they are called in. - -### Why is this bad? - While hooks can be setup in any order, they're always called by `jest` in this specific order: @@ -27,11 +18,10 @@ specific order: This rule aims to make that more obvious by enforcing grouped hooks be setup in that order within tests. -### Examples - -Examples of **incorrect** code for this rule: +### Example ```javascript +// invalid describe("foo", () => { beforeEach(() => { seedMyDatabase(); @@ -50,6 +40,7 @@ describe("foo", () => { beforeEach(() => { seedMyDatabase(specificValue); }); + it("accepts that input", () => { // ... }); @@ -72,16 +63,17 @@ describe("foo", () => { }); ``` -Examples of **correct** code for this rule: - ```javascript +// valid describe("foo", () => { beforeAll(() => { createMyDatabase(); }); + beforeEach(() => { seedMyDatabase(); }); + it("accepts this input", () => { // ... }); @@ -121,32 +113,11 @@ to use it, add the following configuration to your `.eslintrc.json`: ```json { "rules": { - "vitest/prefer-hooks-in-order": "error" - } -} -``` - -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny jest/prefer-hooks-in-order --jest-plugin -``` - -```json [Config (.oxlintrc.json)] -{ - "plugins": ["jest"], - "rules": { - "jest/prefer-hooks-in-order": "error" + "vitest/prefer-hooks-in-order": "error" } } -``` -::: ## References - -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/jest/prefer_hooks_in_order.rs) +``` diff --git a/src/docs/guide/usage/linter/rules/jest/prefer-hooks-on-top.md b/src/docs/guide/usage/linter/rules/jest/prefer-hooks-on-top.md index be962501d47..e40706098f8 100644 --- a/src/docs/guide/usage/linter/rules/jest/prefer-hooks-on-top.md +++ b/src/docs/guide/usage/linter/rules/jest/prefer-hooks-on-top.md @@ -1,10 +1,5 @@ - - # jest/prefer-hooks-on-top
@@ -16,19 +11,10 @@ While hooks can be setup anywhere in a test file, they are always called in a specific order, which means it can be confusing if they're intermixed with test cases. -### Why is this bad? - -When hooks are mixed with test cases, it becomes harder to understand -the test setup and execution order. This can lead to confusion about -which hooks apply to which tests and when they run. Grouping hooks at -the top of each `describe` block makes the test structure clearer and -more maintainable. - -### Examples - -Examples of **incorrect** code for this rule: +### Example ```javascript +// invalid describe("foo", () => { beforeEach(() => { seedMyDatabase(); @@ -77,11 +63,8 @@ describe("foo", () => { removeMyDatabase(); }); }); -``` - -Examples of **correct** code for this rule: -```javascript +// valid describe("foo", () => { beforeAll(() => { createMyDatabase(); @@ -133,27 +116,6 @@ describe("foo", () => { }); ``` -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny jest/prefer-hooks-on-top --jest-plugin -``` - -```json [Config (.oxlintrc.json)] -{ - "plugins": ["jest"], - "rules": { - "jest/prefer-hooks-on-top": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/jest/prefer_hooks_on_top.rs) diff --git a/src/docs/guide/usage/linter/rules/jest/prefer-jest-mocked.md b/src/docs/guide/usage/linter/rules/jest/prefer-jest-mocked.md index 0b3d0fd2d50..88b2c12890a 100644 --- a/src/docs/guide/usage/linter/rules/jest/prefer-jest-mocked.md +++ b/src/docs/guide/usage/linter/rules/jest/prefer-jest-mocked.md @@ -1,10 +1,5 @@ - - # jest/prefer-jest-mocked
@@ -26,56 +21,23 @@ Restricted types: - `jest.MockedClass` - `jest.MockedObject` -### Why is this bad? - -Using type assertions like `fn as jest.Mock` is a less safe approach -than using `jest.mocked()`. The `jest.mocked()` helper provides better -type safety by preserving the original function signature while adding -mock capabilities. It also makes the code more readable and explicit -about mocking intentions. - ### Examples -Examples of **incorrect** code for this rule: - ```typescript +// invalid (foo as jest.Mock).mockReturnValue(1); const mock = (foo as jest.Mock).mockReturnValue(1); (foo as unknown as jest.Mock).mockReturnValue(1); (Obj.foo as jest.Mock).mockReturnValue(1); ([].foo as jest.Mock).mockReturnValue(1); -``` - -Examples of **correct** code for this rule: -```typescript +// valid jest.mocked(foo).mockReturnValue(1); const mock = jest.mocked(foo).mockReturnValue(1); jest.mocked(Obj.foo).mockReturnValue(1); jest.mocked([].foo).mockReturnValue(1); ``` -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny jest/prefer-jest-mocked --jest-plugin -``` - -```json [Config (.oxlintrc.json)] -{ - "plugins": ["jest"], - "rules": { - "jest/prefer-jest-mocked": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/jest/prefer_jest_mocked.rs) diff --git a/src/docs/guide/usage/linter/rules/jest/prefer-lowercase-title.md b/src/docs/guide/usage/linter/rules/jest/prefer-lowercase-title.md index 24482f2fcd8..57fb32d2825 100644 --- a/src/docs/guide/usage/linter/rules/jest/prefer-lowercase-title.md +++ b/src/docs/guide/usage/linter/rules/jest/prefer-lowercase-title.md @@ -1,10 +1,5 @@ - - # jest/prefer-lowercase-title
@@ -15,29 +10,25 @@ const source = `https://github.com/oxc-project/oxc/blob/${ data }/crates/oxc_lin ### What it does -Enforce `it`, `test`, `describe`, and `bench` to have descriptions that begin with a +Enforce `it`, `test` and `describe` to have descriptions that begin with a lowercase letter. This provides more readable test failures. This rule is not enabled by default. -### Examples - -Examples of **incorrect** code for this rule: +### Example ```javascript +// invalid it("Adds 1 + 2 to equal 3", () => { expect(sum(1, 2)).toBe(3); }); -``` -Examples of **correct** code for this rule: - -```javascript +// valid it("adds 1 + 2 to equal 3", () => { expect(sum(1, 2)).toBe(3); }); ``` -### Options +## Options ```json { @@ -50,15 +41,14 @@ it("adds 1 + 2 to equal 3", () => { } ``` -#### `ignore` +### `ignore` -This array option controls which Jest or Vitest functions are checked by this rule. There -are four possible values: +This array option controls which Jest functions are checked by this rule. There +are three possible values: - `"describe"` - `"test"` - `"it"` -- `"bench"` By default, none of these options are enabled (the equivalent of `{ "ignore": [] }`). @@ -84,7 +74,7 @@ Example of **correct** code for the `{ "ignore": ["it"] }` option: it("Uppercase description"); ``` -#### `allowedPrefixes` +### `allowedPrefixes` This array option allows specifying prefixes, which contain capitals that titles can start with. This can be useful when writing tests for API endpoints, where @@ -98,11 +88,10 @@ Example of **correct** code for the `{ "allowedPrefixes": ["GET"] }` option: describe("GET /live"); ``` -#### `ignoreTopLevelDescribe` +### `ignoreTopLevelDescribe` This option can be set to allow only the top-level `describe` blocks to have a title starting with an upper-case letter. - Example of **correct** code for the `{ "ignoreTopLevelDescribe": true }` option: ```js @@ -116,57 +105,6 @@ describe("MyClass", () => { }); ``` -#### `lowercaseFirstCharacterOnly` - -This option can be set to only validate that the first character of a test name is lowercased. - -Example of **correct** code for the `{ "lowercaseFirstCharacterOnly": true }` option: - -```js -/* eslint vitest/prefer-lowercase-title: ["error", { "lowercaseFirstCharacterOnly": true }] */ -describe("myClass", () => { - describe("myMethod", () => { - it("does things", () => { - // - }); - }); -}); -``` - -Example of **incorrect** code for the `{ "lowercaseFirstCharacterOnly": true }` option: - -```js -/* eslint vitest/prefer-lowercase-title: ["error", { "lowercaseFirstCharacterOnly": true }] */ -describe("MyClass", () => { - describe("MyMethod", () => { - it("does things", () => { - // - }); - }); -}); -``` - -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny jest/prefer-lowercase-title --jest-plugin -``` - -```json [Config (.oxlintrc.json)] -{ - "plugins": ["jest"], - "rules": { - "jest/prefer-lowercase-title": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/jest/prefer_lowercase_title.rs) diff --git a/src/docs/guide/usage/linter/rules/jest/prefer-mock-promise-shorthand.md b/src/docs/guide/usage/linter/rules/jest/prefer-mock-promise-shorthand.md index 4a63e739680..6bba7db7c70 100644 --- a/src/docs/guide/usage/linter/rules/jest/prefer-mock-promise-shorthand.md +++ b/src/docs/guide/usage/linter/rules/jest/prefer-mock-promise-shorthand.md @@ -1,10 +1,5 @@ - - # jest/prefer-mock-promise-shorthand
@@ -19,23 +14,12 @@ When working with mocks of functions that return promises, Jest provides some API sugar functions to reduce the amount of boilerplate you have to write. These methods should be preferred when possible. -### Why is this bad? - -Using generic mock functions like `mockImplementation(() => Promise.resolve())` -or `mockReturnValue(Promise.reject())` is more verbose and less readable than -Jest's specialized promise shorthands. The shorthand methods like -`mockResolvedValue()` and `mockRejectedValue()` are more expressive and -make the test intent clearer. - -### Examples - -Examples of **incorrect** code for this rule: +### Example ```javascript +// invalid jest.fn().mockImplementation(() => Promise.resolve(123)); -jest - .spyOn(fs.promises, "readFile") - .mockReturnValue(Promise.reject(new Error("oh noes!"))); +jest.spyOn(fs.promises, "readFile").mockReturnValue(Promise.reject(new Error("oh noes!"))); myFunction .mockReturnValueOnce(Promise.resolve(42)) @@ -43,39 +27,15 @@ myFunction .mockReturnValue(Promise.reject(new Error("too many calls!"))); ``` -Examples of **correct** code for this rule: +// valid ```javascript jest.fn().mockResolvedValue(123); jest.spyOn(fs.promises, "readFile").mockRejectedValue(new Error("oh noes!")); -myFunction - .mockResolvedValueOnce(42) - .mockResolvedValueOnce(42) - .mockRejectedValue(new Error("too many calls!")); +myFunction.mockResolvedValueOnce(42).mockResolvedValueOnce(42).mockRejectedValue(new Error("too many calls!")); ``` -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny jest/prefer-mock-promise-shorthand --jest-plugin -``` - -```json [Config (.oxlintrc.json)] -{ - "plugins": ["jest"], - "rules": { - "jest/prefer-mock-promise-shorthand": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/jest/prefer_mock_promise_shorthand.rs) diff --git a/src/docs/guide/usage/linter/rules/jest/prefer-spy-on.md b/src/docs/guide/usage/linter/rules/jest/prefer-spy-on.md index ffb9a01cafa..e05124f1dbc 100644 --- a/src/docs/guide/usage/linter/rules/jest/prefer-spy-on.md +++ b/src/docs/guide/usage/linter/rules/jest/prefer-spy-on.md @@ -1,10 +1,5 @@ - - # jest/prefer-spy-on
@@ -26,51 +21,18 @@ function. The original function can be overwritten with `mockFn.mockImplementation()` or by some of the [other mock functions](https://jestjs.io/docs/en/mock-function-api). -### Why is this bad? - -Directly overwriting properties with mock functions can lead to cleanup issues -and test isolation problems. When you manually assign a mock to a property, -you're responsible for restoring the original implementation, which is easy to -forget and can cause tests to interfere with each other. Using `jest.spyOn()` -provides automatic cleanup capabilities and makes your tests more reliable. - -### Examples - -Examples of **incorrect** code for this rule: +### Example ```javascript +// invalid Date.now = jest.fn(); Date.now = jest.fn(() => 10); -``` - -Examples of **correct** code for this rule: -```javascript +// valid jest.spyOn(Date, "now"); jest.spyOn(Date, "now").mockImplementation(() => 10); ``` -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny jest/prefer-spy-on --jest-plugin -``` - -```json [Config (.oxlintrc.json)] -{ - "plugins": ["jest"], - "rules": { - "jest/prefer-spy-on": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/jest/prefer_spy_on.rs) diff --git a/src/docs/guide/usage/linter/rules/jest/prefer-strict-equal.md b/src/docs/guide/usage/linter/rules/jest/prefer-strict-equal.md index d438ae865ce..7fde1c00c59 100644 --- a/src/docs/guide/usage/linter/rules/jest/prefer-strict-equal.md +++ b/src/docs/guide/usage/linter/rules/jest/prefer-strict-equal.md @@ -1,10 +1,5 @@ - - # jest/prefer-strict-equal
@@ -17,48 +12,16 @@ const source = `https://github.com/oxc-project/oxc/blob/${ data }/crates/oxc_lin This rule triggers a warning if `toEqual()` is used to assert equality. -### Why is this bad? - -The `toEqual()` matcher performs a deep equality check but ignores -`undefined` values in objects and arrays. This can lead to false -positives where tests pass when they should fail. `toStrictEqual()` -provides more accurate comparison by checking for `undefined` values. - -### Examples - -Examples of **incorrect** code for this rule: +### Example ```javascript +// invalid expect({ a: "a", b: undefined }).toEqual({ a: "a" }); -``` - -Examples of **correct** code for this rule: -```javascript +// valid expect({ a: "a", b: undefined }).toStrictEqual({ a: "a" }); ``` -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny jest/prefer-strict-equal --jest-plugin -``` - -```json [Config (.oxlintrc.json)] -{ - "plugins": ["jest"], - "rules": { - "jest/prefer-strict-equal": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/jest/prefer_strict_equal.rs) diff --git a/src/docs/guide/usage/linter/rules/jest/prefer-to-be.md b/src/docs/guide/usage/linter/rules/jest/prefer-to-be.md index ecdf5649f0c..0fd6a889508 100644 --- a/src/docs/guide/usage/linter/rules/jest/prefer-to-be.md +++ b/src/docs/guide/usage/linter/rules/jest/prefer-to-be.md @@ -1,10 +1,5 @@ - - # jest/prefer-to-be
@@ -15,61 +10,30 @@ const source = `https://github.com/oxc-project/oxc/blob/${ data }/crates/oxc_lin ### What it does -Recommends using `toBe` matcher for primitive literals and specific -matchers for `null`, `undefined`, and `NaN`. - -### Why is this bad? - -When asserting against primitive literals such as numbers and strings, -the equality matchers all operate the same, but read slightly -differently in code. - -This rule recommends using the `toBe` matcher in these situations, as -it forms the most grammatically natural sentence. For `null`, -`undefined`, and `NaN` this rule recommends using their specific `toBe` -matchers, as they give better error messages as well. - -### Examples - -Examples of **incorrect** code for this rule: +When asserting against primitive literals such as numbers and strings, the +equality matchers all operate the same, but read slightly differently in code. -```javascript -expect(value).not.toEqual(5); -expect(getMessage()).toStrictEqual("hello world"); -expect(loadMessage()).resolves.toEqual("hello world"); -``` +This rule recommends using the `toBe` matcher in these situations, as it forms +the most grammatically natural sentence. For `null`, `undefined`, and `NaN` this +rule recommends using their specific `toBe` matchers, as they give better error +messages as well. -Examples of **correct** code for this rule: +### Example ```javascript +// valid expect(value).not.toBe(5); expect(getMessage()).toBe("hello world"); expect(loadMessage()).resolves.toBe("hello world"); expect(didError).not.toBe(true); expect(catchError()).toStrictEqual({ message: "oh noes!" }); -``` - -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny jest/prefer-to-be --jest-plugin -``` -```json [Config (.oxlintrc.json)] -{ - "plugins": ["jest"], - "rules": { - "jest/prefer-to-be": "error" - } -} +// invalid +expect(value).not.toEqual(5); +expect(getMessage()).toStrictEqual("hello world"); +expect(loadMessage()).resolves.toEqual("hello world"); ``` -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/jest/prefer_to_be.rs) diff --git a/src/docs/guide/usage/linter/rules/jest/prefer-to-contain.md b/src/docs/guide/usage/linter/rules/jest/prefer-to-contain.md index 3d0c310bfb8..9ef638a8de0 100644 --- a/src/docs/guide/usage/linter/rules/jest/prefer-to-contain.md +++ b/src/docs/guide/usage/linter/rules/jest/prefer-to-contain.md @@ -1,10 +1,5 @@ - - # jest/prefer-to-contain
@@ -20,11 +15,14 @@ asserting expectations on an array containing an object. TThis rule triggers a warning if `toBe()`, `toEqual()` or `toStrictEqual()` is used to assert object inclusion in an array -### Examples - -Examples of **incorrect** code for this rule: +### Example ```javascript +// valid +expect(a).toContain(b); +expect(a).not.toContain(b); + +// invalid expect(a.includes(b)).toBe(true); expect(a.includes(b)).not.toBe(true); expect(a.includes(b)).toBe(false); @@ -32,34 +30,6 @@ expect(a.includes(b)).toEqual(true); expect(a.includes(b)).toStrictEqual(true); ``` -Examples of **correct** code for this rule: - -```javascript -expect(a).toContain(b); -expect(a).not.toContain(b); -``` - -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny jest/prefer-to-contain --jest-plugin -``` - -```json [Config (.oxlintrc.json)] -{ - "plugins": ["jest"], - "rules": { - "jest/prefer-to-contain": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/jest/prefer_to_contain.rs) diff --git a/src/docs/guide/usage/linter/rules/jest/prefer-to-have-length.md b/src/docs/guide/usage/linter/rules/jest/prefer-to-have-length.md index 4a8ed2cdf3f..677572fca34 100644 --- a/src/docs/guide/usage/linter/rules/jest/prefer-to-have-length.md +++ b/src/docs/guide/usage/linter/rules/jest/prefer-to-have-length.md @@ -1,10 +1,5 @@ - - # jest/prefer-to-have-length
@@ -23,43 +18,21 @@ asserting expectations on objects length property. This rule triggers a warning if `toBe()`, `toEqual()` or `toStrictEqual()` is used to assert objects length property. -### Examples - -Examples of **incorrect** code for this rule: +### Example ```javascript +// valid +expect.hasAssertions; +expect.hasAssertions(); +expect(files).toHaveLength(1); +expect(files.name).toBe("file"); + +// invalid expect(files["length"]).toBe(1); expect(files["length"]).toBe(1); expect(files["length"])["not"].toBe(1); ``` -Examples of **correct** code for this rule: - -```javascript -expect(files).toHaveLength(1); -``` - -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny jest/prefer-to-have-length --jest-plugin -``` - -```json [Config (.oxlintrc.json)] -{ - "plugins": ["jest"], - "rules": { - "jest/prefer-to-have-length": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/jest/prefer_to_have_length.rs) diff --git a/src/docs/guide/usage/linter/rules/jest/prefer-todo.md b/src/docs/guide/usage/linter/rules/jest/prefer-todo.md index 56e666bdc6d..73a46af680f 100644 --- a/src/docs/guide/usage/linter/rules/jest/prefer-todo.md +++ b/src/docs/guide/usage/linter/rules/jest/prefer-todo.md @@ -1,10 +1,5 @@ - - # jest/prefer-todo
@@ -22,43 +17,16 @@ will be highlighted in the summary output. This rule triggers a warning if empty test cases are used without 'test.todo'. -### Examples - -Examples of **incorrect** code for this rule: +### Example ```javascript test("i need to write this test"); // invalid test("i need to write this test", () => {}); // invalid test.skip("i need to write this test", () => {}); // invalid -``` - -Examples of **correct** code for this rule: -```javascript test.todo("i need to write this test"); ``` -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny jest/prefer-todo --jest-plugin -``` - -```json [Config (.oxlintrc.json)] -{ - "plugins": ["jest"], - "rules": { - "jest/prefer-todo": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/jest/prefer_todo.rs) diff --git a/src/docs/guide/usage/linter/rules/jest/require-hook.md b/src/docs/guide/usage/linter/rules/jest/require-hook.md index aeaf21fc59b..3c458444cfc 100644 --- a/src/docs/guide/usage/linter/rules/jest/require-hook.md +++ b/src/docs/guide/usage/linter/rules/jest/require-hook.md @@ -1,10 +1,5 @@ - - # jest/require-hook
@@ -22,23 +17,13 @@ directly within the body of a `describe`, _except_ for the following: - Types - Calls to the standard Jest globals -### Why is this bad? - -Having setup and teardown code outside of hooks can lead to unpredictable test -behavior. Code that runs at the top level executes when the test file is loaded, -not when tests run, which can cause issues with test isolation and make tests -dependent on execution order. Using proper hooks like `beforeEach`, `beforeAll`, -`afterEach`, and `afterAll` ensures that setup and teardown code runs at the -correct time and maintains test isolation. - -### Examples - -Examples of **incorrect** code for this rule: +### Example ```javascript +// invalid +import { database, isCity } from "../database"; import { Logger } from "../../../src/Logger"; import { loadCities } from "../api"; -import { database, isCity } from "../database"; jest.mock("../api"); @@ -75,14 +60,11 @@ describe("when loading cities from the api", () => { }); }); clearCityDatabase(); -``` - -Examples of **correct** code for this rule: -```javascript +// valid +import { database, isCity } from "../database"; import { Logger } from "../../../src/Logger"; import { loadCities } from "../api"; -import { database, isCity } from "../database"; jest.mock("../api"); const initializeCityDatabase = () => { @@ -128,27 +110,6 @@ afterEach(() => { }); ``` -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny jest/require-hook --jest-plugin -``` - -```json [Config (.oxlintrc.json)] -{ - "plugins": ["jest"], - "rules": { - "jest/require-hook": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/jest/require_hook.rs) diff --git a/src/docs/guide/usage/linter/rules/jest/require-to-throw-message.md b/src/docs/guide/usage/linter/rules/jest/require-to-throw-message.md index b463022dc56..7ab1109ac35 100644 --- a/src/docs/guide/usage/linter/rules/jest/require-to-throw-message.md +++ b/src/docs/guide/usage/linter/rules/jest/require-to-throw-message.md @@ -1,10 +1,5 @@ - - # jest/require-to-throw-message
@@ -14,30 +9,18 @@ const source = `https://github.com/oxc-project/oxc/blob/${ data }/crates/oxc_lin This rule triggers a warning if `toThrow()` or `toThrowError()` is used without an error message. -### Why is this bad? - -Using `toThrow()` or `toThrowError()` without specifying an expected error message -makes tests less specific and harder to debug. When a test only checks that an -error was thrown but not what kind of error, it can pass even when the wrong -error is thrown, potentially hiding bugs. Providing an expected error message -or error type makes tests more precise and helps catch regressions more effectively. - -### Examples - -Examples of **incorrect** code for this rule: +### Example ```javascript +// invalid test("all the things", async () => { expect(() => a()).toThrow(); expect(() => a()).toThrowError(); await expect(a()).rejects.toThrow(); await expect(a()).rejects.toThrowError(); }); -``` - -Examples of **correct** code for this rule: -```javascript +// valid test("all the things", async () => { expect(() => a()).toThrow("a"); expect(() => a()).toThrowError("a"); @@ -46,27 +29,6 @@ test("all the things", async () => { }); ``` -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny jest/require-to-throw-message --jest-plugin -``` - -```json [Config (.oxlintrc.json)] -{ - "plugins": ["jest"], - "rules": { - "jest/require-to-throw-message": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/jest/require_to_throw_message.rs) diff --git a/src/docs/guide/usage/linter/rules/jest/require-top-level-describe.md b/src/docs/guide/usage/linter/rules/jest/require-top-level-describe.md index 72fb20bd6e2..832c853b04a 100644 --- a/src/docs/guide/usage/linter/rules/jest/require-top-level-describe.md +++ b/src/docs/guide/usage/linter/rules/jest/require-top-level-describe.md @@ -1,10 +1,5 @@ - - # jest/require-top-level-describe
@@ -12,23 +7,15 @@ const source = `https://github.com/oxc-project/oxc/blob/${ data }/crates/oxc_lin ### What it does -Requires test cases and hooks to be inside a top-level `describe` block. - -### Why is this bad? - -Having tests and hooks organized within `describe` blocks provides better -structure and grouping for test suites. It makes test output more readable -and helps with test organization, especially in larger codebases. - This rule triggers a warning if a test case (`test` and `it`) or a hook (`beforeAll`, `beforeEach`, `afterEach`, `afterAll`) is not located in a top-level `describe` block. -### Examples - -Examples of **incorrect** code for this rule: +### Example ```javascript +// invalid + // Above a describe block test("my test", () => {}); describe("test suite", () => { @@ -43,11 +30,9 @@ test("my test", () => {}); beforeAll("my beforeAll", () => {}); describe("test suite", () => {}); afterEach("my afterEach", () => {}); -``` -Examples of **correct** code for this rule: +//valid -```javascript // Above a describe block // In a describe block describe("test suite", () => { @@ -79,27 +64,6 @@ using the `maxNumberOfTopLevelDescribes` option: } ``` -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny jest/require-top-level-describe --jest-plugin -``` - -```json [Config (.oxlintrc.json)] -{ - "plugins": ["jest"], - "rules": { - "jest/require-top-level-describe": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/jest/require_top_level_describe.rs) diff --git a/src/docs/guide/usage/linter/rules/jest/valid-describe-callback.md b/src/docs/guide/usage/linter/rules/jest/valid-describe-callback.md index ab845d1ee08..11e4944f2ff 100644 --- a/src/docs/guide/usage/linter/rules/jest/valid-describe-callback.md +++ b/src/docs/guide/usage/linter/rules/jest/valid-describe-callback.md @@ -1,10 +1,5 @@ - - # jest/valid-describe-callback
@@ -25,9 +20,7 @@ callback function. This callback function: Using an improper `describe()` callback function can lead to unexpected test errors. -### Examples - -Examples of **incorrect** code for this rule: +### Example ```javascript // Async callback functions are not allowed @@ -36,7 +29,7 @@ describe("myFunction()", async () => { }); // Callback function parameters are not allowed -describe("myFunction()", done => { +describe("myFunction()", (done) => { // ... }); @@ -58,27 +51,6 @@ to use it, add the following configuration to your `.eslintrc.json`: } ``` -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny jest/valid-describe-callback --jest-plugin -``` - -```json [Config (.oxlintrc.json)] -{ - "plugins": ["jest"], - "rules": { - "jest/valid-describe-callback": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/jest/valid_describe_callback.rs) diff --git a/src/docs/guide/usage/linter/rules/jest/valid-expect.md b/src/docs/guide/usage/linter/rules/jest/valid-expect.md index f42b6d4d256..efdca296681 100644 --- a/src/docs/guide/usage/linter/rules/jest/valid-expect.md +++ b/src/docs/guide/usage/linter/rules/jest/valid-expect.md @@ -1,10 +1,5 @@ - - # jest/valid-expect
@@ -14,13 +9,11 @@ const source = `https://github.com/oxc-project/oxc/blob/${ data }/crates/oxc_lin Checks that `expect()` is called correctly. -### Why is this bad? +Why is this bad? -`expect()` is a function that is used to assert values in tests. -It should be called with a single argument, which is the value to be tested. -If you call `expect()` with no arguments, or with more than one argument, it will not work as expected. +`expect()` is a function that is used to assert values in tests. It should be called with a single argument, which is the value to be tested. If you call `expect()` with no arguments, or with more than one argument, it will not work as expected. -### Examples +### Example Examples of **incorrect** code for this rule: @@ -50,27 +43,6 @@ to use it, add the following configuration to your `.eslintrc.json`: } ``` -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny jest/valid-expect --jest-plugin -``` - -```json [Config (.oxlintrc.json)] -{ - "plugins": ["jest"], - "rules": { - "jest/valid-expect": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/jest/valid_expect.rs) diff --git a/src/docs/guide/usage/linter/rules/jest/valid-title.md b/src/docs/guide/usage/linter/rules/jest/valid-title.md index a44f705fcb4..fbdb5e72b0a 100644 --- a/src/docs/guide/usage/linter/rules/jest/valid-title.md +++ b/src/docs/guide/usage/linter/rules/jest/valid-title.md @@ -1,10 +1,5 @@ - - # jest/valid-title
@@ -24,11 +19,11 @@ Titles must be: - not prefixed with their block name, - have no leading or trailing spaces. -### Why is this bad? +Why is this bad? Titles that are not valid can be misleading and make it harder to understand the purpose of the test. -### Examples +### Example Examples of **incorrect** code for this rule: @@ -47,45 +42,11 @@ xtest("", () => {}); Examples of **correct** code for this rule: ```javascript -describe("foo", () => {}); -it("bar", () => {}); -test("baz", () => {}); -``` - -### Options - -```typescript -interface Options { - ignoreSpaces?: boolean; - ignoreTypeOfTestName?: boolean; - ignoreTypeOfDescribeName?: boolean; - disallowedWords?: string[]; - mustNotMatch?: Partial> | string; - mustMatch?: Partial> | string; -} -``` - -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: +describe('foo', () => {}); +it('bar', () => {}); +test('baz', () => {}); -::: code-group - -```bash [CLI] -oxlint --deny jest/valid-title --jest-plugin -``` - -```json [Config (.oxlintrc.json)] -{ - "plugins": ["jest"], - "rules": { - "jest/valid-title": "error" - } -} -``` - -::: ## References - -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/jest/valid_title.rs) +``` diff --git a/src/docs/guide/usage/linter/rules/jsdoc/check-access.md b/src/docs/guide/usage/linter/rules/jsdoc/check-access.md index aa6464378c6..dbb0cbe9bc5 100644 --- a/src/docs/guide/usage/linter/rules/jsdoc/check-access.md +++ b/src/docs/guide/usage/linter/rules/jsdoc/check-access.md @@ -1,10 +1,5 @@ - - # jsdoc/check-access
@@ -23,11 +18,7 @@ Also reports: ### Why is this bad? -It is important to have a consistent way of specifying access levels in JSDoc -comments. Using invalid or multiple access level tags creates confusion about -the intended visibility of documented elements and can lead to inconsistencies -in API documentation generation. Mixing different access tags or using invalid -values makes the documentation unclear and potentially misleading. +It is important to have a consistent way of specifying access levels. ### Examples @@ -47,27 +38,6 @@ Examples of **correct** code for this rule: /** @private */ ``` -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny jsdoc/check-access --jsdoc-plugin -``` - -```json [Config (.oxlintrc.json)] -{ - "plugins": ["jsdoc"], - "rules": { - "jsdoc/check-access": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/jsdoc/check_access.rs) diff --git a/src/docs/guide/usage/linter/rules/jsdoc/check-property-names.md b/src/docs/guide/usage/linter/rules/jsdoc/check-property-names.md index ba313cc259f..8e59741d5e5 100644 --- a/src/docs/guide/usage/linter/rules/jsdoc/check-property-names.md +++ b/src/docs/guide/usage/linter/rules/jsdoc/check-property-names.md @@ -1,10 +1,5 @@ - - # jsdoc/check-property-names
@@ -50,27 +45,6 @@ Examples of **correct** code for this rule: */ ``` -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny jsdoc/check-property-names --jsdoc-plugin -``` - -```json [Config (.oxlintrc.json)] -{ - "plugins": ["jsdoc"], - "rules": { - "jsdoc/check-property-names": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/jsdoc/check_property_names.rs) diff --git a/src/docs/guide/usage/linter/rules/jsdoc/check-tag-names.md b/src/docs/guide/usage/linter/rules/jsdoc/check-tag-names.md index acc12bcaedb..1da44e50c34 100644 --- a/src/docs/guide/usage/linter/rules/jsdoc/check-tag-names.md +++ b/src/docs/guide/usage/linter/rules/jsdoc/check-tag-names.md @@ -1,10 +1,5 @@ - - # jsdoc/check-tag-names
@@ -39,62 +34,6 @@ Examples of **correct** code for this rule: /** @param */ ``` -### Options - -Configuration for allowed tags is done via [`settings.jsdoc.tagNamePreference`](/docs/guide/usage/linter/config-file-reference.html#settings-jsdoc-tagnamepreference). -There is no CLI-only parameter for this rule. - -You can add custom tags by adding a key-value pair where both match the name of the tag you want to add, like so: - -::: code-group - -```json [Config (.oxlintrc.json)] -{ - "plugins": ["jsdoc"], - "rules": { - "jsdoc/check-tag-names": "error" - }, - "settings": { // [!code highlight:7] - "jsdoc": { - "tagNamePreference": { - "customTagName": "customTagName" - } - } - } -} -``` - -::: - -Examples of correct code for this rule with the above configuration, adding the `customTagName` tag: - -```js -/** - * @customTagName - */ -``` - -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny jsdoc/check-tag-names --jsdoc-plugin -``` - -```json [Config (.oxlintrc.json)] -{ - "plugins": ["jsdoc"], - "rules": { - "jsdoc/check-tag-names": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/jsdoc/check_tag_names.rs) diff --git a/src/docs/guide/usage/linter/rules/jsdoc/empty-tags.md b/src/docs/guide/usage/linter/rules/jsdoc/empty-tags.md index 4507ba5f7ad..4bb46410352 100644 --- a/src/docs/guide/usage/linter/rules/jsdoc/empty-tags.md +++ b/src/docs/guide/usage/linter/rules/jsdoc/empty-tags.md @@ -1,10 +1,5 @@ - - # jsdoc/empty-tags
@@ -55,27 +50,6 @@ Examples of **correct** code for this rule: /** @private */ ``` -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny jsdoc/empty-tags --jsdoc-plugin -``` - -```json [Config (.oxlintrc.json)] -{ - "plugins": ["jsdoc"], - "rules": { - "jsdoc/empty-tags": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/jsdoc/empty_tags.rs) diff --git a/src/docs/guide/usage/linter/rules/jsdoc/implements-on-classes.md b/src/docs/guide/usage/linter/rules/jsdoc/implements-on-classes.md index fbfc2ff2e08..c05805a468d 100644 --- a/src/docs/guide/usage/linter/rules/jsdoc/implements-on-classes.md +++ b/src/docs/guide/usage/linter/rules/jsdoc/implements-on-classes.md @@ -1,10 +1,5 @@ - - # jsdoc/implements-on-classes
@@ -46,27 +41,6 @@ class Foo { function quux() {} ``` -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny jsdoc/implements-on-classes --jsdoc-plugin -``` - -```json [Config (.oxlintrc.json)] -{ - "plugins": ["jsdoc"], - "rules": { - "jsdoc/implements-on-classes": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/jsdoc/implements_on_classes.rs) diff --git a/src/docs/guide/usage/linter/rules/jsdoc/no-defaults.md b/src/docs/guide/usage/linter/rules/jsdoc/no-defaults.md index 93b380e0553..dcc9b9f64ec 100644 --- a/src/docs/guide/usage/linter/rules/jsdoc/no-defaults.md +++ b/src/docs/guide/usage/linter/rules/jsdoc/no-defaults.md @@ -1,10 +1,5 @@ - - # jsdoc/no-defaults
@@ -39,27 +34,6 @@ function quux(foo) {} function quux(foo) {} ``` -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny jsdoc/no-defaults --jsdoc-plugin -``` - -```json [Config (.oxlintrc.json)] -{ - "plugins": ["jsdoc"], - "rules": { - "jsdoc/no-defaults": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/jsdoc/no_defaults.rs) diff --git a/src/docs/guide/usage/linter/rules/jsdoc/require-param-description.md b/src/docs/guide/usage/linter/rules/jsdoc/require-param-description.md index a652cac233e..4ad302d53c7 100644 --- a/src/docs/guide/usage/linter/rules/jsdoc/require-param-description.md +++ b/src/docs/guide/usage/linter/rules/jsdoc/require-param-description.md @@ -1,10 +1,5 @@ - - # jsdoc/require-param-description
@@ -34,27 +29,6 @@ Examples of **correct** code for this rule: function quux(foo) {} ``` -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny jsdoc/require-param-description --jsdoc-plugin -``` - -```json [Config (.oxlintrc.json)] -{ - "plugins": ["jsdoc"], - "rules": { - "jsdoc/require-param-description": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/jsdoc/require_param_description.rs) diff --git a/src/docs/guide/usage/linter/rules/jsdoc/require-param-name.md b/src/docs/guide/usage/linter/rules/jsdoc/require-param-name.md index af5b458f3bc..a118e8de6d3 100644 --- a/src/docs/guide/usage/linter/rules/jsdoc/require-param-name.md +++ b/src/docs/guide/usage/linter/rules/jsdoc/require-param-name.md @@ -1,10 +1,5 @@ - - # jsdoc/require-param-name
@@ -34,27 +29,6 @@ Examples of **correct** code for this rule: function quux(foo) {} ``` -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny jsdoc/require-param-name --jsdoc-plugin -``` - -```json [Config (.oxlintrc.json)] -{ - "plugins": ["jsdoc"], - "rules": { - "jsdoc/require-param-name": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/jsdoc/require_param_name.rs) diff --git a/src/docs/guide/usage/linter/rules/jsdoc/require-param-type.md b/src/docs/guide/usage/linter/rules/jsdoc/require-param-type.md index 7dc3c498b00..d23858f2001 100644 --- a/src/docs/guide/usage/linter/rules/jsdoc/require-param-type.md +++ b/src/docs/guide/usage/linter/rules/jsdoc/require-param-type.md @@ -1,10 +1,5 @@ - - # jsdoc/require-param-type
@@ -34,27 +29,6 @@ Examples of **correct** code for this rule: function quux(foo) {} ``` -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny jsdoc/require-param-type --jsdoc-plugin -``` - -```json [Config (.oxlintrc.json)] -{ - "plugins": ["jsdoc"], - "rules": { - "jsdoc/require-param-type": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/jsdoc/require_param_type.rs) diff --git a/src/docs/guide/usage/linter/rules/jsdoc/require-param.md b/src/docs/guide/usage/linter/rules/jsdoc/require-param.md index 083887e2278..02bc96a56e6 100644 --- a/src/docs/guide/usage/linter/rules/jsdoc/require-param.md +++ b/src/docs/guide/usage/linter/rules/jsdoc/require-param.md @@ -1,10 +1,5 @@ - - # jsdoc/require-param
@@ -34,27 +29,6 @@ Examples of **correct** code for this rule: function quux(foo) {} ``` -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny jsdoc/require-param --jsdoc-plugin -``` - -```json [Config (.oxlintrc.json)] -{ - "plugins": ["jsdoc"], - "rules": { - "jsdoc/require-param": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/jsdoc/require_param.rs) diff --git a/src/docs/guide/usage/linter/rules/jsdoc/require-property-description.md b/src/docs/guide/usage/linter/rules/jsdoc/require-property-description.md index 7b2563cc6be..5a92d1e32c8 100644 --- a/src/docs/guide/usage/linter/rules/jsdoc/require-property-description.md +++ b/src/docs/guide/usage/linter/rules/jsdoc/require-property-description.md @@ -1,10 +1,5 @@ - - # jsdoc/require-property-description
@@ -38,27 +33,6 @@ Examples of **correct** code for this rule: */ ``` -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny jsdoc/require-property-description --jsdoc-plugin -``` - -```json [Config (.oxlintrc.json)] -{ - "plugins": ["jsdoc"], - "rules": { - "jsdoc/require-property-description": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/jsdoc/require_property_description.rs) diff --git a/src/docs/guide/usage/linter/rules/jsdoc/require-property-name.md b/src/docs/guide/usage/linter/rules/jsdoc/require-property-name.md index d99084054e8..66eeae70906 100644 --- a/src/docs/guide/usage/linter/rules/jsdoc/require-property-name.md +++ b/src/docs/guide/usage/linter/rules/jsdoc/require-property-name.md @@ -1,10 +1,5 @@ - - # jsdoc/require-property-name
@@ -38,27 +33,6 @@ Examples of **correct** code for this rule: */ ``` -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny jsdoc/require-property-name --jsdoc-plugin -``` - -```json [Config (.oxlintrc.json)] -{ - "plugins": ["jsdoc"], - "rules": { - "jsdoc/require-property-name": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/jsdoc/require_property_name.rs) diff --git a/src/docs/guide/usage/linter/rules/jsdoc/require-property-type.md b/src/docs/guide/usage/linter/rules/jsdoc/require-property-type.md index e38ff32626f..49848649e48 100644 --- a/src/docs/guide/usage/linter/rules/jsdoc/require-property-type.md +++ b/src/docs/guide/usage/linter/rules/jsdoc/require-property-type.md @@ -1,10 +1,5 @@ - - # jsdoc/require-property-type
@@ -38,27 +33,6 @@ Examples of **correct** code for this rule: */ ``` -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny jsdoc/require-property-type --jsdoc-plugin -``` - -```json [Config (.oxlintrc.json)] -{ - "plugins": ["jsdoc"], - "rules": { - "jsdoc/require-property-type": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/jsdoc/require_property_type.rs) diff --git a/src/docs/guide/usage/linter/rules/jsdoc/require-property.md b/src/docs/guide/usage/linter/rules/jsdoc/require-property.md index 97d8440a305..9b1b7c671f6 100644 --- a/src/docs/guide/usage/linter/rules/jsdoc/require-property.md +++ b/src/docs/guide/usage/linter/rules/jsdoc/require-property.md @@ -1,10 +1,5 @@ - - # jsdoc/require-property
@@ -15,8 +10,6 @@ const source = `https://github.com/oxc-project/oxc/blob/${ data }/crates/oxc_lin Requires that all `@typedef` and `@namespace` tags have `@property` tags when their type is a plain `object`, `Object`, or `PlainObject`. -Note: this rule can be configured via [jsdoc settings](https://oxc.rs/docs/guide/usage/linter/config-file-reference.html#settings) option. - ### Why is this bad? Object type should have properties defined. @@ -49,27 +42,6 @@ Examples of **correct** code for this rule: */ ``` -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny jsdoc/require-property --jsdoc-plugin -``` - -```json [Config (.oxlintrc.json)] -{ - "plugins": ["jsdoc"], - "rules": { - "jsdoc/require-property": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/jsdoc/require_property.rs) diff --git a/src/docs/guide/usage/linter/rules/jsdoc/require-returns-description.md b/src/docs/guide/usage/linter/rules/jsdoc/require-returns-description.md index bb58dffad2c..7fd0b869d42 100644 --- a/src/docs/guide/usage/linter/rules/jsdoc/require-returns-description.md +++ b/src/docs/guide/usage/linter/rules/jsdoc/require-returns-description.md @@ -1,10 +1,5 @@ - - # jsdoc/require-returns-description
@@ -13,7 +8,7 @@ const source = `https://github.com/oxc-project/oxc/blob/${ data }/crates/oxc_lin ### What it does Requires that the `@returns` tag has a description value. -The error will not be reported if the return value is `void`or `undefined` or if it is `Promise` or `Promise`. +The error will not be reported if the return value is `void `or `undefined` or if it is `Promise` or `Promise`. ### Why is this bad? @@ -35,27 +30,6 @@ Examples of **correct** code for this rule: function quux(foo) {} ``` -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny jsdoc/require-returns-description --jsdoc-plugin -``` - -```json [Config (.oxlintrc.json)] -{ - "plugins": ["jsdoc"], - "rules": { - "jsdoc/require-returns-description": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/jsdoc/require_returns_description.rs) diff --git a/src/docs/guide/usage/linter/rules/jsdoc/require-returns-type.md b/src/docs/guide/usage/linter/rules/jsdoc/require-returns-type.md index be14b259a7e..ac2cec5d37c 100644 --- a/src/docs/guide/usage/linter/rules/jsdoc/require-returns-type.md +++ b/src/docs/guide/usage/linter/rules/jsdoc/require-returns-type.md @@ -1,10 +1,5 @@ - - # jsdoc/require-returns-type
@@ -34,27 +29,6 @@ Examples of **correct** code for this rule: function quux(foo) {} ``` -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny jsdoc/require-returns-type --jsdoc-plugin -``` - -```json [Config (.oxlintrc.json)] -{ - "plugins": ["jsdoc"], - "rules": { - "jsdoc/require-returns-type": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/jsdoc/require_returns_type.rs) diff --git a/src/docs/guide/usage/linter/rules/jsdoc/require-returns.md b/src/docs/guide/usage/linter/rules/jsdoc/require-returns.md index e45f299e689..efc294bd006 100644 --- a/src/docs/guide/usage/linter/rules/jsdoc/require-returns.md +++ b/src/docs/guide/usage/linter/rules/jsdoc/require-returns.md @@ -1,10 +1,5 @@ - - # jsdoc/require-returns
@@ -47,27 +42,6 @@ function quux() { } ``` -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny jsdoc/require-returns --jsdoc-plugin -``` - -```json [Config (.oxlintrc.json)] -{ - "plugins": ["jsdoc"], - "rules": { - "jsdoc/require-returns": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/jsdoc/require_returns.rs) diff --git a/src/docs/guide/usage/linter/rules/jsdoc/require-yields.md b/src/docs/guide/usage/linter/rules/jsdoc/require-yields.md index e378c53d74b..70ea37deb34 100644 --- a/src/docs/guide/usage/linter/rules/jsdoc/require-yields.md +++ b/src/docs/guide/usage/linter/rules/jsdoc/require-yields.md @@ -1,10 +1,5 @@ - - # jsdoc/require-yields
@@ -44,27 +39,6 @@ function* quux(foo) { } ``` -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny jsdoc/require-yields --jsdoc-plugin -``` - -```json [Config (.oxlintrc.json)] -{ - "plugins": ["jsdoc"], - "rules": { - "jsdoc/require-yields": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/jsdoc/require_yields.rs) diff --git a/src/docs/guide/usage/linter/rules/jsx_a11y/alt-text.md b/src/docs/guide/usage/linter/rules/jsx_a11y/alt-text.md index 8cc0615c07f..25a3f1cf785 100644 --- a/src/docs/guide/usage/linter/rules/jsx_a11y/alt-text.md +++ b/src/docs/guide/usage/linter/rules/jsx_a11y/alt-text.md @@ -1,10 +1,5 @@ - - # jsx_a11y/alt-text
@@ -15,54 +10,36 @@ const source = `https://github.com/oxc-project/oxc/blob/${ data }/crates/oxc_lin Enforce that all elements that require alternative text have meaningful information to relay back to the end user. -### Why is this bad? +### Why is this necessary? Alternative text is a critical component of accessibility for screen -reader users, enabling them to understand the content and function of -an element. Missing or inadequate alt text makes content inaccessible -to users who rely on assistive technologies. +reader users, enabling them to understand the content and function +of an element. -### Examples +### What it checks -Examples of **incorrect** code for this rule: +This rule checks for alternative text on the following elements: +``, ``, ``, and ``. -```jsx - - - - -``` +### How to fix it -Examples of **correct** code for this rule: +Ensure that the `alt` attribute is present and contains meaningful +text that describes the element's content or purpose. + +### Example + +Examples of **incorrect** code for this rule: ```jsx A close-up of a white daisy - - -Navigation link ``` -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny jsx-a11y/alt-text --jsx-a11y-plugin -``` +Examples of **correct** code for this rule: -```json [Config (.oxlintrc.json)] -{ - "plugins": ["jsx-a11y"], - "rules": { - "jsx-a11y/alt-text": "error" - } -} +```jsx + ``` -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/jsx_a11y/alt_text.rs) diff --git a/src/docs/guide/usage/linter/rules/jsx_a11y/anchor-ambiguous-text.md b/src/docs/guide/usage/linter/rules/jsx_a11y/anchor-ambiguous-text.md index 30f1336356a..f89c46035ec 100644 --- a/src/docs/guide/usage/linter/rules/jsx_a11y/anchor-ambiguous-text.md +++ b/src/docs/guide/usage/linter/rules/jsx_a11y/anchor-ambiguous-text.md @@ -1,10 +1,5 @@ - - # jsx_a11y/anchor-ambiguous-text
@@ -42,27 +37,6 @@ Examples of **correct** code for this rule: click here ``` -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny jsx-a11y/anchor-ambiguous-text --jsx-a11y-plugin -``` - -```json [Config (.oxlintrc.json)] -{ - "plugins": ["jsx-a11y"], - "rules": { - "jsx-a11y/anchor-ambiguous-text": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/jsx_a11y/anchor_ambiguous_text.rs) diff --git a/src/docs/guide/usage/linter/rules/jsx_a11y/anchor-has-content.md b/src/docs/guide/usage/linter/rules/jsx_a11y/anchor-has-content.md index d5729bc7411..d2e36e32472 100644 --- a/src/docs/guide/usage/linter/rules/jsx_a11y/anchor-has-content.md +++ b/src/docs/guide/usage/linter/rules/jsx_a11y/anchor-has-content.md @@ -1,10 +1,5 @@ - - # jsx_a11y/anchor-has-content
@@ -41,27 +36,6 @@ Alternatively, you may use the `title` prop or the `aria-label` prop. ``` -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny jsx-a11y/anchor-has-content --jsx-a11y-plugin -``` - -```json [Config (.oxlintrc.json)] -{ - "plugins": ["jsx-a11y"], - "rules": { - "jsx-a11y/anchor-has-content": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/jsx_a11y/anchor_has_content.rs) diff --git a/src/docs/guide/usage/linter/rules/jsx_a11y/anchor-is-valid.md b/src/docs/guide/usage/linter/rules/jsx_a11y/anchor-is-valid.md index cf1b8f5686d..db97a764b59 100644 --- a/src/docs/guide/usage/linter/rules/jsx_a11y/anchor-is-valid.md +++ b/src/docs/guide/usage/linter/rules/jsx_a11y/anchor-is-valid.md @@ -1,10 +1,5 @@ - - # jsx_a11y/anchor-is-valid
@@ -29,18 +24,24 @@ Consider the following: ```jsx <> - Perform action - Perform action + + Perform action + + + Perform action + Perform action -; + ``` All these anchor implementations indicate that the element is only used to execute JavaScript code. All the above should be replaced with: ```jsx -; + ``` +` + ### Why is this bad? There are **many reasons** why an anchor should not have a logic and have a correct `href` attribute: @@ -58,7 +59,7 @@ There are **many reasons** why an anchor should not have a logic and have a corr navigate here navigate here navigate here -; + ``` #### Invalid @@ -69,35 +70,16 @@ There are **many reasons** why an anchor should not have a logic and have a corr navigate here navigate here navigate here - navigate here -; + + navigate here + + ``` ### Reference - [WCAG 2.1.1](https://www.w3.org/WAI/WCAG21/Understanding/keyboard) -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny jsx-a11y/anchor-is-valid --jsx-a11y-plugin -``` - -```json [Config (.oxlintrc.json)] -{ - "plugins": ["jsx-a11y"], - "rules": { - "jsx-a11y/anchor-is-valid": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/jsx_a11y/anchor_is_valid.rs) diff --git a/src/docs/guide/usage/linter/rules/jsx_a11y/aria-activedescendant-has-tabindex.md b/src/docs/guide/usage/linter/rules/jsx_a11y/aria-activedescendant-has-tabindex.md index 8974a34d004..a348e60cf61 100644 --- a/src/docs/guide/usage/linter/rules/jsx_a11y/aria-activedescendant-has-tabindex.md +++ b/src/docs/guide/usage/linter/rules/jsx_a11y/aria-activedescendant-has-tabindex.md @@ -1,10 +1,5 @@ - - # jsx_a11y/aria-activedescendant-has-tabindex
@@ -14,22 +9,7 @@ const source = `https://github.com/oxc-project/oxc/blob/${ data }/crates/oxc_lin Enforce elements with aria-activedescendant are tabbable. -### Why is this bad? - -Elements with `aria-activedescendant` must be tabbable for users to -navigate to them using keyboard input. Without proper tabindex, screen -reader users cannot access the element through keyboard navigation, -making the functionality inaccessible. - -### Examples - -Examples of **incorrect** code for this rule: - -```jsx -const Bad =
; -``` - -Examples of **correct** code for this rule: +### Example ```jsx const Good = ( @@ -51,29 +31,10 @@ const Good = ( ); -``` - -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group -```bash [CLI] -oxlint --deny jsx-a11y/aria-activedescendant-has-tabindex --jsx-a11y-plugin -``` - -```json [Config (.oxlintrc.json)] -{ - "plugins": ["jsx-a11y"], - "rules": { - "jsx-a11y/aria-activedescendant-has-tabindex": "error" - } -} +const Bad =
; ``` -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/jsx_a11y/aria_activedescendant_has_tabindex.rs) diff --git a/src/docs/guide/usage/linter/rules/jsx_a11y/aria-props.md b/src/docs/guide/usage/linter/rules/jsx_a11y/aria-props.md index 8258e0e80ce..1328d57185f 100644 --- a/src/docs/guide/usage/linter/rules/jsx_a11y/aria-props.md +++ b/src/docs/guide/usage/linter/rules/jsx_a11y/aria-props.md @@ -1,10 +1,5 @@ - - # jsx_a11y/aria-props
@@ -25,41 +20,20 @@ for users with disabilities to use the site effectively. This rule includes fixes for some common typos. -### Examples +### Example Examples of **incorrect** code for this rule: ```jsx -; + ``` Examples of **correct** code for this rule: ```jsx -; + ``` -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny jsx-a11y/aria-props --jsx-a11y-plugin -``` - -```json [Config (.oxlintrc.json)] -{ - "plugins": ["jsx-a11y"], - "rules": { - "jsx-a11y/aria-props": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/jsx_a11y/aria_props.rs) diff --git a/src/docs/guide/usage/linter/rules/jsx_a11y/aria-role.md b/src/docs/guide/usage/linter/rules/jsx_a11y/aria-role.md index c203ba7f0e9..7e61fbe5a0d 100644 --- a/src/docs/guide/usage/linter/rules/jsx_a11y/aria-role.md +++ b/src/docs/guide/usage/linter/rules/jsx_a11y/aria-role.md @@ -1,10 +1,5 @@ - - # jsx_a11y/aria-role
@@ -48,10 +43,13 @@ This rule takes one optional object argument of type object: ```json { "rules": { - "jsx-a11y/aria-role": [2, { - "allowedInvalidRoles": ["text"], - "ignoreNonDOM": true - }] + "jsx-a11y/aria-role": [ + 2, + { + "allowedInvalidRoles": ["text"], + "ignoreNonDOM": true + } + ] } } ``` @@ -63,7 +61,7 @@ you need to use a non-standard role. For the `ignoreNonDOM` option, this determines if developer created components are checked. -### Examples +### Example Examples of **incorrect** code for this rule: @@ -83,27 +81,6 @@ Examples of **correct** code for this rule: ``` -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny jsx-a11y/aria-role --jsx-a11y-plugin -``` - -```json [Config (.oxlintrc.json)] -{ - "plugins": ["jsx-a11y"], - "rules": { - "jsx-a11y/aria-role": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/jsx_a11y/aria_role.rs) diff --git a/src/docs/guide/usage/linter/rules/jsx_a11y/aria-unsupported-elements.md b/src/docs/guide/usage/linter/rules/jsx_a11y/aria-unsupported-elements.md index 9b2cd31d80e..6aae83c2e17 100644 --- a/src/docs/guide/usage/linter/rules/jsx_a11y/aria-unsupported-elements.md +++ b/src/docs/guide/usage/linter/rules/jsx_a11y/aria-unsupported-elements.md @@ -1,10 +1,5 @@ - - # jsx_a11y/aria-unsupported-elements
@@ -15,51 +10,25 @@ const source = `https://github.com/oxc-project/oxc/blob/${ data }/crates/oxc_lin ### What it does -Enforces that reserved DOM elements do not contain ARIA roles, states, -or properties. - -### Why is this bad? - Certain reserved DOM elements do not support ARIA roles, states and properties. This is often because they are not visible, for example -`meta`, `html`, `script`, `style`. Adding ARIA attributes to these -elements is meaningless and can create confusion for screen readers. +`meta`, `html`, `script`, `style`. This rule enforces that these DOM +elements do not contain the `role` and/or `aria-*` props. -### Examples +### Example Examples of **incorrect** code for this rule: ```jsx -; + ``` Examples of **correct** code for this rule: ```jsx -; + ``` -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny jsx-a11y/aria-unsupported-elements --jsx-a11y-plugin -``` - -```json [Config (.oxlintrc.json)] -{ - "plugins": ["jsx-a11y"], - "rules": { - "jsx-a11y/aria-unsupported-elements": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/jsx_a11y/aria_unsupported_elements.rs) diff --git a/src/docs/guide/usage/linter/rules/jsx_a11y/autocomplete-valid.md b/src/docs/guide/usage/linter/rules/jsx_a11y/autocomplete-valid.md index e680e2868db..55d76fd4b87 100644 --- a/src/docs/guide/usage/linter/rules/jsx_a11y/autocomplete-valid.md +++ b/src/docs/guide/usage/linter/rules/jsx_a11y/autocomplete-valid.md @@ -1,10 +1,5 @@ - - # jsx_a11y/autocomplete-valid
@@ -18,41 +13,20 @@ Enforces that an element's autocomplete attribute must be a valid value. Incorrectly using the autocomplete attribute may decrease the accessibility of the website for users. -### Examples +### Example Examples of **incorrect** code for this rule: ```jsx -; + ``` Examples of **correct** code for this rule: ```jsx -; + ``` -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny jsx-a11y/autocomplete-valid --jsx-a11y-plugin -``` - -```json [Config (.oxlintrc.json)] -{ - "plugins": ["jsx-a11y"], - "rules": { - "jsx-a11y/autocomplete-valid": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/jsx_a11y/autocomplete_valid.rs) diff --git a/src/docs/guide/usage/linter/rules/jsx_a11y/click-events-have-key-events.md b/src/docs/guide/usage/linter/rules/jsx_a11y/click-events-have-key-events.md index 9aebbc20e33..6a811afe61c 100644 --- a/src/docs/guide/usage/linter/rules/jsx_a11y/click-events-have-key-events.md +++ b/src/docs/guide/usage/linter/rules/jsx_a11y/click-events-have-key-events.md @@ -1,10 +1,5 @@ - - # jsx_a11y/click-events-have-key-events
@@ -19,41 +14,20 @@ Enforce onClick is accompanied by at least one of the following: onKeyUp, onKeyD Coding for the keyboard is important for users with physical disabilities who cannot use a mouse, AT compatibility, and screenreader users. This does not apply for interactive or hidden elements. -### Examples +### Example Examples of **incorrect** code for this rule: ```jsx -
void 0} />; +
void 0} /> ``` Examples of **correct** code for this rule: ```jsx -
void 0} onKeyDown={() => void 0} />; +
void 0} onKeyDown={() => void 0} /> ``` -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny jsx-a11y/click-events-have-key-events --jsx-a11y-plugin -``` - -```json [Config (.oxlintrc.json)] -{ - "plugins": ["jsx-a11y"], - "rules": { - "jsx-a11y/click-events-have-key-events": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/jsx_a11y/click_events_have_key_events.rs) diff --git a/src/docs/guide/usage/linter/rules/jsx_a11y/heading-has-content.md b/src/docs/guide/usage/linter/rules/jsx_a11y/heading-has-content.md index 4229cfa72a9..436305841e2 100644 --- a/src/docs/guide/usage/linter/rules/jsx_a11y/heading-has-content.md +++ b/src/docs/guide/usage/linter/rules/jsx_a11y/heading-has-content.md @@ -1,10 +1,5 @@ - - # jsx_a11y/heading-has-content
@@ -23,41 +18,20 @@ If the heading is empty or the text cannot be accessed, this could either confuse users or even prevent them from accessing information on the page's structure. -### Examples +### Example Examples of **incorrect** code for this rule: ```jsx -

; +

``` Examples of **correct** code for this rule: ```jsx -

Foo

; +

Foo

``` -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny jsx-a11y/heading-has-content --jsx-a11y-plugin -``` - -```json [Config (.oxlintrc.json)] -{ - "plugins": ["jsx-a11y"], - "rules": { - "jsx-a11y/heading-has-content": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/jsx_a11y/heading_has_content.rs) diff --git a/src/docs/guide/usage/linter/rules/jsx_a11y/html-has-lang.md b/src/docs/guide/usage/linter/rules/jsx_a11y/html-has-lang.md index edb62464dad..38a8e03e4de 100644 --- a/src/docs/guide/usage/linter/rules/jsx_a11y/html-has-lang.md +++ b/src/docs/guide/usage/linter/rules/jsx_a11y/html-has-lang.md @@ -1,10 +1,5 @@ - - # jsx_a11y/html-has-lang
@@ -21,41 +16,20 @@ the screen reader assumes the default language set by the user. Language settings become an issue for users who speak multiple languages and access website in more than one language. -### Examples +### Example Examples of **incorrect** code for this rule: ```jsx -; + ``` Examples of **correct** code for this rule: ```jsx -; + ``` -## How to use - -To **enable** this rule in the CLI or using the config file, you can use: - -::: code-group - -```bash [CLI] -oxlint --deny jsx-a11y/html-has-lang --jsx-a11y-plugin -``` - -```json [Config (.oxlintrc.json)] -{ - "plugins": ["jsx-a11y"], - "rules": { - "jsx-a11y/html-has-lang": "error" - } -} -``` - -::: - ## References -- Rule Source +- [Rule Source](https://github.com/oxc-project/oxc/blob/36ebb3e7841818c238c44349d6cf859db4177d55/crates/oxc_linter/src/rules/jsx_a11y/html_has_lang.rs) diff --git a/src/docs/guide/usage/linter/rules/jsx_a11y/iframe-has-title.md b/src/docs/guide/usage/linter/rules/jsx_a11y/iframe-has-title.md index f9025965b8b..d0adba89bca 100644 --- a/src/docs/guide/usage/linter/rules/jsx_a11y/iframe-has-title.md +++ b/src/docs/guide/usage/linter/rules/jsx_a11y/iframe-has-title.md @@ -1,10 +1,5 @@ - - # jsx_a11y/iframe-has-title
@@ -16,12 +11,14 @@ Enforce iframe elements have a title attribute. ### Why is this bad? -Screen reader users rely on a iframe title to describe the contents of -the iframe. Navigating through iframe and iframe elements quickly -becomes difficult and confusing for users of this technology if the -markup does not contain a title attribute. +Screen reader users rely on a iframe title to describe the contents of the iframe. +Navigating through iframe and iframe elements quickly becomes difficult and confusing for users of this technology if the markup does not contain a title attribute. + +### What it checks + +This rule checks for title property on iframe element. -### Examples +### Example Examples of **incorrect** code for this rule: @@ -44,27 +41,6 @@ Examples of **correct** code for this rule: