从 Prettier 开始整理前端开发常用命令

从 Prettier 开始整理前端开发常用命令

最近写 React 页面时，我遇到一个很具体的问题：CSS 虽然能正常显示，但代码挤在长行里，继续修改和检查都很费劲。

这种情况可以交给 Prettier。再往下想一步，格式化、检查类型、构建、查看改动，其实都是每天会重复做的事。把它们整理成项目里的固定命令，新项目能直接复用，隔一段时间回来开发也容易找回节奏。

这篇文章以 React + TypeScript + Vite + npm 为例，整理一套日常开发常用命令。Vue 项目也能参考格式化、Git 和 npm 部分，类型检查则应使用项目对应的工具，例如 vue-tsc。

一 先收藏这张命令表

下面的 format、lint:fix、typecheck、check 是本文会配置的脚本，需要先添加到 package.json 才能运行 。dev、build、preview 也以项目实际脚本为准。

场景	命令	日常使用频率
看项目有哪些脚本	npm run	接手项目时很常用
启动开发服务	npm run dev	每次开发
统一代码格式	npm run format	经常使用
检查代码规则	npm run lint	提交前
自动修复可修复的规则问题	npm run lint:fix	检查报错时
检查 TypeScript	npm run typecheck	改接口和类型后
生成构建产物	npm run build	交付和部署前
本地预览构建产物	npm run preview	构建后
执行整套项目检查	npm run check	提交前
看改了哪些文件	git status --short	提交前必看
看具体改动	git diff	提交前必看
搜索调用位置	rg "关键词" src	排查和重构时

命令不需要一次背完。先让项目提供统一入口，日常使用几次就会记住。

二 用 Prettier 一键整理代码

安装到当前项目

在包含 package.json 的项目根目录执行：

npm install --save-dev --save-exact prettier

把版本锁定在项目里，团队成员和 CI 才容易使用同一版本，避免升级导致格式来回变化。安装之后再用 npx，会优先执行项目本地工具。参考 Prettier 安装文档。

先解决眼前的 CSS 问题

只格式化一个文件：

npx prettier --write src/App.css

格式化所有源码 CSS：

npx prettier --write "src/**/*.css"

通配路径用引号包起来，让 Prettier 自己处理匹配，便于在不同系统的终端中使用。--write 会直接写回文件；如果只想检查，改用 --check。参考 Prettier CLI。

比如原来的代码：

.card{padding:20px;background:#fff;border-radius:12px}.card h2{margin:0;color:#333}

整理后会变成：

.card {
  padding: 20px;
  background: #fff;
  border-radius: 12px;
}

.card h2 {
  margin: 0;
  color: #333;
}

这解决的是代码可读性。字号、间距、响应式布局是否合适，仍需要查看页面效果。

配置团队统一格式

在项目根目录创建 .prettierrc.json：

{
  "singleQuote": true,
  "semi": false,
  "tabWidth": 2,
  "printWidth": 100
}

这里设置了单引号偏好、JavaScript 分号风格、缩进和换行宽度。其中 printWidth 是排版参考值，并不是所有行都必须满足的硬性长度限制。按团队已有约定调整即可，参考 Prettier 配置项。

再创建 .prettierignore：

node_modules/
dist/
coverage/
*.tsbuildinfo
package-lock.json

依赖、构建产物和工具生成文件应交给相应工具管理。这里主动排除了 npm 锁文件；它仍应正常提交到 Git。Prettier 支持通过忽略文件控制处理范围，参考 忽略文件说明。

三 区分格式化 规则检查和类型检查

这三个工具经常一起使用，但解决的问题不同。

工具	主要职责	例子
Prettier	统一代码排版	缩进、换行、空格
ESLint	检查配置中启用的代码规则	未使用变量、React Hooks 规则
TypeScript	检查静态类型	把字符串传给只接受数字的参数

ESLint 检查与修复

React/Vite 模板通常已经提供 ESLint 配置。已有配置时可以执行：

npx eslint .
npx eslint . --fix

--fix 只能自动处理规则支持修复的问题。没有自动修复能力的报错仍需要修改代码。参考 ESLint 命令行文档。

如果项目没有配置 ESLint，先完成配置再执行；安装一个包并不会自动生成适合业务的规则。

TypeScript 检查要对应项目结构

普通单项目可以使用：

npx tsc --noEmit

Vite 的 React/TypeScript 模板常把配置拆成 tsconfig.app.json、tsconfig.node.json，并由根配置引用。这种结构可以沿用模板的：

npx tsc -b

-b 会处理项目引用和依赖；是否输出文件由各个配置决定。如果这些配置已有 noEmit: true，就不会生成 JavaScript 文件。不要把两种命令不加区分地互换，参考 TypeScript CLI。

四 把常用操作写进 package.json

安装 Prettier，并确认项目已经具有 React/Vite、TypeScript 和 ESLint 配置后，可以合并下面的 scripts：

{
  "scripts": {
    "dev": "vite",
    "format": "prettier --write .",
    "format:check": "prettier --check .",
    "lint": "eslint .",
    "lint:fix": "eslint . --fix",
    "typecheck": "tsc -b",
    "build": "npm run typecheck && vite build",
    "preview": "vite preview",
    "fix": "npm run lint:fix && npm run format",
    "check": "npm run format:check && npm run lint && npm run build"
  }
}

这是脚本配置示例，不是完整的 package.json。合并时保留已有的依赖、测试和业务脚本。

以后只需要记住：

npm run format
npm run fix
npm run check

fix 会修改代码；check 中的格式和规则检查不会自动修复文件，最后会生成构建产物。脚本里的 && 让后一步只在前一步成功时执行，适合本地检查和 CI。

另外有两个常见坑：

• scripts 与 dependencies 是同级字段，不能写进依赖对象里。
• 已有 build 如果还包含资源内联、代码生成或产物同步，保留这些步骤。不要为了套用示例覆盖项目原有构建流程。

如果已经配置测试，可以把 npm test 加入 check。只有项目提供了测试脚本，这条命令才有相应作用。

五 开发服务 构建和预览分别做什么

npm run dev

启动开发服务，适合边写边看页面。

npm run build
npm run preview

先生成构建产物，再预览这份产物。只启动 preview 不会自动替你构建，页面可能仍来自上一次构建。

Vite 的 preview 用于本地检查构建结果，不应作为生产服务器使用，参考 Vite 静态部署文档。

需要传参数时，可以写：

npm run dev -- --port 5174

这里 -- 后面的参数会传给脚本里的 Vite 命令。项目脚本是操作入口，真正执行行为的是脚本指定的工具。

六 提交之前先查看改动

很多问题可以在提交前发现：格式化改了大量无关文件，构建产物被误加入，或者配置文件里的一个字段写错了位置。

我会先执行：

git status --short
git diff --stat
git diff

status 看文件状态，--stat 看变更规模，diff 看尚未暂存的具体修改。

再检查空白问题：

git diff --check

它可以发现部分空白错误和冲突标记，但不能替代格式化、类型检查或测试。文件已经暂存时，使用：

git diff --cached
git diff --cached --check

两者查看的是准备提交的内容。参考 Git diff 文档。

确认后，再暂存明确需要提交的文件，例如：

git add src/App.tsx src/App.css
git diff --cached
git commit -m "feat: add todo filters"

暂存范围以实际修改为准。第一次全量格式化最好单独提交，业务功能也单独提交，后续看 diff 和回退都更清楚。

七 用搜索命令快速定位代码

项目变大后，比起打开文件逐个查找，终端搜索通常更快。

安装 ripgrep 后，可以执行：

rg "showToast" src
rg -n "TODO|FIXME" src
rg -F "system.storage.setItem" src
rg --files src

分别用于搜索调用、列出带行号的待办标记、按字面文本查找，以及列出源码文件。ripgrep 默认会参考忽略规则，参考 ripgrep 项目说明。

没有安装 rg 时，编辑器全局搜索也够用。工具的目的，是迅速找到要改的位置。

八 把格式化交给编辑器保存动作

如果使用 VS Code，可以安装 Prettier 扩展，在项目的 .vscode/settings.json 中添加：

{
  "editor.defaultFormatter": "esbenp.prettier-vscode",
  "editor.formatOnSave": true
}

已有设置时合并字段；如果不同语言使用不同格式化工具，可以按语言设置 formatter。

Windows/Linux 的默认"格式化文档"快捷键是 Shift + Alt + F，也可以在命令面板搜索"Format Document"。键位可能被个人配置修改，格式化也需要当前文件有可用的 formatter。参考 VS Code 编辑与格式化说明。

保存格式化适合个人开发，npm run format:check 则适合提交前和 CI；两者使用项目里的统一配置。

九 安装依赖和脚本报错时怎么处理

npm install 与 npm ci

日常新增依赖通常使用 npm install，例如前面安装 Prettier。

项目有 package-lock.json 时，CI 或需要按锁文件重新安装完整依赖的环境可以执行：

npm ci

npm ci 要求锁文件与 package.json 一致；不一致会失败，也不会替你更新锁文件。它会重新安装依赖，已有 node_modules 会先移除，因此不需要额外手动清理。参考 npm ci 文档。

不要把删除锁文件当作通用修复手段，否则依赖解析结果可能变化。

Missing script

遇到类似 Missing script: format，先看当前项目提供什么：

npm run

然后确认当前目录、脚本名称，以及 package.json 中的字段层级。

Windows PowerShell 执行 npm 受阻

如果终端报错指出 npm.ps1 被执行策略阻止，可以先调用同一套 npm 的命令入口：

npm.cmd run format
npx.cmd prettier --write "src/**/*.css"

这不需要先修改系统执行策略。如果错误原因是脚本不存在、依赖未安装或语法错误，应处理对应问题。

十 在 React 和鸿蒙宿主之间复用命令

对于需要把 React 页面装进鸿蒙 Web 容器的项目，还可以把产物同步封装成脚本。例如我的 React Todo 项目提供：

npm run build
npm run sync:harmony -- "C:\你的目录\MyApplication4"

这里的 sync:harmony 是项目自定义脚本，需要在仓库中实现并配置。它把构建产物复制到鸿蒙宿主的 rawfile/web，之后仍要在 DevEco 构建并运行应用。

日常流程因此变成：修改 React 源码 → 格式化和检查 → 构建 React → 同步资源 → 构建并运行鸿蒙应用。

不同工程有不同后续步骤，把它们写成可读的脚本名称，比每次重新翻找一长串命令更方便。

提交前的固定流程

项目按本文配置后，可以使用下面这套顺序：

npm run fix
npm run check
git status --short
git diff
git diff --check

如果自动修复留下错误，就先修复并重新检查；确认通过后，再暂存和查看准备提交的内容。

这些命令能把重复操作变成固定流程。格式统一之后，继续把注意力放在页面效果、功能行为和异常处理上。