My page title

``` ## Configuration This rule accepts a configuration object with the following properties: ### allowExpressionValues type: `boolean` default: `true` If `true`, allows tabIndex values to be expression values (e.g., variables, ternaries). If `false`, only string literal values are allowed. ### roles type: `string[]` default: `["tabpanel"]` An array of ARIA roles that should be considered interactive. ### tags type: `string[]` default: `[]` An array of custom HTML elements that should be considered interactive. ## How to use To **enable** this rule using the config file or in the CLI, you can use: ::: code-group ```json [Config (.oxlintrc.json)] { "plugins": ["jsx-a11y"], "rules": { "jsx-a11y/no-noninteractive-tabindex": "error" } } ``` ```bash [CLI] oxlint --deny jsx-a11y/no-noninteractive-tabindex --jsx-a11y-plugin ``` ::: ## References * Rule Source --- # Source: https://oxc.rs/docs/guide/usage/linter/rules/eslint/no-nonoctal-decimal-escape.md --- url: /docs/guide/usage/linter/rules/eslint/no-nonoctal-decimal-escape.md --- ### What it does This rule disallows \8 and \9 escape sequences in string literals ### Why is this bad? ECMAScript specification treats \8 and \9 in string literals as a legacy feature ### Examples Examples of **incorrect** code for this rule: ```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 using the config file or in the CLI, you can use: ::: code-group ```json [Config (.oxlintrc.json)] { "rules": { "no-nonoctal-decimal-escape": "error" } } ``` ```bash [CLI] oxlint --deny no-nonoctal-decimal-escape ``` ::: ## References * Rule Source --- # Source: https://oxc.rs/docs/guide/usage/linter/rules/unicorn/no-null.md ## What it does Disallow the use of the `null` literal, to encourage using `undefined` instead. ## Why is this bad? There are some reasons for using `undefined` instead of `null`. * From experience, most developers use `null` and `undefined` inconsistently and interchangeably, and few know when to use which. * Supporting both `null` and `undefined` complicates input validation. * Using `null` makes TypeScript types more verbose: `type A = {foo?: string | null}` vs `type A = {foo?: string}`. ## Examples Examples of **incorrect** code for this rule: ```javascript let foo = null; ``` Examples of **correct** code for this rule: ```javascript let foo; ``` ## Configuration This rule accepts a configuration object with the following properties: ## checkStrictEquality type: `boolean` default: `false` When set to `true`, the rule will also check strict equality/inequality comparisons (`===` and `!==`) against `null`. ## How to use To **enable** this rule using the config file or in the CLI, you can use: ::: code-group ```json [Config (.oxlintrc.json)] { "rules": { "unicorn/no-null": "error" } } ``` ```bash [CLI] oxlint --deny unicorn/no-null ``` ::: ## References * Rule Source --- # Source: https://oxc.rs/docs/guide/usage/linter/rules/eslint/no-obj-calls.md --- url: /docs/guide/usage/linter/rules/eslint/no-obj-calls.md --- ### What it does Disallow calling some global objects as functions. This rule can be disabled for TypeScript code, as the TypeScript compiler enforces this check. ### Why is this bad? Some global objects are not intended to be called as functions. Calling them as functions will usually result in a TypeError being thrown. ### Examples Examples of **incorrect** code for this rule: ```javascript let math = Math(); let newMath = new Math(); let json = JSON(); let newJson = new JSON(); let atomics = Atomics(); let newAtomics = new Atomics(); let intl = Intl(); let newIntl = new Intl(); let reflect = Reflect(); let newReflect = new Reflect(); ``` Examples of **correct** code for this rule: ```javascript 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 using the config file or in the CLI, you can use: ::: code-group ```json [Config (.oxlintrc.json)] { "rules": { "no-obj-calls": "error" } } ``` ```bash [CLI] oxlint --deny no-obj-calls ``` ::: ## References * Rule Source --- # Source: https://oxc.rs/docs/guide/usage/linter/rules/unicorn/no-object-as-default-parameter.md ## What it does Disallow the use of an object literal as a default value for a parameter. ## Why is this bad? Default parameters should not be passed to a function through an object literal. The `foo = {a: false}` parameter works fine if only used with one option. As soon as additional options are added, you risk replacing the whole `foo = {a: false, b: true}` object when passing only one option: `{a: true}`. For this reason, object destructuring should be used instead. ## Examples Examples of **incorrect** code for this rule: ```javascript function foo(foo = { a: false }) {} ``` Examples of **correct** code for this rule: ```javascript function foo({ a = false } = {}) {} ``` ## How to use To **enable** this rule using the config file or in the CLI, you can use: ::: code-group ```json [Config (.oxlintrc.json)] { "rules": { "unicorn/no-object-as-default-parameter": "error" } } ``` ```bash [CLI] oxlint --deny unicorn/no-object-as-default-parameter ``` ::: ## References * Rule Source --- # Source: https://oxc.rs/docs/guide/usage/linter/rules/eslint/no-object-constructor.md --- url: /docs/guide/usage/linter/rules/eslint/no-object-constructor.md --- ### What it does Disallow calls to the Object constructor without an argument ### Why is this bad? Use of the Object constructor to construct a new empty object is generally discouraged in favor of object literal notation because of conciseness and because the Object global may be redefined. The exception is when the Object constructor is used to intentionally wrap a specified value which is passed as an argument. ### Examples Examples of **incorrect** code for this rule: ```js Object(); new Object(); ``` 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(); ``` ## How to use To **enable** this rule using the config file or in the CLI, you can use: ::: code-group ```json [Config (.oxlintrc.json)] { "rules": { "no-object-constructor": "error" } } ``` ```bash [CLI] oxlint --deny no-object-constructor ``` ::: ## References * Rule Source --- # Source: https://oxc.rs/docs/guide/usage/linter/rules/oxc/no-optional-chaining.md --- url: /docs/guide/usage/linter/rules/oxc/no-optional-chaining.md --- ### What it does Disallow [optional chaining](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Optional_chaining). ### Why is this bad? You may want to use this rule if you need to maintain compatibility with older environments. However, optional chaining has been supported in all major browsers since 2020 and is generally safe to use today. In some cases, transpiling optional chaining can result in verbose helper code that impacts bundle size and performance. This rule is useful when you need to avoid the overhead of transpiled optional chaining. This is only relevant if you are polyfilling to support browsers from pre-2020. In most codebases at this point, you should not use this rule. ### Examples Examples of **incorrect** code for this rule: ```javascript const foo = obj?.foo; obj.fn?.(); ``` ## Configuration This rule accepts a configuration object with the following properties: ### message type: `string` default: `""` A custom help message to display when optional chaining is found. For example, "Our output target is ES2016, and optional chaining results in verbose helpers and should be avoided." ## How to use To **enable** this rule using the config file or in the CLI, you can use: ::: code-group ```json [Config (.oxlintrc.json)] { "rules": { "oxc/no-optional-chaining": "error" } } ``` ```bash [CLI] oxlint --deny oxc/no-optional-chaining ``` ::: ## References * Rule Source --- # Source: https://oxc.rs/docs/guide/usage/linter/rules/eslint/no-param-reassign.md --- url: /docs/guide/usage/linter/rules/eslint/no-param-reassign.md --- ### 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 using the config file or in the CLI, you can use: ::: code-group ```json [Config (.oxlintrc.json)] { "rules": { "no-param-reassign": "error" } } ``` ```bash [CLI] oxlint --deny no-param-reassign ``` ::: ## References * Rule Source --- # Source: https://oxc.rs/docs/guide/usage/linter/rules/eslint/no-plusplus.md --- url: /docs/guide/usage/linter/rules/eslint/no-plusplus.md --- ### What it does Disallow the unary operators `++` and `--`. ### Why is this bad? Because the unary `++` and `--` operators are subject to automatic semicolon insertion, differences in whitespace can change the semantics of source code. For example, these two code blocks are not equivalent: ```js var i = 10; var j = 20; i++; j; // => i = 11, j = 20 ``` ```js var i = 10; var j = 20; i; ++j; // => i = 10, j = 21 ``` ### Examples Examples of **incorrect** code for this rule: ```js var x = 0; x++; var y = 0; y--; for (let i = 0; i < l; i++) { doSomething(i); } ``` Examples of **correct** code for this rule: ```js var x = 0; x += 1; var y = 0; y -= 1; for (let i = 0; i < l; i += 1) { doSomething(i); } ``` ## 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 using the config file or in the CLI, you can use: ::: code-group ```json [Config (.oxlintrc.json)] { "rules": { "no-plusplus": "error" } } ``` ```bash [CLI] oxlint --deny no-plusplus ``` ::: ## References * Rule Source --- # Source: https://oxc.rs/docs/guide/usage/linter/rules/node/no-process-env.md --- url: /docs/guide/usage/linter/rules/node/no-process-env.md --- ### What it does Disallows use of `process.env`. ### Why is this bad? Directly reading `process.env` can lead to implicit runtime configuration, make code harder to test, and bypass configuration validation. ### Examples Examples of **incorrect** code for this rule: ```js if (process.env.NODE_ENV === "development") { // ... } ``` Examples of **correct** code for this rule: ```js import config from "./config"; if (config.env === "development") { //... } ``` ## Configuration This rule accepts a configuration object with the following properties: ### allowedVariables type: `string[]` default: `[]` Variable names which are allowed to be accessed on `process.env`. ## How to use To **enable** this rule using the config file or in the CLI, you can use: ::: code-group ```json [Config (.oxlintrc.json)] { "plugins": ["node"], "rules": { "node/no-process-env": "error" } } ``` ```bash [CLI] oxlint --deny node/no-process-env --node-plugin ``` ::: ## References * Rule Source --- # Source: https://oxc.rs/docs/guide/usage/linter/rules/unicorn/no-process-exit.md ## What it does Disallow `process.exit()`. ## Why is this bad? Only use `process.exit()` in CLI apps. Throw an error instead. ## Examples Examples of **incorrect** code for this rule: ```javascript if (problem) process.exit(1); ``` Examples of **correct** code for this rule: ```javascript if (problem) throw new Error("message"); ``` ```bash #!/usr/bin/env node if (problem) process.exit(1); ``` ## How to use To **enable** this rule using the config file or in the CLI, you can use: ::: code-group ```json [Config (.oxlintrc.json)] { "rules": { "unicorn/no-process-exit": "error" } } ``` ```bash [CLI] oxlint --deny unicorn/no-process-exit ``` ::: ## References * Rule Source --- # Source: https://oxc.rs/docs/guide/usage/linter/rules/eslint/no-promise-executor-return.md --- url: /docs/guide/usage/linter/rules/eslint/no-promise-executor-return.md --- ### What it does Disallow returning values from Promise executor functions. ### 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. The return value of the executor is ignored. Returning a value from an executor function is a possible error because the returned value cannot be used and it doesn't affect the promise in any way. ### Examples Examples of **incorrect** code for this rule: ```javascript new Promise((resolve, reject) => { if (someCondition) { return defaultResult; } getSomething((err, result) => { if (err) { reject(err); } else { resolve(result); } }); }); new Promise((resolve, reject) => getSomething((err, data) => { if (err) { reject(err); } else { resolve(data); } }), ); new Promise(() => { return 1; }); ``` Examples of **correct** code for this rule: ```javascript new Promise((resolve, reject) => { if (someCondition) { resolve(defaultResult); return; } getSomething((err, result) => { if (err) { reject(err); } else { resolve(result); } }); }); new Promise((resolve, reject) => { getSomething((err, data) => { if (err) { reject(err); } else { resolve(data); } }); }); new Promise((r) => { r(1); }); ``` ## Configuration This rule accepts a configuration object with the following properties: ### allowVoid type: `boolean` default: `false` If `true`, allows returning `void` expressions (e.g., `return void resolve()`). ## How to use To **enable** this rule using the config file or in the CLI, you can use: ::: code-group ```json [Config (.oxlintrc.json)] { "rules": { "no-promise-executor-return": "error" } } ``` ```bash [CLI] oxlint --deny no-promise-executor-return ``` ::: ## References * Rule Source --- # Source: https://oxc.rs/docs/guide/usage/linter/rules/promise/no-promise-in-callback.md --- url: /docs/guide/usage/linter/rules/promise/no-promise-in-callback.md --- ### What it does Disallows the use of Promises within error-first callback functions. ### Why is this bad? Mixing Promises and callbacks can lead to unclear and inconsistent code. Promises and callbacks are different patterns for handling asynchronous code. Mixing them makes the logic flow harder to follow and complicates error handling, as callbacks rely on an error-first pattern, while Promises use `catch`. ### Examples Examples of **incorrect** code for this rule: ```js doSomething((err, val) => { if (err) console.error(err); else doSomethingElse(val).then(console.log); }); ``` Examples of **correct** code for this rule: ```js promisify(doSomething)().then(doSomethingElse).then(console.log).catch(console.error); ``` ## How to use To **enable** this rule using the config file or in the CLI, you can use: ::: code-group ```json [Config (.oxlintrc.json)] { "plugins": ["promise"], "rules": { "promise/no-promise-in-callback": "error" } } ``` ```bash [CLI] oxlint --deny promise/no-promise-in-callback --promise-plugin ``` ::: ## References * Rule Source --- # Source: https://oxc.rs/docs/guide/usage/linter/rules/eslint/no-proto.md --- url: /docs/guide/usage/linter/rules/eslint/no-proto.md --- ### What it does Disallow the use of the `__proto__` property. ### Why is this bad? 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. For more information, see [the MDN documentation](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/proto). ### Examples Examples of **incorrect** code for this rule: ```javascript var a = obj.__proto__; var a = obj["__proto__"]; obj.__proto__ = b; obj["__proto__"] = b; ``` ## How to use To **enable** this rule using the config file or in the CLI, you can use: ::: code-group ```json [Config (.oxlintrc.json)] { "rules": { "no-proto": "error" } } ``` ```bash [CLI] oxlint --deny no-proto ``` ::: ## References * Rule Source --- # Source: https://oxc.rs/docs/guide/usage/linter/rules/eslint/no-prototype-builtins.md --- url: /docs/guide/usage/linter/rules/eslint/no-prototype-builtins.md --- ### What it does Disallow calling some Object.prototype methods directly on objects ### Why is this bad? In ECMAScript 5.1, Object.create was added, which enables the creation of objects with a specified \[\[Prototype]]. Object.create(null) is a common pattern used to create objects that will be used as a Map. This can lead to errors when it is assumed that objects will have properties from Object.prototype. This rule prevents calling some Object.prototype methods directly from an object. Additionally, objects can have properties that shadow the builtins on Object.prototype, potentially causing unintended behavior or denial-of-service security vulnerabilities. For example, it would be unsafe for a webserver to parse JSON input from a client and call hasOwnProperty directly on the resulting object, because a malicious client could send a JSON value like {"hasOwnProperty": 1} and cause the server to crash. 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: ```javascript var hasBarProperty = foo.hasOwnProperty("bar"); var isPrototypeOfBar = foo.isPrototypeOf(bar); var barIsEnumerable = foo.propertyIsEnumerable("bar"); ``` ## How to use To **enable** this rule using the config file or in the CLI, you can use: ::: code-group ```json [Config (.oxlintrc.json)] { "rules": { "no-prototype-builtins": "error" } } ``` ```bash [CLI] oxlint --deny no-prototype-builtins ``` ::: ## References * Rule Source --- # Source: https://oxc.rs/docs/guide/usage/linter/rules/eslint/no-redeclare.md --- url: /docs/guide/usage/linter/rules/eslint/no-redeclare.md --- ### 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. ### 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 Examples of **incorrect** code for this rule: ```javascript var a = 3; var a = 10; ``` Examples of **correct** code for this rule: ```javascript var a = 3; a = 10; ``` ## Configuration This rule accepts a configuration object with the following properties: ### builtinGlobals type: `boolean` default: `true` When set `true`, it flags redeclaring built-in globals (e.g., `let Object = 1;`). ## How to use To **enable** this rule using the config file or in the CLI, you can use: ::: code-group ```json [Config (.oxlintrc.json)] { "rules": { "no-redeclare": "error" } } ``` ```bash [CLI] oxlint --deny no-redeclare ``` ::: ## References * Rule Source --- # Source: https://oxc.rs/docs/guide/usage/linter/rules/jsx_a11y/no-redundant-roles.md --- url: /docs/guide/usage/linter/rules/jsx_a11y/no-redundant-roles.md --- ### What it does Enforces that the explicit `role` property is not the same as implicit/default role property on element. ### Why is this bad? Redundant roles can lead to confusion and verbosity in the codebase. ### Examples Examples of **incorrect** code for this rule: ```jsx

{user.name}	{user.role}
Total users: {users.length}

Hello