ESLint 已移除规则剖析space-unary-word-ops 及其继任者 space-unary-ops 迁移指南【免费下载链接】eslintFind and fix problems in your JavaScript code.项目地址: https://gitcode.com/GitHub_Trending/es/eslint导读space-unary-word-ops是 ESLint 早期版本中用于强制一元单词运算符unary word operator后必须跟空格的排版类规则但它在 ESLint v0.10.0 中即被移除由功能更完整的 space-unary-ops 规则取代。本文以 space-unary-word-ops 官方文档 为骨架完整还原该规则的检查目标、正误示例并深入讲解继任规则的三个配置项words、nonwords、overrides与底层实现帮助你理解为何typeof!a属于风格错误、void 0才是推荐写法以及如何完成从旧规则到新规则的平滑迁移。规则背景为什么它被移除space-unary-word-ops的历史定位非常明确强制一元单词运算符之后必须有一个空格。所谓一元单词运算符指的是用英文单词表示的运算符包括new构造实例delete删除属性typeof类型判断void求值但不返回结果规则的原始描述为 Requires spaces after unary word operators即只关心单词运算符之后这一侧的空格覆盖面较窄。由于后来出现的space-unary-ops规则在功能上完全覆盖并超越它同时管理单词运算符与符号运算符、支持words/nonwords/overrides三个选项ESLint 官方在v0.10.0将其移除并在文档中以:::important提示块明确标注This rule was removed in ESLint v0.10.0 and replaced by the space-unary-ops rule.仓库中的迁移数据同样印证了这一替代关系在 conf/replacements.json 中space-unary-word-ops被映射为[space-unary-ops]在 conf/rule-type-list.json 的已移除规则列表中space-unary-word-ops的replacedBy同样指向space-unary-ops。这意味着 ESLint 在检测到旧规则名时会自动给出使用新规则名的迁移提示用户无需手动记忆映射关系。原始规则的检查目标space-unary-word-ops的核心诉求是消除运算符与操作数之间没有空格的可读性隐患。当单词运算符与紧跟其后的表达式粘连在一起时代码很难一眼读懂甚至可能产生歧义。不符合规则incorrect的代码以下四组示例展示了规则报错的情形typeof!atypeof与!a之间没有空格语义上等价于typeof (!a)但视觉上极易与typeof 作用于!混淆。void{a:0}void与对象字面量{a:0}粘连正确写法应为void {a:0}。new[a][0]new与数组下标表达式粘连正确写法应为new [a][0]。delete(a.b)delete与括号表达式粘连。注意这里的情况比较特殊delete (a.b)才是可接受的写法而完全不加空格直接写成delete(a.b)会被视为风格错误。符合规则correct的代码delete a.bdelete后跟空格。值得注意的是这种写法中空格在语法上是强制要求的delete与成员表达式之间不能省略空格因此它天然符合规则。new Cnew与构造函数名C之间有空格符合规则。void 0void后跟空格作用于字面量0这是业界标准的写法。从这组正误对比可以看出原始规则本质上只做了一件事在单词运算符与其操作数之间强制保留一个空格。而这一规则在后续演进中被space-unary-ops以更细粒度、更可配置的方式继承了下来。继任规则 space-unary-ops功能全解析继任规则 space-unary-ops 文档 将问题域扩展为一元运算符两侧的空格一致性This rule enforces consistency regarding the spaces afterwordsunary operators and after/beforenonwordsunary operators.它将一元运算符划分为两类单词运算符wordsnew、delete、typeof、void、yield// new var joe new Person(); // delete var obj { foo: bar }; delete obj.foo; // typeof typeof {} // object // void void 0 // undefined符号运算符nonwords-、、--、、!、!!if ([1,2,3].indexOf(1) ! -1) {}; foo --foo; bar bar; baz !foo; qux !!baz;一个关键细节是对于words运算符规则只在不加空格会导致语法歧义的场景生效。例如delete obj.foo中的空格是语法强制的规则不介入而delete(obj.foo)中的空格是可选的delete (obj.foo)与delete(obj.foo)均可解析此时规则才会生效。三个配置选项规则接收一个对象类型的选项默认值为{ words: true, nonwords: false }选项类型默认值作用wordsbooleantrue是否要求new、delete、typeof、void、yield等单词运算符之后有空格nonwordsbooleanfalse是否要求-、、--、、!、!!等符号运算符之后/之前有空格overridesobject{}针对单个运算符覆盖上述全局设置value 为 booleanoverrides的典型用法如下space-unary-ops: [ 2, { words: true, nonwords: false, overrides: { new: false, : true } } ]在该配置下全局策略是单词运算符后要空格、符号运算符不要空格但通过overrides做了两处例外new之后禁止空格覆盖words: true前后要求空格覆盖nonwords: false。默认选项下的正误示例不符合规则incorrect/*eslint space-unary-ops: error*/ typeof!foo; void{foo:0}; new[foo][0]; delete(foo.bar); foo; foo --; - foo; 3;/*eslint space-unary-ops: error*/ function *foo() { yield(0) }/*eslint space-unary-ops: error*/ async function foo() { await(bar); }注意继任规则还额外覆盖了yield与await两个单词运算符这是原始space-unary-word-ops所不具备的能力——yield(0)、await(bar)在默认配置下同样会被标记为错误。符合规则correct/*eslint space-unary-ops: error*/ // Word unary operator typeof is followed by a whitespace. typeof !foo; // Word unary operator void is followed by a whitespace. void {foo:0}; // Word unary operator new is followed by a whitespace. new [foo][0]; // Word unary operator delete is followed by a whitespace. delete (foo.bar); // Unary operator is not followed by whitespace. foo; // Unary operator -- is not preceded by whitespace. foo--; // Unary operator - is not followed by whitespace. -foo; // Unary operator is not followed by whitespace. 3;/*eslint space-unary-ops: error*/ function *foo() { yield (0) }/*eslint space-unary-ops: error*/ async function foo() { await (bar); }源码级原理space-unary-ops 是如何实现的从源码结构看继任规则实现在 lib/rules/space-unary-ops.js其meta元数据与检查逻辑共同支撑了上述行为规则类型与可修复性type: layout并声明fixable: whitespace即所有违规都可以通过--fix自动修复在单词后插入空格或删除多余空格。修复器通过fixer.insertTextAfter/fixer.removeRange对 token 之间的空白区域做精确操作。选项默认值源码中const options context.options[0] || { words: true, nonwords: false };与文档声明的默认值完全一致。单词运算符检查逻辑checkUnaryWordOperatorForSpaces会根据是否存在overrides覆盖项决定调用verifyWordHasSpaces要求有空格还是verifyWordDoesntHaveSpaces要求无空格当没有覆盖项时退回到options.words的全局设置。符号运算符检查逻辑checkForSpaces会区分前缀/后缀场景如foo与foo对NewExpression还会额外判断firstToken.type Keyword将new当作单词运算符处理。特殊边界情况isFirstBangInBangBangExpression专门识别!!双重取反表达式——当nonwords: true时第一个!与第二个!之间不要求空格避免误伤!!baz这类常见写法。监听节点范围规则在UnaryExpression、UpdateExpression、NewExpression、YieldExpression、AwaitExpression五类 AST 节点上触发检查覆盖了文档中列出的全部运算符场景。此外从 lib/rules/space-unary-ops.js 的meta.deprecated信息可以看到space-unary-ops自身在 ESLint v8.53.0 起也已标记为废弃格式化类规则逐步移出 ESLint 核心由stylistic/eslint-plugin维护availableUntil: 11.0.0。这意味着如果你在使用较新的 ESLint 版本应优先考虑迁移到 ESLint Stylistic 插件中的同名规则以保证后续版本升级不受影响。迁移指南从旧配置到新配置若你的项目配置文件中仍在使用space-unary-word-ops请按以下步骤迁移替换规则名将space-unary-word-ops: 2改为space-unary-ops: error或2替换关系见 conf/replacements.json。理解行为差异旧规则只强制单词运算符后有空格等价于新规则默认配置中的words: true部分新规则还额外检查符号运算符与yield/await默认nonwords: false表示符号运算符两侧不允许空格如foo、foo--、-foo与旧规则并不冲突。按需补充选项如果你需要保留旧规则只关注单词运算符的宽松度可以显式配置{ words: true, nonwords: false }如需更细粒度控制使用overrides逐运算符覆盖。利用自动修复由于新规则fixable: whitespace运行eslint . --fix即可自动规范化一元运算符周围的空白无需手工逐一修改。关注二次迁移若 ESLint 版本 ≥ v8.53.0请同时留意规则废弃告警将space-unary-ops迁移至stylistic/eslint-plugin的对应规则以匹配 ESLint 核心格式化规则外迁的整体演进方向。总结space-unary-word-ops作为 ESLint 早期的一元运算符空格规则确立了typeof、void、new、delete等单词运算符后必须有空格的代码风格基线并在 v0.10.0 被功能更全面的space-unary-ops取代。理解这段演进历史有助于你读懂旧项目的配置遗产也能更准确地使用words、nonwords、overrides三个选项约束一元运算符的排版最终写出可读性更强、风格一致的 JavaScript 代码。【免费下载链接】eslintFind and fix problems in your JavaScript code.项目地址: https://gitcode.com/GitHub_Trending/es/eslint创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考