ESLint no-path-concat 规则详解：禁用 `__dirname`/`__filename` 字符串拼接，改用 `path.join()` 与 `path.resolve()`-迪斯科星球

ESLint no-path-concat 规则详解：禁用`dirname`/`filename`字符串拼接，改用`path.join()`与`path.resolve()`

【免费下载链接】eslintFind and fix problems in your JavaScript code.项目地址: https://gitcode.com/GitHub_Trending/es/eslint

本篇技术指南聚焦 ESLint 核心规则no-path-concat，它用于拦截 Node.js 环境中使用__dirname、__filename直接与字符串相加来拼装文件路径的写法，并引导开发者改用path.join()、path.resolve()等跨平台安全的路径 API。通过阅读本文，你将理解该规则的产生背景、判定逻辑、正确/错误代码示例，掌握规则的启用方式与适用边界，并通过源码与测试用例了解其底层实现原理。

为什么需要这条规则：跨平台路径拼接的隐患

在 Node.js 中，全局变量__dirname保存着当前执行脚本所在目录的绝对路径，__filename保存着当前执行脚本的完整文件路径。开发者经常希望基于它们去构造其他文件的路径，例如：

var fullPath = __dirname + "/foo.js";

这种写法存在几个问题：

路径分隔符不可控：Node.js 可以运行在任意操作系统上，包括使用反斜杠\作为路径分隔符的 Windows。直接用字符串拼接并假设 Unix 风格的分隔符/，很容易生成无效路径。
可能出现双分隔符：当__dirname以分隔符结尾时，拼接出来的路径会变成/path/to/dir//foo.js这种包含双分隔符的形式。
难以保证路径正确性：手工拼接无法利用系统相关的路径规则，在边界情况下容易产生语义模糊或彻底无效的路径。

为了避免上述问题，Node.js 提供了内置的path模块。该模块基于运行时的系统信息来计算路径，始终返回符合当前平台规则的正确结果。因此，前面的示例可以改写为：

var fullPath = path.join(__dirname, "foo.js");

这段代码无需手工包含分隔符，path.join()会以最合适的方式自动完成拼接。你也可以使用path.resolve()获取完全限定的绝对路径：

var fullPath = path.resolve(__dirname, "foo.js");

无论是path.join()还是path.resolve()，在创建文件或目录路径时都是字符串拼接的合适替代方案。

Rule Details：规则如何工作

no-path-concat的目标是阻止在 Node.js 中通过字符串拼接来构造目录路径。该规则是 ESLint 核心规则之一，从规则版本数据可以看到它自 ESLint 0.4.0 起便已存在。

规则的错误（incorrect）代码示例

/*eslint no-path-concat: "error"*/ var fullPath = __dirname + "/foo.js"; var fullPath = __filename + "/foo.js";

以上代码中，__dirname与__filename出现在+表达式的任意一侧，都会触发规则报告。

规则的正确（correct）代码示例

/*eslint no-path-concat: "error"*/ var fullPath = dirname + "/foo.js";

这里拼接的dirname只是普通的标识符变量，并不是 Node.js 的全局变量，因此不会被规则报告。规则只针对__dirname与__filename这两个特殊标识符。

源码级实现原理

规则的核心实现位于 lib/rules/no-path-concat.js，其判定逻辑非常简洁：

通过正则MATCHER = /^__(?:dir|file)name$/u精确匹配__dirname或__filename标识符；
注册BinaryExpression访问器，当节点的operator为+，且左操作数或右操作数中存在类型为Identifier且名字命中上述正则的标识符时，调用context.report()报告问题；
报告时使用messageId: "usePathFunctions"，对应消息文本为"Use path.join() or path.resolve() instead of + to create paths."。

从实现细节可以看出：规则只针对二元+表达式，因此使用==、===等运算符比较__dirname不会被报告；变量出现在+的哪一侧都会被检测（测试用例覆盖了"/foo.js" + __filename、"/foo.js" + __dirname这类左侧为字符串字面量的情况）；__dirname与__filename都会命中同一个正则，共享同一条报告消息。

该规则在 lib/rules/index.js 中通过懒加载方式注册：

"no-path-concat": () => require("./no-path-concat"),

规则的元数据定义（位于 lib/rules/no-path-concat.js 的meta字段，同步维护于 docs/src/_data/rules_meta.json）还包括：

type:"suggestion"：表明这是一条建议型规则，不涉及强制性的代码风格，主要用于提示潜在问题；
recommended:false：该规则未包含在eslint:recommended推荐配置中，需要开发者显式开启；
schema:[]：规则不接受任何配置选项，启用后即按默认逻辑工作。

测试用例验证

规则的完整测试位于 tests/lib/rules/no-path-concat.js，使用RuleTester驱动，包含 4 个有效（valid）用例与 4 个无效（invalid）用例：

有效用例（不触发报告）：

var fullPath = dirname + "foo.js"; // 普通标识符，非 __dirname var fullPath = __dirname == "foo.js"; // 非 + 运算符 if (fullPath === __dirname) {} // 比较运算 if (__dirname === fullPath) {} // __dirname 在左侧的比较运算

无效用例（触发usePathFunctions报告）：

var fullPath = __dirname + "/foo.js"; // __dirname 在左侧 var fullPath = __filename + "/foo.js"; // __filename 在左侧 var fullPath = "/foo.js" + __filename; // __filename 在右侧 var fullPath = "/foo.js" + __dirname; // __dirname 在右侧

这些用例精确印证了源码中的匹配逻辑：只有Identifier且名字为__dirname/__filename参与+运算时才被报告，无论其位于表达式的哪一侧。

如何启用该规则

由于该规则不在eslint:recommended中，需要显式配置。在 flat config（eslint.config.js）中：

export default [ { rules: { "no-path-concat": "error" // 或 "warn" } } ];

在传统的.eslintrc风格配置中：

{ "rules": { "no-path-concat": "error" } }

规则没有可配置选项，因此不存在"off"、"warn"、"error"之外的第三档参数。

注意事项：规则的废弃状态

需要特别说明的是，该规则已被标记为废弃。从 lib/rules/no-path-concat.js 的meta.deprecated字段可以看到：

deprecatedSince:"7.0.0"：自 ESLint 7.0.0 起废弃，原因是 Node.js 相关规则被移出 ESLint 核心；
availableUntil:"11.0.0"：该规则在核心中保留可用至 ESLint 11.0.0；
replacedBy：废弃后由社区维护的eslint-plugin-n插件继续维护同名的no-path-concat规则。

因此，如果你正在使用 ESLint 7.0.0 及以上的版本，官方推荐安装eslint-plugin-n插件来获得该规则的持续维护；在核心版本中该规则仍然可用，但未来版本将移除。

When Not To Use It：何时应该关闭此规则

如果你希望允许对路径名进行字符串拼接（例如项目明确只运行在单一平台、且能保证分隔符正确），可以选择关闭该规则：

{ "rules": { "no-path-concat": "off" } }

但考虑到path.join()与path.resolve()不仅能解决跨平台问题，还能自动处理分隔符、相对路径归一化等细节，通常建议保留该规则，除非你有明确且充分的理由。

企业官网建设流程全解析