+
+✅ This rule is turned on by default.
+
🚧 An auto-fix is still under development.
diff --git a/src/docs/guide/usage/linter/rules/typescript/no-for-in-array.md b/src/docs/guide/usage/linter/rules/typescript/no-for-in-array.md
new file mode 100644
index 0000000000..ef91ab3747
--- /dev/null
+++ b/src/docs/guide/usage/linter/rules/typescript/no-for-in-array.md
@@ -0,0 +1,92 @@
+
+
+
+
+# typescript/no-for-in-array
+
+
+
+### What it does
+
+This rule disallows iterating over an array with a for-in loop.
+
+### Why is this bad?
+
+A for-in loop iterates over the enumerable properties of an object, which includes the array indices, but also includes any enumerable properties added to the array prototype or the array instance. This is almost never what you want when iterating over an array.
+
+### Examples
+
+Examples of **incorrect** code for this rule:
+
+```ts
+const arr = [1, 2, 3];
+
+for (const i in arr) {
+ console.log(arr[i]);
+}
+
+for (const i in arr) {
+ console.log(i, arr[i]);
+}
+```
+
+Examples of **correct** code for this rule:
+
+```ts
+const arr = [1, 2, 3];
+
+// Use for-of to iterate over array values
+for (const value of arr) {
+ console.log(value);
+}
+
+// Use regular for loop with index
+for (let i = 0; i < arr.length; i++) {
+ console.log(i, arr[i]);
+}
+
+// Use forEach
+arr.forEach((value, index) => {
+ console.log(index, value);
+});
+
+// for-in is fine for objects
+const obj = { a: 1, b: 2 };
+for (const key in obj) {
+ console.log(key, obj[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 typescript/no-for-in-array
+```
+
+```json [Config (.oxlintrc.json)]
+{
+ "rules": {
+ "typescript/no-for-in-array": "error"
+ }
+}
+```
+
+:::
+
+## References
+
+-
Rule Source
diff --git a/src/docs/guide/usage/linter/rules/typescript/no-implied-eval.md b/src/docs/guide/usage/linter/rules/typescript/no-implied-eval.md
new file mode 100644
index 0000000000..6e4d497796
--- /dev/null
+++ b/src/docs/guide/usage/linter/rules/typescript/no-implied-eval.md
@@ -0,0 +1,85 @@
+
+
+
+
+# typescript/no-implied-eval
+
+
+
+### What it does
+
+This rule disallows the use of eval-like methods.
+
+### Why is this bad?
+
+It's considered a good practice to avoid using eval() in JavaScript. There are security and performance implications involved with doing so, which is why many linters recommend disallowing eval(). However, there are some other ways to pass a string and have it interpreted as JavaScript code that have similar concerns.
+
+### Examples
+
+Examples of **incorrect** code for this rule:
+
+```ts
+setTimeout("alert(\"Hi!\");", 100);
+
+setInterval("alert(\"Hi!\");", 100);
+
+setImmediate("alert(\"Hi!\")");
+
+window.setTimeout("count = 5", 10);
+
+window.setInterval("foo = bar", 10);
+
+const fn = new Function("a", "b", "return a + b");
+```
+
+Examples of **correct** code for this rule:
+
+```ts
+setTimeout(() => {
+ alert("Hi!");
+}, 100);
+
+setInterval(() => {
+ alert("Hi!");
+}, 100);
+
+setImmediate(() => {
+ alert("Hi!");
+});
+
+const fn = (a: number, b: number) => 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 typescript/no-implied-eval
+```
+
+```json [Config (.oxlintrc.json)]
+{
+ "rules": {
+ "typescript/no-implied-eval": "error"
+ }
+}
+```
+
+:::
+
+## References
+
+-
Rule Source
diff --git a/src/docs/guide/usage/linter/rules/typescript/no-meaningless-void-operator.md b/src/docs/guide/usage/linter/rules/typescript/no-meaningless-void-operator.md
new file mode 100644
index 0000000000..4937be305a
--- /dev/null
+++ b/src/docs/guide/usage/linter/rules/typescript/no-meaningless-void-operator.md
@@ -0,0 +1,85 @@
+
+
+
+
+# typescript/no-meaningless-void-operator
+
+
+
+### What it does
+
+This rule disallows the void operator when its argument is already of type void or undefined.
+
+### Why is this bad?
+
+The void operator is useful when you want to execute an expression and force it to evaluate to undefined. However, using void on expressions that are already of type void or undefined is meaningless and adds unnecessary complexity to the code.
+
+### Examples
+
+Examples of **incorrect** code for this rule:
+
+```ts
+function foo(): void {
+ return;
+}
+
+void foo(); // meaningless, foo() already returns void
+
+void undefined; // meaningless, undefined is already undefined
+
+async function bar() {
+ void (await somePromise); // meaningless if somePromise resolves to void
+}
+```
+
+Examples of **correct** code for this rule:
+
+```ts
+function getValue(): number {
+ return 42;
+}
+
+void getValue(); // meaningful, converts number to void
+
+void console.log("hello"); // meaningful, console.log returns undefined but we want to be explicit
+
+function processData() {
+ // some processing
+}
+
+processData(); // no void needed since we don't care about return 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 typescript/no-meaningless-void-operator
+```
+
+```json [Config (.oxlintrc.json)]
+{
+ "rules": {
+ "typescript/no-meaningless-void-operator": "error"
+ }
+}
+```
+
+:::
+
+## References
+
+-
Rule Source
diff --git a/src/docs/guide/usage/linter/rules/typescript/no-misused-promises.md b/src/docs/guide/usage/linter/rules/typescript/no-misused-promises.md
index f3f87cf4b5..3499dbbcb9 100644
--- a/src/docs/guide/usage/linter/rules/typescript/no-misused-promises.md
+++ b/src/docs/guide/usage/linter/rules/typescript/no-misused-promises.md
@@ -5,7 +5,7 @@ import { data } from '../version.data.js';
const source = `https://github.com/oxc-project/oxc/blob/${ data }/crates/oxc_linter/src/rules/typescript/no_misused_promises.rs`;
-# typescript/no-misused-promises
+# typescript/no-misused-promises