ESLint no-unexpected-multiline 规则详解捕获看似换行结束实则未结束的混淆多行表达式【免费下载链接】eslintFind and fix problems in your JavaScript code.项目地址: https://gitcode.com/GitHub_Trending/es/eslint导读no-unexpected-multiline是 ESLint 内置的一条problem问题类型规则用于识别换行看起来结束了语句、但实际上并没有结束的混淆多行表达式——这类代码在语法上完全合法却极可能让读者误判语句边界进而在运行时抛出异常。本文以 官方规则文档 为骨架结合 规则源码 与 完整测试用例系统讲解该规则的背景原理、四种检测场景、配置方式与适用边界帮助你理解并驾驭这条已进入recommended集合的默认开启规则。背景JavaScript 的自动分号插入ASI与歧义换行JavaScript 中分号通常可以省略因为引擎会执行自动分号插入Automatic Semicolon Insertion简称 ASI。如果你希望强制或禁止分号可以使用 semi 规则。ASI 的规则本身相对直接。正如 Isaac Schlueter 曾总结的那样换行符总是会结束一条语句其效果等同于分号除非满足以下任一例外语句中存在未闭合的括号、数组字面量、对象字面量或者以其他无法合法结束语句的方式结尾例如以.或,结尾该行是--或此时它会作用于下一行的 token执行自减/自增该行是for()、while()、do、if()或else且后面没有{下一行以[、(、、*、/、-、,、.或其他只能出现在单个表达式中两个 token 之间的二元运算符开头。在换行不会结束语句的这些例外情况下如果程序员漏写了分号两条本不相关的连续代码行就会被解析器合并成同一个表达式。这种代码虽然在语法上是合法的能通过解析但语义与书写者的意图完全不同——尤其是在无分号的编码风格下读者很容易忽略这个笔误导致代码在运行时抛出异常。Rule Details规则如何判定意外的多行表达式本规则的核心定义是禁止那些换行看起来像在结束语句但实际上并没有的混淆多行表达式。它在 规则元信息 中声明为type: problem属于问题类规则意味着发现的问题通常是真正的 bug 隐患recommended: true已列入 ESLint 的推荐配置eslint:recommended默认开启conf/rules.json 数据 也确认其为 recommended 且不可自动修复fixable: falseschema: []不接受任何选项四条消息 IDfunction、property、taggedTemplate、division分别对应规则检测的四类场景。检测场景一函数调用前的换行(开头当上一行的语句如变量声明const foo bar之后紧跟一行以(开头的函数调用时ASI 不会插入分号两行会被合并为一个表达式。源码中通过 CallExpression 分支 检查若调用表达式的callee与参数开括号之间存在换行即报告function消息。错误示例/*eslint no-unexpected-multiline: error*/ const foo bar (1 || 2).baz(); // 被解析为 bar(1 || 2).baz() 而非两条语句正确示例const foo bar; (1 || 2).baz(); // 显式分号结束上一条语句 const baz bar ;(1 || 2).baz() // 行首分号强制结束语句检测场景二属性访问前的换行[开头当下一行以[开头时解析器会把它视为对上一行表达式的计算属性访问而不是数组字面量。源码中的 MemberExpression 分支 专门针对计算属性node.computed为真且非可选链node.optional为假的成员表达式做换行检查命中后报告property消息。错误示例const hello world [1, 2, 3].forEach(addNumber); // 被解析为 world[1,2,3] 再调用抛出异常正确示例const hello world; [1, 2, 3].forEach(addNumber); const hi world void [1, 2, 3].forEach(addNumber); // 用 void 运算符隔断表达式检测场景三标签模板前的换行开头当上一行是一个函数表达式、变量声明等下一行以反引号开头的模板字符串开始时该模板串会被解析为标签模板tagged template即调用上一行的函数。源码中的 TaggedTemplateExpression 分支 检查模板quasi前的 token 与模板起始位置是否跨行命中即报告taggedTemplate消息。该分支还专门处理了常见标签、括号包裹的标签以及 TypeScript 泛型类型参数等情况。错误示例const x function() {} hello // 被解析为调用 xhello const y function() {} y hello // 跨两行后依然被视为 yhello正确示例const x function() {}; hello // 分号结束语句模板串成为独立表达式 const tag function() {} tag hello // 有意使用标签模板属于合法用法检测场景四除法运算符前的换行/开头当上一行以变量名等表达式结尾、下一行以/开头的正则字面量开始时整段代码会被解析为连续除法运算而非两条语句。源码中的 BinaryExpression 分支 做了精细的判别通过正则REGEX_FLAG_MATCHER /^[gimsuy]$/u匹配/之后的 token 是否为合法的正则修饰符从而确认下一行确实是一个正则字面量再报告division消息。错误示例const z foo /regex/g.test(bar) // 被解析为连续除法 foo / regex / g / .test(bar)正确示例分隔除法表达式避免歧义const z foo / 2;Options无选项配置本规则没有任何选项schema: []见 规则源码。你只能选择开启或关闭它无法调整检测的严格程度或范围。作为对比semi规则强制/禁止分号与no-unexpected-multiline是两条独立的规则——需要注意被本规则视为问题的这些模式semi规则并不会标记出来。即便你已经通过semi规则统一了分号风格no-unexpected-multiline依然有独立的存在价值二者互为补充。使用方式与配置示例在 ESLint 扁平配置flat config中开启本规则export default [ { rules: { no-unexpected-multiline: error, }, }, ];由于该规则已在recommended: true中直接继承eslint:recommended即可默认启用。实际检查时ESLint 通过 lib/rules/index.js 中的no-unexpected-multiline: () require(./no-unexpected-multiline)注册并惰性加载该规则模块。如需手动验证也可以在仓库根目录下对示例文件运行node bin/eslint.js --no-config-lookup --rule no-unexpected-multiline: error example.js边界情况与源码级细节从 规则测试用例 可以看到规则在大量边界场景下做了严谨处理可选链不误报var a b\n ?.(x || y).doSomething()以及?.[形式均判为合法因为?.已经明确表达了跨行继续的意图对应源码中node.optional的过滤未闭合表达式不误报var a (\n(123)\n)、f(\n(x)\n)等带未闭合括号的多行写法是合法代码类字段Class Fields场景ES2015 的类字段与计算属性名之间允许换行class C { field1\n[field2]; }是合法的但class C { field1 obj\n[field2]; }会触发property报告因为字段初始化表达式与计算属性之间形成了意外合并除法的精细判别foo\n/ bar /2这类写法不会误报2不是正则修饰符而foo\n/ bar /gym、foo\n/ bar /s.test(baz)等会被判定为混淆除法并报告division测试中还有专门针对 TypeScript 泛型标签模板issue #11650 相关的 parser fixture 用例。此外func-call-spacing 的源码注释指出如果存在?.它并不会隐藏 no-unexpected-multiline 的错误说明可选链语法与换行检测之间存在经过深思熟虑的交互设计两条规则各司其职。When Not To Use It何时关闭本规则如果你非常确信自己不会意外写出这类代码可以关闭此规则。但需要记住这类问题代码是语法正确的解析器不会报错semi规则也不会介入因此它属于沉默的 bug——通常在运行时才会暴露。对于绝大多数项目保留eslint:recommended中该规则的默认开启状态是更稳妥的选择。总结no-unexpected-multiline用四条针对性检测函数调用、属性访问、标签模板、除法/正则混淆覆盖了 ASI 例外规则下最容易产生的四类换行歧义问题。它无选项、不可自动修复、已被推荐配置默认启用其实现细节可选链过滤、类字段兼容、正则修饰符判别均可在 规则源码 与 测试套件 中逐一验证。理解它的判定逻辑能帮助你写出对读者和未来的自己语义清晰的 JavaScript 代码也解释了为什么少一个分号有时会引发难以排查的运行时异常。【免费下载链接】eslintFind and fix problems in your JavaScript code.项目地址: https://gitcode.com/GitHub_Trending/es/eslint创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
ESLint no-unexpected-multiline 规则详解捕获看似换行结束实则未结束的混淆多行表达式【免费下载链接】eslintFind and fix problems in your JavaScript code.项目地址: https://gitcode.com/GitHub_Trending/es/eslint导读no-unexpected-multiline是 ESLint 内置的一条problem问题类型规则用于识别换行看起来结束了语句、但实际上并没有结束的混淆多行表达式——这类代码在语法上完全合法却极可能让读者误判语句边界进而在运行时抛出异常。本文以 官方规则文档 为骨架结合 规则源码 与 完整测试用例系统讲解该规则的背景原理、四种检测场景、配置方式与适用边界帮助你理解并驾驭这条已进入recommended集合的默认开启规则。背景JavaScript 的自动分号插入ASI与歧义换行JavaScript 中分号通常可以省略因为引擎会执行自动分号插入Automatic Semicolon Insertion简称 ASI。如果你希望强制或禁止分号可以使用 semi 规则。ASI 的规则本身相对直接。正如 Isaac Schlueter 曾总结的那样换行符总是会结束一条语句其效果等同于分号除非满足以下任一例外语句中存在未闭合的括号、数组字面量、对象字面量或者以其他无法合法结束语句的方式结尾例如以.或,结尾该行是--或此时它会作用于下一行的 token执行自减/自增该行是for()、while()、do、if()或else且后面没有{下一行以[、(、、*、/、-、,、.或其他只能出现在单个表达式中两个 token 之间的二元运算符开头。在换行不会结束语句的这些例外情况下如果程序员漏写了分号两条本不相关的连续代码行就会被解析器合并成同一个表达式。这种代码虽然在语法上是合法的能通过解析但语义与书写者的意图完全不同——尤其是在无分号的编码风格下读者很容易忽略这个笔误导致代码在运行时抛出异常。Rule Details规则如何判定意外的多行表达式本规则的核心定义是禁止那些换行看起来像在结束语句但实际上并没有的混淆多行表达式。它在 规则元信息 中声明为type: problem属于问题类规则意味着发现的问题通常是真正的 bug 隐患recommended: true已列入 ESLint 的推荐配置eslint:recommended默认开启conf/rules.json 数据 也确认其为 recommended 且不可自动修复fixable: falseschema: []不接受任何选项四条消息 IDfunction、property、taggedTemplate、division分别对应规则检测的四类场景。检测场景一函数调用前的换行(开头当上一行的语句如变量声明const foo bar之后紧跟一行以(开头的函数调用时ASI 不会插入分号两行会被合并为一个表达式。源码中通过 CallExpression 分支 检查若调用表达式的callee与参数开括号之间存在换行即报告function消息。错误示例/*eslint no-unexpected-multiline: error*/ const foo bar (1 || 2).baz(); // 被解析为 bar(1 || 2).baz() 而非两条语句正确示例const foo bar; (1 || 2).baz(); // 显式分号结束上一条语句 const baz bar ;(1 || 2).baz() // 行首分号强制结束语句检测场景二属性访问前的换行[开头当下一行以[开头时解析器会把它视为对上一行表达式的计算属性访问而不是数组字面量。源码中的 MemberExpression 分支 专门针对计算属性node.computed为真且非可选链node.optional为假的成员表达式做换行检查命中后报告property消息。错误示例const hello world [1, 2, 3].forEach(addNumber); // 被解析为 world[1,2,3] 再调用抛出异常正确示例const hello world; [1, 2, 3].forEach(addNumber); const hi world void [1, 2, 3].forEach(addNumber); // 用 void 运算符隔断表达式检测场景三标签模板前的换行开头当上一行是一个函数表达式、变量声明等下一行以反引号开头的模板字符串开始时该模板串会被解析为标签模板tagged template即调用上一行的函数。源码中的 TaggedTemplateExpression 分支 检查模板quasi前的 token 与模板起始位置是否跨行命中即报告taggedTemplate消息。该分支还专门处理了常见标签、括号包裹的标签以及 TypeScript 泛型类型参数等情况。错误示例const x function() {} hello // 被解析为调用 xhello const y function() {} y hello // 跨两行后依然被视为 yhello正确示例const x function() {}; hello // 分号结束语句模板串成为独立表达式 const tag function() {} tag hello // 有意使用标签模板属于合法用法检测场景四除法运算符前的换行/开头当上一行以变量名等表达式结尾、下一行以/开头的正则字面量开始时整段代码会被解析为连续除法运算而非两条语句。源码中的 BinaryExpression 分支 做了精细的判别通过正则REGEX_FLAG_MATCHER /^[gimsuy]$/u匹配/之后的 token 是否为合法的正则修饰符从而确认下一行确实是一个正则字面量再报告division消息。错误示例const z foo /regex/g.test(bar) // 被解析为连续除法 foo / regex / g / .test(bar)正确示例分隔除法表达式避免歧义const z foo / 2;Options无选项配置本规则没有任何选项schema: []见 规则源码。你只能选择开启或关闭它无法调整检测的严格程度或范围。作为对比semi规则强制/禁止分号与no-unexpected-multiline是两条独立的规则——需要注意被本规则视为问题的这些模式semi规则并不会标记出来。即便你已经通过semi规则统一了分号风格no-unexpected-multiline依然有独立的存在价值二者互为补充。使用方式与配置示例在 ESLint 扁平配置flat config中开启本规则export default [ { rules: { no-unexpected-multiline: error, }, }, ];由于该规则已在recommended: true中直接继承eslint:recommended即可默认启用。实际检查时ESLint 通过 lib/rules/index.js 中的no-unexpected-multiline: () require(./no-unexpected-multiline)注册并惰性加载该规则模块。如需手动验证也可以在仓库根目录下对示例文件运行node bin/eslint.js --no-config-lookup --rule no-unexpected-multiline: error example.js边界情况与源码级细节从 规则测试用例 可以看到规则在大量边界场景下做了严谨处理可选链不误报var a b\n ?.(x || y).doSomething()以及?.[形式均判为合法因为?.已经明确表达了跨行继续的意图对应源码中node.optional的过滤未闭合表达式不误报var a (\n(123)\n)、f(\n(x)\n)等带未闭合括号的多行写法是合法代码类字段Class Fields场景ES2015 的类字段与计算属性名之间允许换行class C { field1\n[field2]; }是合法的但class C { field1 obj\n[field2]; }会触发property报告因为字段初始化表达式与计算属性之间形成了意外合并除法的精细判别foo\n/ bar /2这类写法不会误报2不是正则修饰符而foo\n/ bar /gym、foo\n/ bar /s.test(baz)等会被判定为混淆除法并报告division测试中还有专门针对 TypeScript 泛型标签模板issue #11650 相关的 parser fixture 用例。此外func-call-spacing 的源码注释指出如果存在?.它并不会隐藏 no-unexpected-multiline 的错误说明可选链语法与换行检测之间存在经过深思熟虑的交互设计两条规则各司其职。When Not To Use It何时关闭本规则如果你非常确信自己不会意外写出这类代码可以关闭此规则。但需要记住这类问题代码是语法正确的解析器不会报错semi规则也不会介入因此它属于沉默的 bug——通常在运行时才会暴露。对于绝大多数项目保留eslint:recommended中该规则的默认开启状态是更稳妥的选择。总结no-unexpected-multiline用四条针对性检测函数调用、属性访问、标签模板、除法/正则混淆覆盖了 ASI 例外规则下最容易产生的四类换行歧义问题。它无选项、不可自动修复、已被推荐配置默认启用其实现细节可选链过滤、类字段兼容、正则修饰符判别均可在 规则源码 与 测试套件 中逐一验证。理解它的判定逻辑能帮助你写出对读者和未来的自己语义清晰的 JavaScript 代码也解释了为什么少一个分号有时会引发难以排查的运行时异常。【免费下载链接】eslintFind and fix problems in your JavaScript code.项目地址: https://gitcode.com/GitHub_Trending/es/eslint创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
