ESLint template-curly-spacing 规则深度解析统一模板字符串${}内部空格的布局规则【免费下载链接】eslintFind and fix problems in your JavaScript code.项目地址: https://gitcode.com/GitHub_Trending/es/eslint导读本文围绕 ESLint 核心规则template-curly-spacing展开它是用于统一 JavaScript 模板字符串Template Literal中${ ... }内嵌表达式内部空格风格的 layout布局类规则。文章将以官方文档 docs/src/rules/template-curly-spacing.md 为主体骨架结合仓库内 规则实现源码、单元测试 与 规则元数据讲清两种选项never/always的语义、可自动修复行为、边界情况多行表达式、注释、带标签模板以及该规则的弃用与迁移路径使读者能直接在自己的 ESLint 配置中落地使用。一、规则背景模板字符串中的表达式占位符ES6 模板字符串允许通过一对${与}在字符串中嵌入 JavaScript 表达式例如let hello hello, ${people.name}!;这里的${people.name}就是模板字符串中的嵌入式表达式embedded expression。虽然写法自由但占位符内部的空格风格在不同的风格指南style guides中并不一致有的团队习惯${ people.name }两侧留空格有的则坚持${people.name}紧贴。template-curly-spacing规则正是为这一细节而生它根据配置强制约束花括号对内部的空格使用方式从而让整个代码库的模板字符串保持一致的排版。注意它只关注${与}内部的空格不会管表达式内部自身的格式也不管模板字符串之外的内容。从仓库的 rule_versions.json 可以看到该规则自 ESLint2.0.0-rc.0版本起引入属于历史悠久的核心规则之一。二、Rule Details规则到底检查什么官方文档docs/src/rules/template-curly-spacing.md对本规则的目标给出了明确定义This rule aims to maintain consistency around the spacing inside of template literals.即维护模板字符串内部空格的全局一致性。具体到实现层面lib/rules/template-curly-spacing.js 中的create(context)函数遍历 AST 中的TemplateElement节点对每个模板元素 token 执行两个方向的检查checkSpacingBefore(token)检查}之前是否有空格实现位置checkSpacingAfter(token)检查${之后是否有空格实现位置。两个检查函数都调用了sourceCode.isSpaceBetween()判断两个 token 之间是否存在空白字符并通过astUtils.isTokenOnSameLine()判断是否处于同一行——这两个细节决定了下文要讲的多行表达式豁免行为。规则在meta中声明为layout 类型且fixable: whitespacemeta 定义意味着所有违规都可以通过eslint --fix自动修复。三、Optionsnever与always两种模式规则的配置方式与参数约束在源码 schema 中写得非常清楚lib/rules/template-curly-spacing.js#L54schema: [{ enum: [always, never] }],即只接受一个选项取值只能是always或never二选一传入其他值会在配置校验阶段由共享的 ajv 校验 负责直接报配置错误。默认配置示例{ template-curly-spacing: [error, never] }两种选项的官方语义选项含义源码判定never默认禁止${与}内部出现空格always context.options[0] always为false源码always要求${与}内部至少一个空格always为true需要特别说明默认值是never。从源码const always context.options[0] alwayslib/rules/template-curly-spacing.js#L65可以推断只要未显式传入always规则一律按never处理——这与官方文档never(by default)的描述完全一致。该规则recommended: falsemeta 定义因此它既不在eslint:recommended中也不在 tests/conf/eslint-recommended.js 所列规则之列需要使用者显式开启。3.1 never禁止花括号内部空格不正确的代码默认never选项下会报错/*eslint template-curly-spacing: error*/ hello, ${ people.name}!; hello, ${people.name }!; hello, ${ people.name }!;正确的代码/*eslint template-curly-spacing: error*/ hello, ${people.name}!; hello, ${ people.name }!;注意最后一个多行例子表达式换行书写时${\n与\n}之间是换行而非空格规则同样放行原因见下文多行表达式豁免。3.2 always要求花括号内部至少一个空格不正确的代码always选项下会报错/*eslint template-curly-spacing: [error, always]*/ hello, ${ people.name}!; hello, ${people.name }!; hello, ${people.name}!;正确的代码/*eslint template-curly-spacing: [error, always]*/ hello, ${ people.name }!; hello, ${ people.name }!;可以看出always只要求${与表达式、表达式与}之间各至少一个空格多行写法同样不受影响。3.3 两种模式下的错误消息规则共定义了 4 条 messageIdlib/rules/template-curly-spacing.js#L55-L60在--fix之外使用--format json等格式化器或断言测试时可以直接引用messageId触发条件文本expectedAfteralways下${后缺空格Expected space(s) after ${.expectedBeforealways下}前缺空格Expected space(s) before }.unexpectedAfternever下${后有空格Unexpected space(s) after ${.unexpectedBeforenever下}前有空格Unexpected space(s) before }.四、源码实现三个关键行为细节只讲怎么配还不够结合 lib/rules/template-curly-spacing.js 的实现可以看清规则在三个边界场景下的真实行为这些细节直接影响落地效果。4.1 仅检查紧邻占位符的模板元素checkSpacingBefore首先判断token.value.startsWith(})源码checkSpacingAfter则判断token.value.endsWith(${)源码两者不满足就提前返回。这是因为模板字符串会被解析为若干TemplateElement纯文本段与表达式段交替出现只有恰好以${结束紧邻嵌入表达式之前或以}开始紧邻嵌入表达式之后的模板元素才是本规则关注的对象——首尾以反引号收尾的普通文本段直接被跳过。4.2 多行表达式豁免规则通过astUtils.isTokenOnSameLine(prevToken, token)源码判断${之后 /}之前的 token 是否与占位符位于同一行。只要不在同一行就直接 return不做任何检查。这正是官方示例中以下多行写法在两种模式下都正确的原因hello, ${ people.name }!;换言之本规则只约束同一行内的内联空格多行书写不受影响。这一设计避免了规则与换行缩进风格互相干扰。4.3 注释参与空格判定两个检查函数在取相邻 token 时都传入了includeComments: true源码 与 L123-L125意味着${ /* 注释 */ foo }这类带注释的写法中注释会被当作相邻 token参与isSpaceBetween判定。从 单元测试 可以看到never下${/* */ foo} ${bar /* */}是合法代码而always下${ /* */ foo } ${ bar /* */ }才是合法代码——注释两侧的空格同样受规则约束。4.4 自动修复逻辑规则的fixable: whitespace决定了它支持eslint --fix自动修复never模式下违规时通过fixer.removeRange([...])删除${后或}前的多余空格源码 与 L153-L155always模式下通过fixer.insertTextAfter/insertTextBefore插入一个空格源码 与 L142。注意由于多行场景被豁免修复操作只会发生在同一行内不会把多行表达式强行压平。五、测试验证RuleTester 覆盖的行为矩阵仓库在 tests/lib/rules/template-curly-spacing.js 中为该规则编写了非常详尽的 RuleTester 用例测试运行环境为ecmaVersion: 6即模板字符串的最低支持版本可以作为行为矩阵的权威依据普通模板字符串${foo} ${bar}never合法、${ foo } ${ bar }always合法以及两者互判为违规并给出精确的修复输出如${ foo } ${ bar }→${foo} ${bar}带标签模板tagged templatetag\${foo} ${bar} 等用例与普通模板行为完全一致说明规则对带标签调用同样生效多个空格/制表符${ foo } ${ bar }、${foo }${ bar}、${ foo \t}${\t\tbar }均在never下被逐处报告unexpectedAfter/unexpectedBefore并修复为无空格形式证明规则处理的是任意数量的空白而非仅单个空格注释场景块注释、行注释、跨行注释穿插在占位符内的各种组合均有 valid/invalid 用例且never与always下注释两侧空格规则对称跨行模板\n${foo}\n在always下修复为\n${ foo }\n验证了自动修复对换行场景的处理。测试同时精确断言了每次报告的line/column/endLine/endColumn定位例如${ foo } ${ bar }在never下第一次报告的unexpectedAfter位于第 1 行第 45 列tests/lib/rules/template-curly-spacing.js#L86-L118这为依赖 ESLint 位置的编辑器集成提供了稳定预期。六、在项目配置中启用该规则该规则可通过传统的.eslintrc风格与新版 flat config 两种方式启用。.eslintrc风格JSON{ rules: { template-curly-spacing: [error, never] } }新版 flat configeslint.config.js 风格export default [ { rules: { template-curly-spacing: [error, never] } } ];关于 flat config 的完整迁移说明可参考 docs/src/extend/plugin-migration-flat-config.md。由于该规则recommended: false两种方式下都必须显式声明才会生效。七、When Not To Use It何时关闭该规则官方文档的结论非常直白If you dont want to be notified about usage of spacing inside of template strings, then its safe to disable this rule.即如果你不希望被模板字符串内部的空格问题打扰完全可以安全地关闭它。这背后有两层原因空格属于纯样式问题不影响程序行为关闭不会带来任何功能风险该规则是布局类layout规则从 rules_meta.json 可以看到ESLint 官方从 v8.53.0 起已开始将格式化类规则移出核心template-curly-spacing标记为deprecateddeprecatedSince: 8.53.0availableUntil: 11.0.0其维护工作交由stylistic/eslint-plugin插件接管。因此如果项目已使用stylistic/eslint-plugin应改由该插件的同名template-curly-spacing规则负责此项检查如果项目仅需在 ESLint v11 之前锁定现状继续使用核心内置规则也完全可行如果团队根本不关心这类细节排版直接不启用即可。八、小结template-curly-spacing是 ESLint 中一个小而精的布局规则它以never默认禁止${}内部空格和always要求内部至少一个空格两个选项统一了模板字符串嵌入表达式的排版其实现基于TemplateElementtoken 的成对检查天然豁免多行表达式并支持eslint --fix自动修复与注释感知。结合本文引用的 官方文档、实现源码 与 测试用例开发者可以准确判断该规则在本项目的取舍——包括其自 v8.53.0 起的弃用状态与迁移到 Stylistic 插件的时机。/DSMLparameter /DSMLinvoke /DSMLtool_calls【免费下载链接】eslintFind and fix problems in your JavaScript code.项目地址: https://gitcode.com/GitHub_Trending/es/eslint创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 ESLint template-curly-spacing 规则深度解析：统一模板字符串 `${}` 内部空格的布局规则
ESLint template-curly-spacing 规则深度解析统一模板字符串${}内部空格的布局规则【免费下载链接】eslintFind and fix problems in your JavaScript code.项目地址: https://gitcode.com/GitHub_Trending/es/eslint导读本文围绕 ESLint 核心规则template-curly-spacing展开它是用于统一 JavaScript 模板字符串Template Literal中${ ... }内嵌表达式内部空格风格的 layout布局类规则。文章将以官方文档 docs/src/rules/template-curly-spacing.md 为主体骨架结合仓库内 规则实现源码、单元测试 与 规则元数据讲清两种选项never/always的语义、可自动修复行为、边界情况多行表达式、注释、带标签模板以及该规则的弃用与迁移路径使读者能直接在自己的 ESLint 配置中落地使用。一、规则背景模板字符串中的表达式占位符ES6 模板字符串允许通过一对${与}在字符串中嵌入 JavaScript 表达式例如let hello hello, ${people.name}!;这里的${people.name}就是模板字符串中的嵌入式表达式embedded expression。虽然写法自由但占位符内部的空格风格在不同的风格指南style guides中并不一致有的团队习惯${ people.name }两侧留空格有的则坚持${people.name}紧贴。template-curly-spacing规则正是为这一细节而生它根据配置强制约束花括号对内部的空格使用方式从而让整个代码库的模板字符串保持一致的排版。注意它只关注${与}内部的空格不会管表达式内部自身的格式也不管模板字符串之外的内容。从仓库的 rule_versions.json 可以看到该规则自 ESLint2.0.0-rc.0版本起引入属于历史悠久的核心规则之一。二、Rule Details规则到底检查什么官方文档docs/src/rules/template-curly-spacing.md对本规则的目标给出了明确定义This rule aims to maintain consistency around the spacing inside of template literals.即维护模板字符串内部空格的全局一致性。具体到实现层面lib/rules/template-curly-spacing.js 中的create(context)函数遍历 AST 中的TemplateElement节点对每个模板元素 token 执行两个方向的检查checkSpacingBefore(token)检查}之前是否有空格实现位置checkSpacingAfter(token)检查${之后是否有空格实现位置。两个检查函数都调用了sourceCode.isSpaceBetween()判断两个 token 之间是否存在空白字符并通过astUtils.isTokenOnSameLine()判断是否处于同一行——这两个细节决定了下文要讲的多行表达式豁免行为。规则在meta中声明为layout 类型且fixable: whitespacemeta 定义意味着所有违规都可以通过eslint --fix自动修复。三、Optionsnever与always两种模式规则的配置方式与参数约束在源码 schema 中写得非常清楚lib/rules/template-curly-spacing.js#L54schema: [{ enum: [always, never] }],即只接受一个选项取值只能是always或never二选一传入其他值会在配置校验阶段由共享的 ajv 校验 负责直接报配置错误。默认配置示例{ template-curly-spacing: [error, never] }两种选项的官方语义选项含义源码判定never默认禁止${与}内部出现空格always context.options[0] always为false源码always要求${与}内部至少一个空格always为true需要特别说明默认值是never。从源码const always context.options[0] alwayslib/rules/template-curly-spacing.js#L65可以推断只要未显式传入always规则一律按never处理——这与官方文档never(by default)的描述完全一致。该规则recommended: falsemeta 定义因此它既不在eslint:recommended中也不在 tests/conf/eslint-recommended.js 所列规则之列需要使用者显式开启。3.1 never禁止花括号内部空格不正确的代码默认never选项下会报错/*eslint template-curly-spacing: error*/ hello, ${ people.name}!; hello, ${people.name }!; hello, ${ people.name }!;正确的代码/*eslint template-curly-spacing: error*/ hello, ${people.name}!; hello, ${ people.name }!;注意最后一个多行例子表达式换行书写时${\n与\n}之间是换行而非空格规则同样放行原因见下文多行表达式豁免。3.2 always要求花括号内部至少一个空格不正确的代码always选项下会报错/*eslint template-curly-spacing: [error, always]*/ hello, ${ people.name}!; hello, ${people.name }!; hello, ${people.name}!;正确的代码/*eslint template-curly-spacing: [error, always]*/ hello, ${ people.name }!; hello, ${ people.name }!;可以看出always只要求${与表达式、表达式与}之间各至少一个空格多行写法同样不受影响。3.3 两种模式下的错误消息规则共定义了 4 条 messageIdlib/rules/template-curly-spacing.js#L55-L60在--fix之外使用--format json等格式化器或断言测试时可以直接引用messageId触发条件文本expectedAfteralways下${后缺空格Expected space(s) after ${.expectedBeforealways下}前缺空格Expected space(s) before }.unexpectedAfternever下${后有空格Unexpected space(s) after ${.unexpectedBeforenever下}前有空格Unexpected space(s) before }.四、源码实现三个关键行为细节只讲怎么配还不够结合 lib/rules/template-curly-spacing.js 的实现可以看清规则在三个边界场景下的真实行为这些细节直接影响落地效果。4.1 仅检查紧邻占位符的模板元素checkSpacingBefore首先判断token.value.startsWith(})源码checkSpacingAfter则判断token.value.endsWith(${)源码两者不满足就提前返回。这是因为模板字符串会被解析为若干TemplateElement纯文本段与表达式段交替出现只有恰好以${结束紧邻嵌入表达式之前或以}开始紧邻嵌入表达式之后的模板元素才是本规则关注的对象——首尾以反引号收尾的普通文本段直接被跳过。4.2 多行表达式豁免规则通过astUtils.isTokenOnSameLine(prevToken, token)源码判断${之后 /}之前的 token 是否与占位符位于同一行。只要不在同一行就直接 return不做任何检查。这正是官方示例中以下多行写法在两种模式下都正确的原因hello, ${ people.name }!;换言之本规则只约束同一行内的内联空格多行书写不受影响。这一设计避免了规则与换行缩进风格互相干扰。4.3 注释参与空格判定两个检查函数在取相邻 token 时都传入了includeComments: true源码 与 L123-L125意味着${ /* 注释 */ foo }这类带注释的写法中注释会被当作相邻 token参与isSpaceBetween判定。从 单元测试 可以看到never下${/* */ foo} ${bar /* */}是合法代码而always下${ /* */ foo } ${ bar /* */ }才是合法代码——注释两侧的空格同样受规则约束。4.4 自动修复逻辑规则的fixable: whitespace决定了它支持eslint --fix自动修复never模式下违规时通过fixer.removeRange([...])删除${后或}前的多余空格源码 与 L153-L155always模式下通过fixer.insertTextAfter/insertTextBefore插入一个空格源码 与 L142。注意由于多行场景被豁免修复操作只会发生在同一行内不会把多行表达式强行压平。五、测试验证RuleTester 覆盖的行为矩阵仓库在 tests/lib/rules/template-curly-spacing.js 中为该规则编写了非常详尽的 RuleTester 用例测试运行环境为ecmaVersion: 6即模板字符串的最低支持版本可以作为行为矩阵的权威依据普通模板字符串${foo} ${bar}never合法、${ foo } ${ bar }always合法以及两者互判为违规并给出精确的修复输出如${ foo } ${ bar }→${foo} ${bar}带标签模板tagged templatetag\${foo} ${bar} 等用例与普通模板行为完全一致说明规则对带标签调用同样生效多个空格/制表符${ foo } ${ bar }、${foo }${ bar}、${ foo \t}${\t\tbar }均在never下被逐处报告unexpectedAfter/unexpectedBefore并修复为无空格形式证明规则处理的是任意数量的空白而非仅单个空格注释场景块注释、行注释、跨行注释穿插在占位符内的各种组合均有 valid/invalid 用例且never与always下注释两侧空格规则对称跨行模板\n${foo}\n在always下修复为\n${ foo }\n验证了自动修复对换行场景的处理。测试同时精确断言了每次报告的line/column/endLine/endColumn定位例如${ foo } ${ bar }在never下第一次报告的unexpectedAfter位于第 1 行第 45 列tests/lib/rules/template-curly-spacing.js#L86-L118这为依赖 ESLint 位置的编辑器集成提供了稳定预期。六、在项目配置中启用该规则该规则可通过传统的.eslintrc风格与新版 flat config 两种方式启用。.eslintrc风格JSON{ rules: { template-curly-spacing: [error, never] } }新版 flat configeslint.config.js 风格export default [ { rules: { template-curly-spacing: [error, never] } } ];关于 flat config 的完整迁移说明可参考 docs/src/extend/plugin-migration-flat-config.md。由于该规则recommended: false两种方式下都必须显式声明才会生效。七、When Not To Use It何时关闭该规则官方文档的结论非常直白If you dont want to be notified about usage of spacing inside of template strings, then its safe to disable this rule.即如果你不希望被模板字符串内部的空格问题打扰完全可以安全地关闭它。这背后有两层原因空格属于纯样式问题不影响程序行为关闭不会带来任何功能风险该规则是布局类layout规则从 rules_meta.json 可以看到ESLint 官方从 v8.53.0 起已开始将格式化类规则移出核心template-curly-spacing标记为deprecateddeprecatedSince: 8.53.0availableUntil: 11.0.0其维护工作交由stylistic/eslint-plugin插件接管。因此如果项目已使用stylistic/eslint-plugin应改由该插件的同名template-curly-spacing规则负责此项检查如果项目仅需在 ESLint v11 之前锁定现状继续使用核心内置规则也完全可行如果团队根本不关心这类细节排版直接不启用即可。八、小结template-curly-spacing是 ESLint 中一个小而精的布局规则它以never默认禁止${}内部空格和always要求内部至少一个空格两个选项统一了模板字符串嵌入表达式的排版其实现基于TemplateElementtoken 的成对检查天然豁免多行表达式并支持eslint --fix自动修复与注释感知。结合本文引用的 官方文档、实现源码 与 测试用例开发者可以准确判断该规则在本项目的取舍——包括其自 v8.53.0 起的弃用状态与迁移到 Stylistic 插件的时机。/DSMLparameter /DSMLinvoke /DSMLtool_calls【免费下载链接】eslintFind and fix problems in your JavaScript code.项目地址: https://gitcode.com/GitHub_Trending/es/eslint创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考