怎么使用命令行批量格式化项目中的JS文件

在日常项目维护中，批量格式化 JavaScript 文件的核心做法是在项目根目录打开终端，调用代码风格格式化工具（推荐 Prettier）或代码校验工具（ESLint），通过 Glob 路径通配符匹配所有目标 .js 文件，并附加自动重写参数（如 --write 或 --fix）一键完成格式规整。本文将按实际操作流程，完整讲解直接运行命令、工程化配置、过滤规则与常见报错处理。

一、使用 Prettier 命令行快速批量格式化

Prettier 是目前前端生态中最主流、专精于排版风格的代码格式化器。它不检查业务逻辑，而是将 JavaScript 代码解析为抽象语法树（AST），然后按照设定的行宽、缩进和标点规则重新打印整洁代码。

1. 免安装直接执行（适用临时检查与单次清理）

如果本地环境已安装 Node.js（建议 v14+），无需在项目中单独安装 Prettier，直接使用 npx 工具即可一键下载并运行格式化：

# 在项目根目录下执行，递归格式化所有子目录及当前目录的 .js 文件
npx prettier --write "**/*.js"

命令关键参数说明：

• --write（简写 -w）：指示 Prettier 直接修改并覆盖原文件。如果不加该参数，Prettier 默认只会将格式化后的代码直接打印到终端窗口中，不会更改磁盘文件。
• "**/*.js"：Glob 匹配模式，代表匹配当前目录及其任意深度的子目录下的所有以 .js 结尾的文件。

2. 先验证后写入：只检查不覆盖

在不确定代码改动范围前，可以先使用 --check 参数排查项目中哪些文件存在格式问题：

npx prettier --check "**/*.js"

终端示例输出结果：

Checking formatting...
[warn] src/api/request.js
[warn] src/utils/format.js
[warn] Code style issues found in 2 files. Run Prettier with --write to fix.

如果所有文件都已经符合规范，Prettier 会输出 All matched files use Prettier code style!，退出码为 0。

二、工程化标准配置：统一格式化规则与排除范围

为了确保团队内所有成员运行命令行格式化时产生完全一致的结果，不应依赖工具的默认缺省值，而应在项目根目录放置统一的配置文件。

1. 安装项目本地依赖

在项目根目录运行安装命令，将 Prettier 保存至开发依赖中：

npm install --save-dev prettier

2. 创建格式化配置文件 .prettierrc

在项目根目录下新建 .prettierrc（JSON格式），根据团队习惯约定基础排版规则：

{
  "semi": true,
  "singleQuote": true,
  "tabWidth": 2,
  "trailingComma": "es5",
  "printWidth": 80
}

常用规则项含义：

• semi: 语句末尾是否添加分号（true 保留，false 省略）。
• singleQuote: 是否使用单引号替代双引号。
• tabWidth: 每个缩进级别的空格数（通常推荐 2 或 4）。
• trailingComma: 多行对象或数组末尾是否保留逗号（es5 适用于现代 JS 语法）。
• printWidth: 单行代码的最大字符长度，超过此长度将智能折行。

3. 建立忽略清单 .prettierignore

这是命令行批量格式化中最关键的一步。如果不显式排除依赖目录和产物目录，命令行通配符会扫描数以万计的第三方模块，导致格式化耗时极长，甚至直接污染构建包。

在项目根目录新建 .prettierignore 文件：

# 依赖包（绝不能格式化）
node_modules/

# 构建输出目录
dist/
build/
coverage/

# 压缩版或第三方离线库
*.min.js
vendor/

三、使用 ESLint 命令行批量修复与格式化

部分团队没有引入 Prettier，而是仅通过 ESLint 来统领代码规范。ESLint 主要侧重于代码质量检查（如禁用未声明变量、禁止死循环等），但它也具备风格修复能力。

1. 执行 ESLint 批量修复命令

在项目根目录运行带有 --fix 标志的 ESLint 命令，即可自动修正所有支持自动修复的格式与语法规则：

# 使用 ESLint 批量修复 src 目录下所有的 .js 文件
npx eslint "src/**/*.js" --fix

命令工作机制：

• --fix 参数会遍历所有匹配规则，例如缩进（indent）、分号（semi）、引号（quotes）等规则，并在 AST 上直接修正代码，最后将变更写回原文件。
• 对于无法自动推断的代码逻辑问题（如 no-unused-vars 未使用的变量、变量重名等），ESLint 不会强行修改，而是输出终端告警，需要人工干预。

2. 两者的工业化协同方案

现代化前端项目通常将两者分工协作：Prettier 负责代码所有格式排版（缩进、行宽、换行），ESLint 负责代码逻辑与质量守卫（变量未用、类型安全）。

为了避免两者在分号或引号等规则上“打架”，通常会在 ESLint 中安装 eslint-config-prettier，禁用 ESLint 中与格式冲突的所有原生规则，保证各自通过命令行批量执行时互不干扰。

四、将命令行封装进 package.json 脚本

每次在命令行中输入长串参数既繁琐又容易打错文件名，最规范的做法是将批量格式化命令固化为 package.json 中的 npm scripts。

编辑 package.json，在 scripts 字段中增加以下命令：

{
  "scripts": {
    // 批量覆写格式化所有 JS 文件
    "format": "prettier --write \"src/**/*.js\"",
    // CI 自动化测试只做格式校验
    "format:check": "prettier --check \"src/**/*.js\"",
    // ESLint 代码逻辑批量修复
    "lint:fix": "eslint \"src/**/*.js\" --fix"
  }
}

配置完成后，在日常开发中只需在终端中输入简短的指令：

# 执行全项目 JS 批量格式化
npm run format

终端示例输出：

> my-project@1.0.0 format
> prettier --write "src/**/*.js"

src/api/auth.js 45ms
src/components/button.js 28ms
src/index.js 15ms
src/utils/math.js 18ms

终端会清晰逐行列出被处理的文件名以及每一个文件的格式化耗时，最终返回命令提示符，代表所有目标 JS 文件已被原地格式化完成。

五、常见问题与防坑指南

六、总结与工程化演进路径

通过命令行批量格式化 JS 文件是保证项目代码一致性的基础手段。从单次命令到团队成熟自动化体系，通常经历四个演进阶段：

1. 单次按需执行：使用 npx prettier --write "**/*.js" 解决接手遗留项目时的排版混乱。
2. 项目脚本固化：在 package.json 中定义 npm run format，使团队成员使用统一规则。
3. 提交前钩子拦截：结合 husky 与 lint-staged，在执行 git commit 时仅对暂存区的 .js 文件调用命令行格式化，实现增量无感格式化。
4. 持续集成门禁（CI）：在代码仓库合并请求（PR/MR）流程中，运行 npm run format:check，若有未格式化的 JS 代码则直接阻断合并。