OxcFmt 与 OxcLint 使用指南
前言
前端工程里,eslint + prettier 是常见组合,但在大仓库下执行速度和一致性成本一直是团队关注点。oxc 提供了以性能为导向的工具链,其中 OxcFmt 负责代码格式化,OxcLint 负责规则检查。
从 oxc 官方 benchmark 口径看,Oxlint 相比 ESLint 约快 50x-100x,Oxfmt 相比 Prettier 约快 35x。
它最明显的优势就是速度,在大仓库和高频改动场景下能显著缩短格式化与规则检查的等待时间。
对需要频繁本地校验的团队来说,更快的反馈意味着更短的提交回路和更高的开发效率。
这篇文章聚焦一个可直接落地的最小流程。
你会完成本地安装、命令验证与 npm scripts 集成。
安装
先在项目里安装 OxcFmt 与 OxcLint 命令行工具。
下面命令通过 npm 安装开发依赖,适合大多数 JavaScript/TypeScript 项目。
1 | npm install -D oxfmt |
如果你希望在本机任意目录直接使用命令,也可以选择全局安装。
下面脚本更适合个人环境快速体验,团队协作场景仍建议优先使用项目本地依赖。
1 | npm install -g oxfmt |
安装完成后,先确认本地工具可用。
下面命令会输出版本信息,确保命令已正确安装。
1 | npx oxfmt --version |
VS Code 配置
如果你希望在 VS Code 里按保存自动格式化,可以把默认格式化器切到 Oxc 扩展。
先在扩展市场安装 Oxc,扩展标识是 oxc.oxc-vscode。
下面配置会把全局默认格式化器设为 OxcFmt,并在保存时自动执行格式化。
1 | { |
如果你只想让 JavaScript/TypeScript 使用 OxcFmt,建议改为按语言设置,避免影响其他语言。
下面示例只对前端常见四种文件类型生效。
1 | { |
如果项目里同时安装了 Prettier,请确保它没有被设为同语言的默认格式化器。
推荐职责划分是 OxcFmt 负责格式,OxcLint 负责规则检查。
Scripts
把常用命令统一收敛到 package.json 的 scripts,可以降低团队使用门槛。
下面示例把“检查”和“自动修复”拆成两个清晰入口。
1 | { |
如果你的仓库是多包结构,建议把命令中的 . 改成具体目录。
例如 src、packages/*/src 等路径可以减少无关扫描。
另外要注意,Oxfmt 只会格式化它当前支持的语言和文件类型,不会处理所有文件。
如果仓库里同时包含 markdown、yaml、后端代码等内容,建议按目录拆分脚本,避免把不相关文件放进同一次格式化流程。
按 oxc 官方文档,Oxfmt 当前支持的格式可以按类型分组如下。
- 脚本与类型:
javascript、jsx、typescript、tsx - 数据与配置:
json、jsonc、json5、yaml、toml - 样式:
css、scss、less - 标记与内容:
html、markdown、mdx、graphql - 模板与框架:
angular、vue、ember、handlebars
验证
建议按下面顺序做一次端到端验证,确认本地行为稳定可复现。
- 新建一个故意格式错误的文件并运行
npm run format:check,确认命令失败。 - 运行
npm run format后再次执行npm run format:check,确认命令通过。 - 新增一个会触发规则告警的片段并运行
npm run lint,确认有清晰报错。 - 在可自动修复的场景下运行
npm run lint:fix,再次执行npm run lint确认问题消失。 - 把这套命令接入日常提交流程,确保每次改动都经过同一套检查。
总结
OxcFmt 与 OxcLint 的组合可以覆盖“格式统一 + 规则校验”这条最常见的前端质量链路。
建议把本地默认入口固定为 npm run check,让团队始终使用同一套检查命令。
只要入口一致,团队排查问题和迁移旧仓库都会更顺滑。