ESLint no-invalid-regexp 规则深度解析拦截RegExp构造函数中的无效正则表达式【免费下载链接】eslintFind and fix problems in your JavaScript code.项目地址: https://gitcode.com/GitHub_Trending/es/eslintno-invalid-regexp是 ESLint 内置的problem型规则即用于发现代码中潜在 Bug它专门检查通过RegExp构造函数RegExp(...)与new RegExp(...)传入的正则表达式字符串与标志位是否合法。本文将以仓库中的官方文档 docs/src/rules/no-invalid-regexp.md 为主体骨架结合 lib/rules/no-invalid-regexp.js 的源码实现与 tests/lib/rules/no-invalid-regexp.js 的完整测试用例深入讲解该规则的触发场景、可选配置项以及底层验证机制帮助你彻底掌握如何在静态分析阶段提前发现这类运行时才可能抛出的SyntaxError。为什么需要这条规则静态阶段 vs 运行时阶段在 JavaScript 中正则表达式字面量如/[的无效模式在代码被解析时就会直接抛出SyntaxError属于语法层面的错误ESLint 的解析器在编译阶段就会拦截。然而通过RegExp构造函数传入的字符串是普通的字符串字面量解析器无法感知其内容是否为一个合法正则。无效字符串只有在代码真正执行到new RegExp([)这一步时才会抛出SyntaxError。这意味着错误发生在运行时而非编译期无法被解析器捕获若该代码路径未被测试覆盖缺陷会直接流到生产环境测试阶段若分支未执行CI 也无法发现。no-invalid-regexp的使命就是在静态分析阶段校验RegExp构造函数中传入的字符串与标志位把这种运行时错误提前暴露出来。该规则自 ESLint0.1.4版本起就已存在见 docs/src/_data/rule_versions.json 中no-invalid-regexp: 0.1.4并被标记为recommended: true见 docs/src/_data/rules.json意味着它默认包含在eslint:recommended配置中开箱即用。Rule Details该规则禁止在RegExp构造函数中使用无效的正则表达式字符串。根据 lib/rules/no-invalid-regexp.js 的实现规则的监听器为CallExpression, NewExpression源码第 181 行并且只对以下调用形式生效源码第 182-188 行node.callee.type ! Identifier || node.callee.name ! RegExp || !sourceCode.isGlobalReference(node.callee)即被调用的必须是以RegExp为标识符、且引用的是全局RegExp的调用。如果RegExp被局部变量遮蔽如function foo(RegExp) { RegExp([); }、被重新赋值、或者通过this.RegExp(...)、global.RegExp(...)调用则规则不进行校验——因为此时调用方已不再是真正的原生构造函数校验无意义。错误的代码示例::: incorrect/*eslint no-invalid-regexp: error*/ RegExp([) RegExp(., z) new RegExp(\\):::以上三个示例对应的实际错误分别为代码规则报告的信息RegExp([)Invalid regular expression: /[/: Unterminated character class字符类未闭合RegExp(., z)Invalid flags supplied to RegExp constructor zz不是合法标志位new RegExp(\\)Invalid regular expression: /\/: \ at end of pattern反斜杠位于模式末尾这三个错误消息均可在测试文件 tests/lib/rules/no-invalid-regexp.js 的invalid用例中找到精确断言。正确的代码示例::: correct/*eslint no-invalid-regexp: error*/ RegExp(.) new RegExp this.RegExp([):::RegExp(.)模式与标志位均合法new RegExp未传任何参数此时等价于/(?:)/规则放行this.RegExp([)调用方不是全局RegExp引用规则不干预。Options该规则接受一个对象选项用于配置例外情况选项类型说明allowConstructorFlagsstring[]允许的构造器标志位数组区分大小写。列出的标志位将被规则忽略选项对应的 JSON Schema 定义位于源码 lib/rules/no-invalid-regexp.js 第 34-48 行allowConstructorFlags必须是字符串数组items: { type: string }且不允许重复项uniqueItems: true对象中不允许出现其他属性additionalProperties: false。默认情况下规则只认可 ECMAScript 规范定义的标准标志位。从源码第 13 行可以看到规则维护的合法标志位集合const validFlags dgimsuvy;即dhasIndices、gglobal、iignoreCase、mmultiline、sdotAll、uunicode、vunicodeSets、ysticky。allowConstructorFlags 的用途某些环境或运行时会自定义额外的标志位例如 Deno、特定宿主环境扩展。如果代码中确实需要使用规范之外的标志位可以通过该选项放行::: correct/*eslint no-invalid-regexp: [error, { allowConstructorFlags: [a, z] }]*/ new RegExp(., a) new RegExp(., az):::在以上配置下a与z被视为合法标志位规则不再报告错误。选项的底层处理逻辑从源码第 57-68 行可以看到规则处理allowConstructorFlags时还有一个值得注意的细节const temp allowConstructorFlags .join() .replace(new RegExp([${validFlags}], gu), ); if (temp) { allowedFlags [...new Set(temp)]; }即标准标志位dgimsuvy不会进入allowedFlags它们已被内置逻辑处理只有剩余的、非标准的自定义标志位才被加入放行列表。同时用new Set去重。allowConstructorFlags是区分大小写的。测试用例验证了这一点tests/lib/rules/no-invalid-regexp.js配置[A]时RegExp(., a)仍然报错Invalid flags supplied to RegExp constructor a配置[a]时RegExp(., A)同样报错Invalid flags supplied to RegExp constructor A。底层实现原理基于 regexpp 的静态验证该规则并不依赖运行时去真正构造RegExp对象而是借助eslint-community/regexpp的RegExpValidator进行纯静态的语法解析。源码第 11-12 行const RegExpValidator require(eslint-community/regexpp).RegExpValidator; const validator new RegExpValidator();规则的核心校验分为标志位校验与模式校验两条路径。1. 标志位校验源码第 149-178 行的validateRegExpFlags函数依次检查三类问题重复标志位如new RegExp(., aa)会报告Duplicate flags (a) supplied to RegExp constructor。测试用例中aga、aaz、azz、uu等均被覆盖u与v互斥new RegExp(., uv)会报告Regex u and v flags cannot be used together。源码注释指出虽然regexpp在解析Pattern时会依据ecma262检查u/v组合但当模式无法识别如模式参数是变量时需要在此处单独兜底校验源码第 160-167 行无效标志位如RegExp(., z)会报告Invalid flags supplied to RegExp constructor z。标志位在以下两种情况下无法确定源码第 108-118 行的getFlags返回null参数不足两个或第二个参数不是字符串字面量如变量flags。此时标志位校验直接跳过。2. 模式校验模式参数第一个参数必须是字符串字面量才会被校验源码第 214-216 行isString检查Literal节点且typeof node.value string。validateRegExpPattern源码第 128-140 行将模式交给validator.validatePattern(pattern, undefined1, undefined1, flags)验证捕获并返回regexpp抛出的错误消息。其中最具技巧性的分支是当标志位未知flags null时源码第 220-234 行规则会同时尝试三种模式flags null ? validateRegExpPattern(pattern, { unicode: true, unicodeSets: false }) validateRegExpPattern(pattern, { unicode: false, unicodeSets: true }) validateRegExpPattern(pattern, { unicode: false, unicodeSets: false }) : ...也就是说只有当模式在u模式、v模式、普通模式三种情况下都无效时才报告错误。这是因为u/v标志会显著改变模式的语法规则例如RegExp({, flags)在没有u标志时合法{被当作普通字符因此不应报错RegExp(\\u{0}*, flags)在没有u标志时非法但在u模式下合法同样不应报错。测试用例第 53-65 行明确验证了这两种情况。而当标志位确定时规则直接按对应的unicode/unicodeSets组合校验源码第 235-238 行。边界情况与注意事项规则校验遵循最新 ECMAScript 规范与解析器设置无关原文档明确指出Please note that this rule validates regular expressions per the latest ECMAScript specification, regardless of your parser settings.请注意无论你的解析器设置如何本规则都按照最新的 ECMAScript 规范验证正则表达式。这意味着即使你的项目 parser 配置为较旧的 ECMAScript 版本该规则仍会按最新规范判定模式合法性。例如测试用例中覆盖了ES2020命名捕获组、\p{Script...}属性转义ES2022dhasIndices标志、新 Unicode 属性ES2024vunicodeSets标志、集合差集[A--B]、交集[AB]ES2025重复捕获组名Duplicate capture group name、内联修饰符(?ims:foo)及其各种非法形式如(?ii:foo)报告Duplicated flag i、(?-:foo)报告Invalid empty flags、(?g:foo)报告Invalid group。从测试文件 tests/lib/rules/no-invalid-regexp.js 的用例分组注释可以看到这些 ES 版本演进对应的验证能力。仅校验字符串字面量模式与标志位都必须是字符串字面量才会被校验。例如new RegExp(pattern, g)模式是变量、new RegExp(., y)标志位是变量都不会触发报告——这是合理的设计因为变量值在静态阶段无法确定。但标志位错误检查有个例外当标志位是字符串字面量而模式是变量时标志位仍会被校验见测试用例new RegExp(pattern, az)配合allowConstructorFlags: [a]时报告Invalid flags supplied to RegExp constructor z。标志位检查优先于模式检查从源码执行顺序看第 203-212 行规则先校验标志位一旦发现标志位非法就立即报告并返回不再继续校验模式。因此RegExp() , a)这类代码会先报告Invalid flags supplied to RegExp constructor a而非模式错误。与相关规则的配合docs/src/rules/prefer-named-capture-group.md 和 docs/src/rules/no-useless-backreference.md 的文档中都将no-invalid-regexp列为关联规则说明它常与其他正则相关规则一起构成完整的正则质量检查体系。配置建议与实战小结由于该规则已被标记为recommended: true见 docs/src/_data/rules.json使用eslint:recommended预设的项目无需任何配置即可获得此检查。如果需要自定义配置典型用法如下// eslint.config.js (flat config) export default [ { rules: { no-invalid-regexp: [error, { allowConstructorFlags: [a] }] } } ];// .eslintrc.json (legacy config) { rules: { no-invalid-regexp: [error, { allowConstructorFlags: [a] }] } }需要注意建议保持默认除非你的运行环境确实支持规范之外的自定义标志位否则不要配置allowConstructorFlags以免掩盖真实错误大小写敏感a与A是完全不同的配置项配置时务必与实际使用的标志位一致标准标志位无需列入dgimsuvy中任何一个都不会被当作额外允许的标志它们本身就在默认合法集合内。总而言之no-invalid-regexp把正则构造错误从运行时崩溃提前到静态分析报告配合其基于regexpp的严格按最新 ECMAScript 规范校验的能力是保障 JavaScript 项目中动态正则安全的一道重要防线。【免费下载链接】eslintFind and fix problems in your JavaScript code.项目地址: https://gitcode.com/GitHub_Trending/es/eslint创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
ESLint no-invalid-regexp 规则深度解析：拦截 `RegExp` 构造函数中的无效正则表达式
ESLint no-invalid-regexp 规则深度解析拦截RegExp构造函数中的无效正则表达式【免费下载链接】eslintFind and fix problems in your JavaScript code.项目地址: https://gitcode.com/GitHub_Trending/es/eslintno-invalid-regexp是 ESLint 内置的problem型规则即用于发现代码中潜在 Bug它专门检查通过RegExp构造函数RegExp(...)与new RegExp(...)传入的正则表达式字符串与标志位是否合法。本文将以仓库中的官方文档 docs/src/rules/no-invalid-regexp.md 为主体骨架结合 lib/rules/no-invalid-regexp.js 的源码实现与 tests/lib/rules/no-invalid-regexp.js 的完整测试用例深入讲解该规则的触发场景、可选配置项以及底层验证机制帮助你彻底掌握如何在静态分析阶段提前发现这类运行时才可能抛出的SyntaxError。为什么需要这条规则静态阶段 vs 运行时阶段在 JavaScript 中正则表达式字面量如/[的无效模式在代码被解析时就会直接抛出SyntaxError属于语法层面的错误ESLint 的解析器在编译阶段就会拦截。然而通过RegExp构造函数传入的字符串是普通的字符串字面量解析器无法感知其内容是否为一个合法正则。无效字符串只有在代码真正执行到new RegExp([)这一步时才会抛出SyntaxError。这意味着错误发生在运行时而非编译期无法被解析器捕获若该代码路径未被测试覆盖缺陷会直接流到生产环境测试阶段若分支未执行CI 也无法发现。no-invalid-regexp的使命就是在静态分析阶段校验RegExp构造函数中传入的字符串与标志位把这种运行时错误提前暴露出来。该规则自 ESLint0.1.4版本起就已存在见 docs/src/_data/rule_versions.json 中no-invalid-regexp: 0.1.4并被标记为recommended: true见 docs/src/_data/rules.json意味着它默认包含在eslint:recommended配置中开箱即用。Rule Details该规则禁止在RegExp构造函数中使用无效的正则表达式字符串。根据 lib/rules/no-invalid-regexp.js 的实现规则的监听器为CallExpression, NewExpression源码第 181 行并且只对以下调用形式生效源码第 182-188 行node.callee.type ! Identifier || node.callee.name ! RegExp || !sourceCode.isGlobalReference(node.callee)即被调用的必须是以RegExp为标识符、且引用的是全局RegExp的调用。如果RegExp被局部变量遮蔽如function foo(RegExp) { RegExp([); }、被重新赋值、或者通过this.RegExp(...)、global.RegExp(...)调用则规则不进行校验——因为此时调用方已不再是真正的原生构造函数校验无意义。错误的代码示例::: incorrect/*eslint no-invalid-regexp: error*/ RegExp([) RegExp(., z) new RegExp(\\):::以上三个示例对应的实际错误分别为代码规则报告的信息RegExp([)Invalid regular expression: /[/: Unterminated character class字符类未闭合RegExp(., z)Invalid flags supplied to RegExp constructor zz不是合法标志位new RegExp(\\)Invalid regular expression: /\/: \ at end of pattern反斜杠位于模式末尾这三个错误消息均可在测试文件 tests/lib/rules/no-invalid-regexp.js 的invalid用例中找到精确断言。正确的代码示例::: correct/*eslint no-invalid-regexp: error*/ RegExp(.) new RegExp this.RegExp([):::RegExp(.)模式与标志位均合法new RegExp未传任何参数此时等价于/(?:)/规则放行this.RegExp([)调用方不是全局RegExp引用规则不干预。Options该规则接受一个对象选项用于配置例外情况选项类型说明allowConstructorFlagsstring[]允许的构造器标志位数组区分大小写。列出的标志位将被规则忽略选项对应的 JSON Schema 定义位于源码 lib/rules/no-invalid-regexp.js 第 34-48 行allowConstructorFlags必须是字符串数组items: { type: string }且不允许重复项uniqueItems: true对象中不允许出现其他属性additionalProperties: false。默认情况下规则只认可 ECMAScript 规范定义的标准标志位。从源码第 13 行可以看到规则维护的合法标志位集合const validFlags dgimsuvy;即dhasIndices、gglobal、iignoreCase、mmultiline、sdotAll、uunicode、vunicodeSets、ysticky。allowConstructorFlags 的用途某些环境或运行时会自定义额外的标志位例如 Deno、特定宿主环境扩展。如果代码中确实需要使用规范之外的标志位可以通过该选项放行::: correct/*eslint no-invalid-regexp: [error, { allowConstructorFlags: [a, z] }]*/ new RegExp(., a) new RegExp(., az):::在以上配置下a与z被视为合法标志位规则不再报告错误。选项的底层处理逻辑从源码第 57-68 行可以看到规则处理allowConstructorFlags时还有一个值得注意的细节const temp allowConstructorFlags .join() .replace(new RegExp([${validFlags}], gu), ); if (temp) { allowedFlags [...new Set(temp)]; }即标准标志位dgimsuvy不会进入allowedFlags它们已被内置逻辑处理只有剩余的、非标准的自定义标志位才被加入放行列表。同时用new Set去重。allowConstructorFlags是区分大小写的。测试用例验证了这一点tests/lib/rules/no-invalid-regexp.js配置[A]时RegExp(., a)仍然报错Invalid flags supplied to RegExp constructor a配置[a]时RegExp(., A)同样报错Invalid flags supplied to RegExp constructor A。底层实现原理基于 regexpp 的静态验证该规则并不依赖运行时去真正构造RegExp对象而是借助eslint-community/regexpp的RegExpValidator进行纯静态的语法解析。源码第 11-12 行const RegExpValidator require(eslint-community/regexpp).RegExpValidator; const validator new RegExpValidator();规则的核心校验分为标志位校验与模式校验两条路径。1. 标志位校验源码第 149-178 行的validateRegExpFlags函数依次检查三类问题重复标志位如new RegExp(., aa)会报告Duplicate flags (a) supplied to RegExp constructor。测试用例中aga、aaz、azz、uu等均被覆盖u与v互斥new RegExp(., uv)会报告Regex u and v flags cannot be used together。源码注释指出虽然regexpp在解析Pattern时会依据ecma262检查u/v组合但当模式无法识别如模式参数是变量时需要在此处单独兜底校验源码第 160-167 行无效标志位如RegExp(., z)会报告Invalid flags supplied to RegExp constructor z。标志位在以下两种情况下无法确定源码第 108-118 行的getFlags返回null参数不足两个或第二个参数不是字符串字面量如变量flags。此时标志位校验直接跳过。2. 模式校验模式参数第一个参数必须是字符串字面量才会被校验源码第 214-216 行isString检查Literal节点且typeof node.value string。validateRegExpPattern源码第 128-140 行将模式交给validator.validatePattern(pattern, undefined1, undefined1, flags)验证捕获并返回regexpp抛出的错误消息。其中最具技巧性的分支是当标志位未知flags null时源码第 220-234 行规则会同时尝试三种模式flags null ? validateRegExpPattern(pattern, { unicode: true, unicodeSets: false }) validateRegExpPattern(pattern, { unicode: false, unicodeSets: true }) validateRegExpPattern(pattern, { unicode: false, unicodeSets: false }) : ...也就是说只有当模式在u模式、v模式、普通模式三种情况下都无效时才报告错误。这是因为u/v标志会显著改变模式的语法规则例如RegExp({, flags)在没有u标志时合法{被当作普通字符因此不应报错RegExp(\\u{0}*, flags)在没有u标志时非法但在u模式下合法同样不应报错。测试用例第 53-65 行明确验证了这两种情况。而当标志位确定时规则直接按对应的unicode/unicodeSets组合校验源码第 235-238 行。边界情况与注意事项规则校验遵循最新 ECMAScript 规范与解析器设置无关原文档明确指出Please note that this rule validates regular expressions per the latest ECMAScript specification, regardless of your parser settings.请注意无论你的解析器设置如何本规则都按照最新的 ECMAScript 规范验证正则表达式。这意味着即使你的项目 parser 配置为较旧的 ECMAScript 版本该规则仍会按最新规范判定模式合法性。例如测试用例中覆盖了ES2020命名捕获组、\p{Script...}属性转义ES2022dhasIndices标志、新 Unicode 属性ES2024vunicodeSets标志、集合差集[A--B]、交集[AB]ES2025重复捕获组名Duplicate capture group name、内联修饰符(?ims:foo)及其各种非法形式如(?ii:foo)报告Duplicated flag i、(?-:foo)报告Invalid empty flags、(?g:foo)报告Invalid group。从测试文件 tests/lib/rules/no-invalid-regexp.js 的用例分组注释可以看到这些 ES 版本演进对应的验证能力。仅校验字符串字面量模式与标志位都必须是字符串字面量才会被校验。例如new RegExp(pattern, g)模式是变量、new RegExp(., y)标志位是变量都不会触发报告——这是合理的设计因为变量值在静态阶段无法确定。但标志位错误检查有个例外当标志位是字符串字面量而模式是变量时标志位仍会被校验见测试用例new RegExp(pattern, az)配合allowConstructorFlags: [a]时报告Invalid flags supplied to RegExp constructor z。标志位检查优先于模式检查从源码执行顺序看第 203-212 行规则先校验标志位一旦发现标志位非法就立即报告并返回不再继续校验模式。因此RegExp() , a)这类代码会先报告Invalid flags supplied to RegExp constructor a而非模式错误。与相关规则的配合docs/src/rules/prefer-named-capture-group.md 和 docs/src/rules/no-useless-backreference.md 的文档中都将no-invalid-regexp列为关联规则说明它常与其他正则相关规则一起构成完整的正则质量检查体系。配置建议与实战小结由于该规则已被标记为recommended: true见 docs/src/_data/rules.json使用eslint:recommended预设的项目无需任何配置即可获得此检查。如果需要自定义配置典型用法如下// eslint.config.js (flat config) export default [ { rules: { no-invalid-regexp: [error, { allowConstructorFlags: [a] }] } } ];// .eslintrc.json (legacy config) { rules: { no-invalid-regexp: [error, { allowConstructorFlags: [a] }] } }需要注意建议保持默认除非你的运行环境确实支持规范之外的自定义标志位否则不要配置allowConstructorFlags以免掩盖真实错误大小写敏感a与A是完全不同的配置项配置时务必与实际使用的标志位一致标准标志位无需列入dgimsuvy中任何一个都不会被当作额外允许的标志它们本身就在默认合法集合内。总而言之no-invalid-regexp把正则构造错误从运行时崩溃提前到静态分析报告配合其基于regexpp的严格按最新 ECMAScript 规范校验的能力是保障 JavaScript 项目中动态正则安全的一道重要防线。【免费下载链接】eslintFind and fix problems in your JavaScript code.项目地址: https://gitcode.com/GitHub_Trending/es/eslint创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
