遷移至 v9.x

ESLint v9.0.0 是 ESLint 的主要版本，因此，有一些您需要注意的重大變更。本指南旨在引導您了解這些重大變更。

以下清單大致按照預期每個變更會影響的使用者數量排序，其中第一個項目預期會影響最多使用者。

不再支援 Node.js < v18.18、v19
新的預設設定格式 (eslint.config.js)
移除多個格式器
移除 require-jsdoc 和 valid-jsdoc 規則
eslint:recommended 已更新
--quiet 不再執行設定為 "warn" 的規則
--output-file 現在即使輸出為空也會將檔案寫入磁碟
當沒有模式傳遞給 CLI 時的行為變更
僅具有嚴重性的 /* eslint */ 註解現在會保留設定檔中的選項
現在不允許對同一規則使用多個 /* eslint */ 註解
更嚴格的 /* exported */ 解析
no-constructor-return 和 no-sequences 規則綱要更嚴格
預設情況下，no-implicit-coercion 中有新的檢查
no-invalid-regexp 中的區分大小寫的旗標
no-unused-vars 的 varsIgnorePattern 選項不再適用於 catch 引數
no-restricted-imports 現在接受具有相同 name 的多個設定項目
扁平設定中不再接受 "eslint:recommended" 和 "eslint:all" 字串
no-inner-declarations 具有新的預設行為和新的選項
no-unused-vars 現在預設將 caughtErrors 設定為 "all"
no-useless-computed-key 預設會在類別中標記不必要的計算成員名稱
camelcase allow 選項僅接受字串陣列

對整合開發人員來說的重大變更

不再支援 Node.js < v18.18、v19
FlatESLint 現在是 ESLint
Linter 現在預期扁平設定格式

不再支援 Node.js < v18.18、v19

從 ESLint v9.0.0 開始，ESLint 正式放棄對這些版本的 Node.js 的支援。ESLint 現在支援以下版本的 Node.js

Node.js v18.18.0 及以上
Node.js v20.9.0 及以上
Node.js v21 及以上

處理方式： 確保在使用 ESLint v9.0.0 時升級至至少 Node.js v18.18.0。一個需要仔細檢查的重要事項是，當透過編輯器整合使用 ESLint 時，您的編輯器所支援的 Node.js 版本。如果您無法升級，我們建議您繼續使用 ESLint v8.56.0，直到您可以升級 Node.js 為止。

相關問題： #17595

新的預設設定格式 (`eslint.config.js`)

正如我們在部落格文章中宣布的那樣，在 ESLint v9.0.0 中，eslint.config.js 是新的預設設定格式。先前的格式 eslintrc 現在已棄用，且不會自動搜尋。

處理方式： 依照設定遷移指南將您的設定更新為新格式。如果您仍然需要使用已棄用的 eslintrc 設定格式，請將環境變數 ESLINT_USE_FLAT_CONFIG 設定為 false。

相關問題： #13481

移除多個格式器

ESLint v9.0.0 已從核心移除以下格式器

移除的格式器	替換 npm 套件
`checkstyle`	`eslint-formatter-checkstyle`
`compact`	`eslint-formatter-compact`
`jslint-xml`	`eslint-formatter-jslint-xml`
`junit`	`eslint-formatter-junit`
`tap`	`eslint-formatter-tap`
`unix`	`eslint-formatter-unix`
`visualstudio`	`eslint-formatter-visualstudio`

處理方式： 如果您透過 -f 命令列旗標使用這些格式器中的任何一個，您需要為該格式器安裝對應的套件。

相關問題： #17524

移除 `require-jsdoc` 和 `valid-jsdoc` 規則

require-jsdoc 和 valid-jsdoc 規則已在 ESLint v9.0.0 中移除。這些規則最初在 2018 年已棄用。

處理方式： 使用 eslint-plugin-jsdoc 中的替換規則。

相關問題： #15820

`eslint:recommended` 已更新

在 eslint:recommended 中已啟用四個新規則

此外，已從 eslint:recommended 中移除以下規則

處理方式： 修正錯誤或停用這些規則。

相關問題： #15576、#17446、#17596

`--quiet` 不再執行設定為 `"warn"` 的規則

在 ESLint v9.0.0 之前，--quiet CLI 旗標會執行所有設定為 "error" 或 "warn" 的規則，然後隱藏設定為 "warn" 的規則的結果。在 ESLint v9.0.0 中，--quiet 將會防止執行設定為 "warn" 的規則。這可以改善包含許多設定為 "warn" 的規則的設定的效能。

如果使用 --max-warnings，則 --quiet 不會抑制執行設定為 "warn" 的規則，但會抑制這些規則的輸出。

處理方式： 在大多數情況下，此變更是透明的。但是，如果您正在執行設定為 "warn" 的規則，該規則會變更其他規則可用的資料（例如，如果該規則使用 sourceCode.markVariableAsUsed()），則這可能會導致行為變更。在這種情況下，您需要將規則設定為 "error" 或停止使用 --quiet。

相關問題： #16450

`--output-file` 現在即使輸出為空也會將檔案寫入磁碟

在 ESLint v9.0.0 之前，如果輸出為空，則 --output-file 旗標會跳過將檔案寫入磁碟。但是，在 ESLint v9.0.0 中，--output-file 現在會一致地將檔案寫入磁碟，即使輸出為空。此更新可確保 --output-file 更一致且可靠的行為。

處理方式： 檢閱您對 --output-file 旗標的使用，尤其是在您的程序依賴於檔案的存在或不存在（基於輸出內容）的情況下。如有必要，請更新您的腳本或設定以適應此變更。

相關問題： #17660

當沒有模式傳遞給 CLI 時的行為變更

在 ESLint v9.0.0 之前，在沒有任何檔案或目錄模式的情況下執行 ESLint CLI 會導致沒有檔案被 linting，並會以程式碼 0 退出。這令人困惑，因為不清楚實際上沒有任何事情發生。在 ESLint v9.0.0 中，此行為已更新

扁平配置（Flat config）。 如果您使用的是扁平配置，您可以執行 npx eslint 或 eslint（如果已全域安裝），ESLint 會假設您想要檢查目前目錄。實際上，不傳遞任何模式等同於傳遞 .。
eslintrc。 如果您使用的是已棄用的 eslintrc 配置，當您在沒有任何模式的情況下執行 CLI 時，現在會收到錯誤。

解決方法： 在大多數情況下，不需要任何變更，您可能會發現某些位置您以為 ESLint 正在執行，但實際上並沒有。如果您想保留 v8.x 的行為，即不傳遞任何模式會導致 ESLint 以代碼 0 退出，請將 --pass-on-no-patterns 標誌添加到 CLI 呼叫中。

相關問題： #14308

僅包含嚴重性的 `/* eslint */` 註解現在會保留配置檔案中的選項

在 ESLint v9.0.0 之前，諸如 /* eslint curly: "warn" */ 或 /* eslint curly: ["warn"] */ 之類的配置註解會完全覆蓋配置檔案中為規則指定的任何配置，因此會強制執行該規則的預設選項。

在 ESLint v9.0.0 中，配置註解的行為與配置檔案中規則配置的合併方式一致，這表示僅包含嚴重性的配置註解現在會保留配置檔案中指定的選項，而只會覆蓋嚴重性。

例如，如果您有以下配置檔案

// eslint.config.js

export default [{
    rules: {
        curly: ["error", "multi"]
    }
}];
1
2
3
4
5
6
7

以及以下配置註解

// my-file.js

/* eslint curly: "warn" */
1
2
3

當檢查 my-file.js 時，curly 規則的最終配置將為 curly: ["warn", "multi"]。

請注意，此變更僅影響在配置檔案中使用選項配置同一個規則，且同時使用不帶選項的配置註解的情況。在所有其他情況下（例如，該規則僅使用配置註解配置），行為與 ESLint v9.0.0 之前保持不變。

解決方法： 我們預期在大多數情況下不需要任何變更，因為使用配置註解配置的規則通常不會在配置檔案中配置。但是，如果您需要配置註解完全覆蓋配置檔案中的配置並強制執行預設選項，您需要至少指定一個選項

// my-file.js

/* eslint curly: ["warn", "all"] */
1
2
3

相關問題： #17381

現在不允許同一個規則有多個 `/* eslint */` 註解

在 ESLint v9.0.0 之前，如果正在檢查的檔案包含同一個規則的多個 /* eslint */ 配置註解，則會套用最後一個，而其他註解將會被靜默忽略。例如

/* eslint semi: ["error", "always"] */
/* eslint semi: ["error", "never"] */

foo() // valid, because the configuration is "never"
1
2
3
4

在 ESLint v9.0.0 中，會套用第一個註解，而其他註解則會回報為檢查錯誤

/* eslint semi: ["error", "always"] */
/* eslint semi: ["error", "never"] */ // error: Rule "semi" is already configured by another configuration comment in the preceding code. This configuration is ignored.

foo() // error: Missing semicolon
1
2
3
4

解決方法： 移除重複的 /* eslint */ 註解。

相關問題： #18132

更嚴格的 `/* exported */` 解析

在 ESLint v9.0.0 之前，/* exported */ 指令錯誤地允許以下語法

/* exported foo: true, bar: false */

// and

/* exported foo bar */
1
2
3
4
5

在此範例中的 true 和 false 對 ESLint 的行為沒有任何影響，實際上，這是一個解析錯誤。

在 ESLint v9.0.0 中，任何後接冒號和值的 /* exported */ 變數都會被視為無效而被忽略。

解決方法： 更新任何 /* exported */ 指令，以刪除冒號和後續的值，並確保變數名稱之間有逗號，例如

/* exported foo, bar */
1

相關問題： #17622

`no-constructor-return` 和 `no-sequences` 規則的架構更嚴格

在之前的 ESLint 版本中，no-constructor-return 和 no-sequences 規則錯誤地接受了無效的選項。

這已在 ESLint v9.0.0 中修正

no-constructor-return 規則不接受任何選項。
no-sequences 規則可以採用一個選項，該選項是一個具有 "allowInParentheses" 屬性（布林值）的物件。

{
    "rules": {
        "no-constructor-return": ["error"],
        "no-sequences": ["error", { "allowInParentheses": false }]
    }
}
1
2
3
4
5
6

解決方法： 如果 ESLint 回報任何這些規則的無效配置，請更新您的配置。

相關問題： #16879

`no-implicit-coercion` 預設情況下新增檢查

在 ESLint v9.0.0 中，no-implicit-coercion 規則預設還會回報以下情況

-(-foo);
foo - 0;
1
2

解決方法： 如果您想保留此規則的先前行為，請設定 "allow": ["-", "- -"]。

{
    "rules": {
        "no-implicit-coercion": [2, { "allow": ["-", "- -"] } ],
    }
}
1
2
3
4
5

相關問題： #17832

`no-invalid-regexp` 中的區分大小寫的標誌

在 ESLint v9.0.0 中，選項 allowConstructorFlags 現在區分大小寫。

解決方法： 如果需要，請更新您的配置。

相關問題： #16574

`no-unused-vars` 的 `varsIgnorePattern` 選項不再適用於 catch 引數

在之前的 ESLint 版本中，no-unused-vars 的 varsIgnorePattern 選項錯誤地忽略了 catch 子句中指定的錯誤。在 ESLint v9.0.0 中，varsIgnorePattern 不再適用於 catch 子句中的錯誤。例如

/*eslint no-unused-vars: ["error", { "caughtErrors": "all", "varsIgnorePattern": "^err" }]*/

try {
    //...
} catch (err) { // 'err' will be reported.
    console.error("errors");
}

1
2
3
4
5
6
7
8

解決方法： 如果您想為 catch 子句變數名稱指定忽略模式，請使用 caughtErrorsIgnorePattern 選項以及 varsIgnorePattern。

相關問題： #17540

`no-restricted-imports` 現在接受具有相同 `name` 的多個配置項目

在之前的 ESLint 版本中，如果 no-restricted-imports 規則配置中的 paths 陣列有多個具有相同 name 屬性的項目，則只會套用最後一個項目，而之前的項目會被忽略。

從 ESLint v9.0.0 開始，所有項目都會套用，允許為不同的匯入名稱指定不同的訊息。例如，您現在可以像這樣配置規則

{
    rules: {
        "no-restricted-imports": ["error", {
            paths: [
                {
                    name: "react-native",
                    importNames: ["Text"],
                    message: "import 'Text' from 'ui/_components' instead"
                },
                {
                    name: "react-native",
                    importNames: ["View"],
                    message: "import 'View' from 'ui/_components' instead"
                }
            ]
        }]
    }
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

import { Text } from "react-native" 和 import { View } from "react-native" 都會被回報，並帶有不同的訊息。

在之前的 ESLint 版本中，使用此配置只會回報 import { View } from "react-native"。

解決方法： 如果您此規則的配置有多個具有相同 name 的項目，您可能需要移除非預期的項目。

相關問題： #15261

扁平配置不再接受 `"eslint:recommended"` 和 `"eslint:all"`

在 ESLint v8.x 中，eslint.config.js 可以透過將字串插入配置陣列來參照 "eslint:recommended" 和 "eslint:all" 配置，如此範例所示

// eslint.config.js
export default [
    "eslint:recommended",
    "eslint:all"
];
1
2
3
4
5

在 ESLint v9.0.0 中，不再支援此格式，並且會導致錯誤。

解決方法： 請改用 @eslint/js 套件

// eslint.config.js
import js from "@eslint/js";

export default [
    js.configs.recommended,
    js.configs.all
];
1
2
3
4
5
6
7

相關問題： #17488

`no-inner-declarations` 具有新的預設行為和一個新選項

ESLint v9.0.0 在 no-inner-declarations 規則中引入一個名為 blockScopeFunctions 的新選項，預設情況下，當 languageOptions.ecmaVersion 設定為 2015 或更高版本時，允許嚴格模式中的區塊層級 function。

/*eslint no-inner-declarations: "error"*/
"use strict";

if (test) {
    function foo () { }  // no error
}
1
2
3
4
5
6

解決方法： 如果您想在任何情況下回報區塊層級 function，無論是否為嚴格模式，請將 blockScopeFunctions 選項設定為 "disallow"。

相關問題： #15576

`no-unused-vars` 現在預設將 `caughtErrors` 設定為 `"all"`

ESLint v9.0.0 變更了 no-unused-vars 規則的 caughtErrors 選項的預設值。之前它預設為 "none"，從不檢查是否使用了 catch 到的錯誤。現在它預設為 "all"，以檢查 catch 到的錯誤是否被使用。

/*eslint no-unused-vars: "error"*/
try {}
catch (error) {
    // 'error' is defined but never used
}
1
2
3
4
5

解決方法： 如果您想允許未使用的 catch 到的錯誤，例如在編寫將直接在不支援 ES2019 可選 catch 綁定的環境中執行的程式碼時，請將 caughtErrors 選項設定為 "none"。否則，請刪除未使用的 catch 到的錯誤。

/*eslint no-unused-vars: "error"*/
try {}
catch {
    // no error
}
1
2
3
4
5

相關問題： #17974

`no-useless-computed-key` 預設會標記類別中不必要的計算成員名稱

在 ESLint v9.0.0 中，no-useless-computed-key 規則的 enforceForClassMembers 選項的預設值已從 false 變更為 true。此變更的效果是，類別中不必要的計算成員名稱預設會被標記。

/*eslint no-useless-computed-key: "error"*/

class SomeClass {
    ["someMethod"]() {} // ok in ESLint v8, error in ESLint v9.
}
1
2
3
4
5

解決方法： 修正規則回報的問題，或將 enforceForClassMembers 選項設定為 false 以恢復先前的行為。

相關問題： #18042

`camelcase` allow 選項只接受字串陣列

之前，camelcase 規則沒有強制執行 allow 選項必須是字串陣列。在 ESLint v9.0.0 中，allow 選項現在只接受字串陣列。

解決方法： 如果 ESLint 回報此規則的無效配置，請更新您的配置。

相關問題： #18232

移除多個 `context` 方法

ESLint v9.0.0 從 context 物件中移除多個已棄用的方法，並將它們移至 SourceCode 物件

在 `context` 上移除	`SourceCode` 上的替代方法
`context.getSource()`	`sourceCode.getText()`
`context.getSourceLines()`	`sourceCode.getLines()`
`context.getAllComments()`	`sourceCode.getAllComments()`
`context.getNodeByRangeIndex()`	`sourceCode.getNodeByRangeIndex()`
`context.getComments()`	`sourceCode.getCommentsBefore()`, `sourceCode.getCommentsAfter()`, `sourceCode.getCommentsInside()`
`context.getCommentsBefore()`	`sourceCode.getCommentsBefore()`
`context.getCommentsAfter()`	`sourceCode.getCommentsAfter()`
`context.getCommentsInside()`	`sourceCode.getCommentsInside()`
`context.getJSDocComment()`	`sourceCode.getJSDocComment()`
`context.getFirstToken()`	`sourceCode.getFirstToken()`
`context.getFirstTokens()`	`sourceCode.getFirstTokens()`
`context.getLastToken()`	`sourceCode.getLastToken()`
`context.getLastTokens()`	`sourceCode.getLastTokens()`
`context.getTokenAfter()`	`sourceCode.getTokenAfter()`
`context.getTokenBefore()`	`sourceCode.getTokenBefore()`
`context.getTokenByRangeStart()`	`sourceCode.getTokenByRangeStart()`
`context.getTokens()`	`sourceCode.getTokens()`
`context.getTokensAfter()`	`sourceCode.getTokensAfter()`
`context.getTokensBefore()`	`sourceCode.getTokensBefore()`
`context.getTokensBetween()`	`sourceCode.getTokensBetween()`
`context.parserServices`	`sourceCode.parserServices`
`context.getDeclaredVariables()`	`sourceCode.getDeclaredVariables()`

除了上表中的方法外，還有一些其他方法也被移動了，但需要不同的方法簽名。

在 `context` 上移除	`SourceCode` 上的替代方法
`context.getAncestors()`	`sourceCode.getAncestors(node)`
`context.getScope()`	`sourceCode.getScope(node)`
`context.markVariableAsUsed(name)`	`sourceCode.markVariableAsUsed(name, node)`

解決方法： 請使用部落格文章中建議的自動升級工具。

相關問題： #16999, #13481

移除 `sourceCode.getComments()`

ESLint v9.0.0 移除了已棄用的 sourceCode.getComments() 方法。

解決方法： 請替換為 sourceCode.getCommentsBefore()、sourceCode.getCommentsAfter() 或 sourceCode.getCommentsInside()。

相關問題： #14744

移除 `CodePath#currentSegments`

ESLint v9.0.0 移除了已棄用的 CodePath#currentSegments 屬性。

解決方法： 請按照部落格文章中的建議更新您的程式碼。

相關問題： #17457

程式碼路徑現在預先計算

在 ESLint v9.0.0 之前，程式碼路徑是在規則使用的相同 AST 遍歷期間計算的，這表示傳遞給 onCodePathStart 和 onCodePathSegmentStart 等方法的資訊是不完整的。具體來說，像 CodePath#childCodePaths 和 CodePathSegment#nextSegments 這樣的陣列屬性最初是空的，然後隨著遍歷完成而填入適當的資訊，這表示這些陣列可能會因為您檢查其值的時間點不同而有不同的元素。

ESLint v9.0.0 現在會在規則使用的遍歷之前預先計算程式碼路徑資訊。因此，無論在規則中的何處存取，程式碼路徑資訊現在都是完整的。

解決方法： 如果您正在存取 CodePath 或 CodePathSegment 上的任何陣列屬性，您需要更新您的程式碼。具體來說

如果您正在檢查任何陣列屬性的 length，請確保您使用的是相對比較運算子，例如 <、>、<= 和 >=，而不是等於。
如果您正在存取 CodePathSegment 上的 nextSegments、prevSegments、allNextSegments 或 allPrevSegments 屬性，或者 CodePath#childCodePaths，請驗證您的程式碼是否仍然可以如預期般運作。為了向後相容，請考慮將檢查這些屬性的邏輯移動到 onCodePathEnd 中。

相關問題： #16999

不再支援函式式規則

ESLint v9.0.0 不再支援函式式規則。函式式規則是指透過匯出函式而非具有 create() 方法的物件所建立的規則。此規則格式已於 2016 年棄用。

解決方法： 請將您的規則更新為最新的規則格式。對於使用 CommonJS 編寫的規則，您也可以使用eslint-transforms。

eslint-plugin/prefer-object-rule 規則可以幫助強制使用物件式規則，並自動修復任何剩餘的函式式規則。

相關問題： #14709

具有選項的規則必須有 `meta.schema`

從 ESLint v9.0.0 開始，如果任何傳遞給未指定 meta.schema 屬性的規則選項，將會拋出錯誤。

解決方法

如果您的規則預期有選項，請將 meta.schema 屬性設定為規則選項的 JSON Schema 格式描述。此 schema 將由 ESLint 用於驗證已配置的選項，並防止規則的無效或意外輸入。
如果您的規則不預期有任何選項，則無需採取任何動作。此變更可確保最終使用者不會錯誤地為不預期選項的規則配置選項。
（不建議）您也可以將 meta.schema 設定為 false 以停用此驗證，但如果規則預期有選項，則強烈建議提供 schema，如果規則不預期選項，則省略 schema（或設定 []），以便 ESLint 可以確保您使用者的配置有效。

eslint-plugin/require-meta-schema 規則可以幫助強制要求規則在需要時具有 schema。

相關問題： #14709

`FlatRuleTester` 現在是 `RuleTester`

正如我們在部落格文章中宣布的那樣，臨時的 FlatRuleTester 類別已重新命名為 RuleTester，而 v8.x 中的 RuleTester 類別已被移除。此外，已移除從 eslint/use-at-your-own-risk 匯出的 FlatRuleTester。

解決方法： 請更新您的規則測試以使用新的 RuleTester。為此，以下是一些您需要進行的常見變更

請注意 ecmaVersion 和 sourceType 的新預設值。 預設情況下，RuleTester 使用扁平配置的預設值 ecmaVersion: "latest" 和 sourceType: "module"。如果某些測試預期舊的預設值 ecmaVersion: 5 和 sourceType: "script"，則可能會導致某些測試中斷。如果您想使用舊的預設值，您需要在 RuleTester 中手動指定，如下所示
```
// use eslintrc defaults
const ruleTester = new RuleTester({
    languageOptions: {
        ecmaVersion: 5,
        sourceType: "script"
    }
});
1
2
3
4
5
6
7
```

將 parserOptions 變更為 languageOptions。 如果您正在測試中設定 ecmaVersion 或 sourceType，請將它們從 parserOptions 移動到 languageOptions，如下所示

ruleTester.run("my-rule", myRule, {
    valid: [
        {
            code: "foo",
            parserOptions: {
                ecmaVersion: 6
            }
        }
    ]
});

// becomes

ruleTester.run("my-rule", myRule, {
    valid: [
        {
            code: "foo",
            languageOptions: {
                ecmaVersion: 6
            }
        }
    ]
});
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

翻譯其他配置鍵。 過去在 eslintrc 配置系統上執行的鍵（例如 env 和 parser）必須翻譯成扁平配置系統。請參閱配置移轉指南，以了解有關翻譯您可能使用的其他鍵的詳細資訊。

相關問題： #13481

更嚴格的 `RuleTester` 檢查

為了協助開發高品質且沒有常見錯誤的自訂規則，ESLint v9.0.0 對 RuleTester 實作了一些變更

測試案例的 output 必須與 code 不同。 在 ESLint v8.x 中，如果 output 與 code 相同，則會斷言沒有自動修復。查看測試案例時，並非總是能立即清楚 output 是否與 code 不同，特別是當字串較長或為多行時，這使得開發人員難以判斷測試案例是否預期有自動修復。在 ESLint v9.0.0 中，為了避免這種模糊性，如果測試的 output 與測試的 code 具有相同的值，RuleTester 現在會拋出錯誤。因此，指定 output 現在必然表示測試案例預期有自動修復並斷言其結果。如果測試案例不預期自動修復，請省略 output 屬性或將其設定為 null。這會斷言沒有自動修復。
測試錯誤物件必須指定 message 或 messageId。 為了提高測試涵蓋範圍的品質，如果測試錯誤物件上未指定 message 或 messageId，RuleTester 現在會拋出錯誤。
如果實際錯誤提供建議，則測試錯誤物件必須指定 suggestions。 在 ESLint v8.x 中，如果測試錯誤物件中省略了 suggestions 屬性，RuleTester 不會執行任何與建議相關的檢查，因此很容易忘記斷言測試案例是否產生建議。在 ESLint v9.0.0 中，省略 suggestions 屬性會斷言實際錯誤不提供建議，而如果實際錯誤確實提供建議，則您需要指定 suggestions 屬性。我們強烈建議您透過指定測試建議物件的陣列來詳細測試建議，但您也可以指定 suggestions: <number> 來僅斷言建議的數量。
測試建議物件必須指定 output。 為了提高測試涵蓋範圍的品質，如果測試建議物件上未指定 output 屬性，RuleTester 現在會拋出錯誤。
測試建議物件必須指定 desc 或 messageId。 為了提高測試涵蓋範圍的品質，如果測試建議物件上未指定 desc 或 messageId 屬性，RuleTester 現在會拋出錯誤。同時指定兩者也是不允許的。如果您想除了 messageId 之外還斷言建議說明文字，則還請新增 data 屬性。
建議訊息必須是唯一的。 由於建議通常在編輯器中顯示為下拉式清單，因此對於同一個 lint 問題，沒有兩個建議具有相同的訊息是很重要的。否則，就不可能知道任何給定建議會做什麼。此額外檢查會自動執行。
建議必須變更程式碼。 建議預期會透過變更程式碼來修正回報的問題。如果建議測試的 output 與測試的 code 相同，RuleTester 現在會拋出錯誤。
建議必須產生有效的語法。 為了使規則建議有用，它們需要是有效的語法。RuleTester 現在使用與 code 值相同的語言選項來解析建議的輸出，如果解析失敗，則會拋出錯誤。
測試案例必須是唯一的。 相同的測試案例可能會導致混淆，並且在較長的測試檔案中很難手動偵測到。現在會自動偵測到重複的項目，並且可以安全地移除它們。
filename 和 only 必須為預期的類型。 RuleTester 現在會檢查測試物件的 filename 和 only 屬性的類型。如果指定，filename 必須為字串值。如果指定，only 必須為布林值。
訊息不能有未替換的佔位符。 RuleTester 現在也會檢查訊息中是否仍有 {{ placeholder }}，因為它們的值未透過各自的 context.report() 呼叫中的 data 傳遞。

解決方法： 請使用 RuleTester 執行您的規則測試，並修正發生的任何錯誤。您需要進行的變更以滿足 RuleTester 的要求與 ESLint v8.x 相容。

相關問題： #15104, #15735, #16908, #18016

`FlatESLint` 現在是 `ESLint`

正如我們在部落格文章中宣布的那樣，臨時的 FlatESLint 類別已重新命名為 ESLint，而 v8.x 中的 ESLint 類別已重新命名為 LegacyESLint。

解決方法： 如果您目前正在使用 ESLint 類別，請驗證您的測試是否使用新的 ESLint 類別通過。並非所有舊選項都受支援，因此您可能需要更新傳遞給建構函式的引數。有關詳細資訊，請參閱Node.js API 參考。

如果您仍然需要 v8.x 的 ESLint 功能，請使用 LegacyESLint 類別，如下所示

const { LegacyESLint } = require("eslint/use-at-your-own-risk");
1

相關問題： #13481

`Linter` 現在預期扁平配置格式

在 ESLint v9.0.0 中，傳遞給 Linter#verify() 和 Linter#verifyAndFix() 方法的 config 引數應該採用扁平配置格式。

此外，方法 Linter#defineRule()、Linter#defineRules()、Linter#defineParser() 和 Linter#getRules() 不再可用。

請注意： 如果您正在使用 Linter 類別，請驗證您的測試是否通過。

如果您傳遞的組態物件與扁平組態格式不相容，則需要更新程式碼。

// eslintrc config format
linter.verify(code, {
    parserOptions: {
        ecmaVersion: 6
    }
});

// flat config format
linter.verify(code, {
    languageOptions: {
        ecmaVersion: 6
    }
});
1
2
3
4
5
6
7
8
9
10
11
12
13

請參閱組態遷移指南，以了解有關轉換您可能正在使用的其他鍵的詳細資訊。

規則和解析器可以直接在組態中定義。

// eslintrc mode
linter.defineRule("my-rule1", myRule1);
linter.defineRules({
    "my-rule2": myRule2,
    "my-rule3": myRule3
});
linter.defineParser("my-parser", myParser);
linter.verify(code, {
    rules: {
        "my-rule1": "error",
        "my-rule2": "error",
        "my-rule3": "error"
    },
    parser: "my-parser"
});

// flat config mode
linter.verify(code, {
    plugins: {
        "my-plugin-foo": {
            rules: {
                "my-rule1": myRule1
            }
        },
        "my-plugin-bar": {
            rules: {
                "my-rule2": myRule2,
                "my-rule3": myRule3
            }
        }
    },
    rules: {
        "my-plugin-foo/my-rule1": "error",
        "my-plugin-bar/my-rule2": "error",
        "my-plugin-bar/my-rule3": "error"
    },
    languageOptions: {
        parser: myParser
    }
});
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40

如果您仍然需要 v8.x 的 Linter 功能，請將 configType: "eslintrc" 傳遞給建構子，如下所示：

const linter = new Linter({ configType: "eslintrc" });

linter.verify(code, {
    parserOptions: {
        ecmaVersion: 6
    }
});

linter.getRules();
1
2
3
4
5
6
7
8
9

相關問題： #13481

編輯此頁面

遷移至 v9.x

目錄

對使用者來說的重大變更

對外掛程式開發人員來說的重大變更

對整合開發人員來說的重大變更

不再支援 Node.js < v18.18、v19

新的預設設定格式 (eslint.config.js)

移除多個格式器

移除 require-jsdoc 和 valid-jsdoc 規則

eslint:recommended 已更新

--quiet 不再執行設定為 "warn" 的規則

--output-file 現在即使輸出為空也會將檔案寫入磁碟

當沒有模式傳遞給 CLI 時的行為變更

僅包含嚴重性的 /* eslint */ 註解現在會保留配置檔案中的選項

現在不允許同一個規則有多個 /* eslint */ 註解

更嚴格的 /* exported */ 解析

no-constructor-return 和 no-sequences 規則的架構更嚴格

no-implicit-coercion 預設情況下新增檢查

no-invalid-regexp 中的區分大小寫的標誌

no-unused-vars 的 varsIgnorePattern 選項不再適用於 catch 引數

no-restricted-imports 現在接受具有相同 name 的多個配置項目

扁平配置不再接受 "eslint:recommended" 和 "eslint:all"

no-inner-declarations 具有新的預設行為和一個新選項

no-unused-vars 現在預設將 caughtErrors 設定為 "all"

no-useless-computed-key 預設會標記類別中不必要的計算成員名稱

camelcase allow 選項只接受字串陣列

移除多個 context 方法

移除 sourceCode.getComments()

移除 CodePath#currentSegments

程式碼路徑現在預先計算

不再支援函式式規則

具有選項的規則必須有 meta.schema

FlatRuleTester 現在是 RuleTester

更嚴格的 RuleTester 檢查

FlatESLint 現在是 ESLint

Linter 現在預期扁平配置格式

新的預設設定格式 (`eslint.config.js`)

移除 `require-jsdoc` 和 `valid-jsdoc` 規則

`eslint:recommended` 已更新

`--quiet` 不再執行設定為 `"warn"` 的規則

`--output-file` 現在即使輸出為空也會將檔案寫入磁碟

僅包含嚴重性的 `/* eslint */` 註解現在會保留配置檔案中的選項

現在不允許同一個規則有多個 `/* eslint */` 註解

更嚴格的 `/* exported */` 解析

`no-constructor-return` 和 `no-sequences` 規則的架構更嚴格

`no-implicit-coercion` 預設情況下新增檢查

`no-invalid-regexp` 中的區分大小寫的標誌

`no-unused-vars` 的 `varsIgnorePattern` 選項不再適用於 catch 引數

`no-restricted-imports` 現在接受具有相同 `name` 的多個配置項目

扁平配置不再接受 `"eslint:recommended"` 和 `"eslint:all"`

`no-inner-declarations` 具有新的預設行為和一個新選項

`no-unused-vars` 現在預設將 `caughtErrors` 設定為 `"all"`

`no-useless-computed-key` 預設會標記類別中不必要的計算成員名稱

`camelcase` allow 選項只接受字串陣列

移除多個 `context` 方法

移除 `sourceCode.getComments()`

移除 `CodePath#currentSegments`

具有選項的規則必須有 `meta.schema`

`FlatRuleTester` 現在是 `RuleTester`

更嚴格的 `RuleTester` 檢查

`FlatESLint` 現在是 `ESLint`

`Linter` 現在預期扁平配置格式