
深入解析 ESLintspace-before-keywords規則關鍵字前置空格的強制規范與keyword-spacing演進之路【免費下載鏈接】eslintFind and fix problems in your JavaScript code.項目地址: https://gitcode.com/GitHub_Trending/es/eslint關鍵字keyword是 JavaScript 語法結構中的保留標識符例如function、if、return等。它們在語言中具有特殊含義其前后空格的使用方式往往是團隊代碼風格規范的重要一環。本文基于 ESLint 倉庫中的space-before-keywords規則文檔完整還原該規則的設計理念、參數選項與正反示例并結合倉庫源碼剖析其接替者keyword-spacing的底層實現原理。讀完本文你將掌握關鍵字前置空格的兩種風格always/never如何配置理解該規則為何在 ESLint v2.0.0 被移除、如何平滑遷移到keyword-spacing以及新規則在源碼層面如何完成檢查與自動修復。規則背景為什么需要規范關鍵字前的空格關鍵字是 JavaScript 語法元素的組成部分如function和if。這些標識符對語言具有特殊含義因此代碼編輯器中通常會以不同的顏色顯示它們。作為語言的重要組成部分各類風格指南常常對關鍵字周圍的空格做出約定。例如你可能有一個風格指南要求關鍵字必須始終被空格前置那么if-else語句必須寫成這樣if (foo) { // ... } else { // ... }當然也可能存在相反的風格指南——禁止在關鍵字前出現空格。space-before-keywords規則正是為了在團隊中統一關鍵字前是否留空格這一細節而設計的。該規則屬于布局類layout規則并且支持自動修復原文檔明確指出通過命令行的--fix選項可以自動修復該規則報告的問題fixable。重要提示該規則已在 ESLint v2.0.0 中被移除由 keyword-spacing 規則取代。倉庫的版本數據文件 rule_versions.json 中記錄著這條規則的生命周期其首次出現于 1.4.0space-before-keywords: 1.4.0在 2.0.0-beta.3space-before-keywords: 2.0.0-beta.3之后正式退役。規則詳情覆蓋的關鍵字與兩種風格選項該規則將強制以下關鍵字之前的空格一致性條件與循環if、else、for、while、do、switch異常處理throw、try、catch、finally流程控制with、break、continue、return聲明function、yield、class以及變量聲明let、const、var標簽語句label statements參數選項該規則接收一個參數always或never選項行為默認值always關鍵字前必須至少有一個空格? 默認值never關鍵字else、whiledo...while 場景、finally和catch前不允許有空格—值得注意的是當選項為always時該規則允許關鍵字前面出現左花括號{即}else {會被要求修正但{后的換行與空格不在此規則管轄范圍。如果你希望調整這一行為可以考慮使用 block-spacing 規則。代碼示例always選項下的正反例默認always選項下的錯誤代碼/*eslint space-before-keywords: [error, always]*/ if (foo) { // ... }else {} // else 前缺少空格 const foo bar;let baz qux; // let 前缺少空格 var qux function bar () {} // function 前缺少空格 function bar() { if (foo) {return; } // return 前缺少空格 }默認always選項下的正確代碼/*eslint space-before-keywords: [error, always]*/ if (foo) { // ... } else {} // else 前有空格 (function() {})(); // function 前是 ( ) 等起始符號不受限制 Foo onClick{function bar() {}} / // JSX 屬性中的 function 表達式 for (let foo of [bar, baz, qux]) {} // for/of 前均有空格從上面的 JSX 示例可以看出該規則同樣作用于 JSX 語法上下文中的關鍵字示例中開啟了parserOptions.ecmaFeatures.jsx。代碼示例never選項下的正反例never選項下的錯誤代碼/*eslint space-before-keywords: [error, never]*/ if (foo) { // ... } else {} // else 前不應有空格 do { } while (foo) // do...while 的 while 前不應有空格 try {} finally {} // finally 前不應有空格 try {} catch(e) {} // catch 前不應有空格never選項下的正確代碼/*eslint space-before-keywords: [error, never]*/ if (foo) { // ... }else {} // else 前無空格 do {}while (foo) // do...while 的 while 前無空格 try {}finally {} // finally 前無空格 try{}catch(e) {} // catch 前無空格何時不使用該規則如果你不希望強制執行關鍵字空格的一致性則可以完全關閉此規則不啟用space-before-keywords。規則的演進v2.0.0 移除與keyword-spacing接替space-before-keywords之所以被移除是因為 ESLint 團隊在 v2.0.0 推出了能力更全面的keyword-spacing規則——后者不僅能控制關鍵字之前before的空格還能控制關鍵字之后after的空格并且支持對每個關鍵字單獨定制overrides。倉庫中的 replacements.json 明確記錄了這一替代關系space-before-keywords: [keyword-spacing]同時遷移指南 migrating-to-2.0.0.md 也寫明了對應說明space-before-keywordsis replaced bykeyword-spacing.因此如果你從舊版本升級到 ESLint 2.0.0 或更高版本只需將配置中的規則名替換為keyword-spacing并按下文所述方式設置before選項即可保持原有的檢查行為。源碼剖析keyword-spacing如何實現關鍵字前空格檢查替代規則 keyword-spacing.js 的實現位于倉庫lib/rules/目錄其meta聲明為type: layout布局類與fixable: whitespace可自動修復空白。其配置 Schema 如下源碼 lib/rules/keyword-spacing.js 第 112–136 行schema: [ { type: object, properties: { before: { type: boolean, default: true }, after: { type: boolean, default: true }, overrides: { type: object, properties: KEYS.reduce((retv, key) { retv[key] { type: object, properties: { before: { type: boolean }, after: { type: boolean }, }, additionalProperties: false, }; return retv; }, {}), additionalProperties: false, }, }, additionalProperties: false, }, ],該 Schema 揭示了三層能力before默認true控制關鍵字前是否需要空格等價于舊的space-before-keywords的alwaystrue與neverfalseafter默認true控制關鍵字后是否需要空格這是舊規則不具備的能力overrides以關鍵字名為鍵可針對單個關鍵字單獨覆蓋before/after行為實現細粒度的特例控制。在檢查邏輯中規則維護了兩組正則源碼第 20–23 行const PREV_TOKEN /^[)\]}]$/u; const NEXT_TOKEN /^(?:[([{~!]|\\?|--?)$/u; const PREV_TOKEN_M /^[)\]}*]$/u; const NEXT_TOKEN_M /^[{*]$/u;這些模式用于判斷關鍵字前/后的相鄰 token 是什么。當關鍵字前一個 token 匹配PREV_TOKEN如}、)、]、時才觸發期望空格expectSpaceBefore或禁止空格unexpectSpaceBefore的判斷。修復邏輯的底層實現expectSpaceBefore源碼第 156–177 行通過sourceCode.getTokenBefore(token)獲取關鍵字的前一個 token在滿足前一個 token 類型或值匹配模式、與關鍵字處于同一行、且兩者之間沒有空格時報告錯誤并調用修復器fix(fixer) { return fixer.insertTextBefore(token, ); }即在關鍵字前插入一個空格。與之對應的unexpectSpaceBefore源碼第 185–209 行則在兩個 token 之間存在空格時報告錯誤并移除兩者之間的空白區域fix(fixer) { return fixer.removeRange([ prevToken.range[1], token.range[0], ]); }這種先取前一個 token、再判斷行內空格的機制保證了規則只在同一行內檢查空格不會誤傷跨行代碼例如else換行到下一行的寫法。規則在create階段會根據options.before ! false決定對每個關鍵字掛載expectSpaceBefore還是unexpectSpaceBefore源碼第 280–300 行并支持overrides中的逐關鍵字覆蓋這正是遷移自space-before-keywords后最直接的對應關系。測試用例印證在測試文件 tests/lib/rules/keyword-spacing.js 中可以看到對before: false的驗證等價于舊的never選項options: [{ before: false }],以及通過overrides對單個關鍵字做特判的用例例如對else、if單獨設置before: false、as設置before: true等測試第 982–987 行、1234–1248 行、2395 行、4904 行。這些用例直接覆蓋了從全局統一到逐關鍵字定制的全部配置形態。遷移對照從space-before-keywords到keyword-spacing綜合原規則文檔與keyword-spacing的源碼 Schema兩者的配置映射關系如下舊規則配置新規則等價配置說明[error, always][error, { before: true }]關鍵字前必須有空格before默認即為true[error, never][error, { before: false }]關鍵字前禁止空格無法實現[error, { before: true, after: true }]同時控制關鍵字后的空格無法實現[error, { before: true, overrides: { else: { before: false } } }]僅對else特例禁止前置空格遷移時的關鍵提醒原space-before-keywords的never只作用于else、whiledo...while、finally和catch四個關鍵字而keyword-spacing的before: false會影響其關鍵字列表中的全部關鍵字源碼中KEYS由keywords模塊導出并額外包含as、async、await、from、get、let、of、set、yield等見 keyword-spacing.js 第 28–38 行。因此如果舊配置使用never遷移到新規則后若不想改變對if、for等關鍵字的行為需要借助overrides精確指定哪些關鍵字前置空格被禁用例如{ rules: { keyword-spacing: [error, { before: true, overrides: { else: { before: false }, catch: { before: false }, finally: { before: false } } }] } }補充keyword-spacing的后續命運與格式化規則遷移需要留意的是keyword-spacing規則本身在 ESLint 8.53.0 也被標記為棄用。倉庫源碼 keyword-spacing.js 第 80–101 行的meta.deprecated字段記錄了這一事實該規則屬于格式化類規則ESLint 團隊正逐步將格式化規則移出核心keyword-spacing計劃在 11.0.0 之后從核心中移除其維護職責已移交至 ESLint Stylistic 項目stylistic/eslint-plugin中的keyword-spacing規則。這意味著新項目若需要關鍵字空格檢查建議直接使用 ESLint Stylistic 提供的對應規則而歷史項目在升級時則需關注這一遷移路徑。總結space-before-keywords雖然已在 ESLint v2.0.0 退役但它所承載的關鍵字前空格一致性這一風格訴求至今仍是格式化檢查的重要一環。通過本文你不僅完整掌握了該規則的兩個選項always/never及其全部正反示例還深入理解了其接替者keyword-spacing在 lib/rules/keyword-spacing.js 中的 Schema 設計、token 相鄰判斷機制與自動修復實現以及從舊規則到新規則的精確遷移對照。當你需要在團隊中統一關鍵字空格風格時無論是直接啟用現代規則還是閱讀歷史代碼中的舊配置都可以借助本文快速定位到正確的配置形態。【免費下載鏈接】eslintFind and fix problems in your JavaScript code.項目地址: https://gitcode.com/GitHub_Trending/es/eslint創作聲明:本文部分內容由AI輔助生成(AIGC),僅供參考