Debian中JS代码风格和规范如何制定

Debian下制定JS代码风格与规范的落地方案

在Debian环境下制定一套靠谱的Ja vaScript代码规范，说难不难，但真要落地执行，还是有不少讲究的。今儿就来聊聊这个话题，从环境配置到团队协作，一条龙捋清楚。

一 基础环境准备

先把地基打牢。Node.js和npm的安装方案，Debian上基本就两条路：NodeSource仓库或者nvm。NodeSource能直接拿到较新的稳定版本，比如18.x；而nvm的好处在于多版本切换灵活，项目之间互不干扰。选哪个看团队习惯，但有一条共识——尽可能用新版本，ES6+的特性支持才跟得上。

编辑器这边，VS Code目前是最优选。装上ESLint和Prettier扩展之后，保存时自动格式化、实时报错提醒，体验相当丝滑。别忘了，虽然apt也能直接装prettier和eslint，但前端生态迭代速度快得像翻书，强烈建议通过npm在项目里锁定版本，确保每个人跑出来的结果一模一样，避免“我这没问题啊”的尴尬。

二 规范制定与落地

规整代码风格，核心思路是“分层控制、工具闭环”。

先上EditorConfig，解决不同编辑器之间的基础格式差异——缩进是空格还是Tab、换行符用LF还是CRLF、编码用什么，统一在一个.editorconfig文件里搞定。

格式层面，Prettier是那个“独裁者”。团队里关于缩进几个空格、用单引号还是双引号的争论可以直接打住——让工具来做决定，省下精力写业务。只需要维护一个.prettierrc文件，全局统一。

代码质量这块，ESLint上场。它负责揪出那些Prettier管不了的逻辑问题，比如未使用变量、console滥用、潜在的错误模式。配合.eslintrc配置文件，团队可自定义严格程度。

问题来了：Prettier和ESLint在某些规则上可能打架。解决方案是引入eslint-config-prettier，把ESLint里负责格式的规则关掉；再加一个eslint-plugin-prettier，让Prettier以一种“规则”的形式运行在ESLint里。这样一来，格式交给Prettier，质量交给ESLint，彼此不冲突，协作无间。

最后，在package.json里把脚本固化下来，版本锁定，团队统一执行，CI也能直接复用。

三 推荐配置与示例

直接给配置模板，拿来就能用。

Prettier 示例（.prettierrc）：统一缩进、引号、行宽、尾逗号等基础格式

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

ESLint 示例（.eslintrc.json）：质量和风格并重，并集成Prettier

{
  "extends": [
    "eslint:recommended",
    "plugin:prettier/recommended"
  ],
  "plugins": ["prettier"],
  "env": { "browser": true, "node": true, "es2022": true },
  "parserOptions": { "ecmaVersion": "latest", "sourceType": "module" },
  "rules": {
    "indent": ["error", 2],
    "quotes": ["error", "single"],
    "semi": ["error", "always"],
    "no-console": "warn",
    "prettier/prettier": "error"
  }
}

EditorConfig 示例（.editorconfig）

root = true

[*]
charset = utf-8
end_of_line = lf
indent_style = space
indent_size = 2
trim_trailing_whitespace = true
insert_final_newline = true

[*.md]
trim_trailing_whitespace = false

package.json 脚本示例

{
  "scripts": {
    "lint": "eslint . --ext .js,.jsx,.ts,.tsx",
    "format": "prettier --write .",
    "format:check": "prettier --check .",
    "precommit": "lint-staged"
  },
  "devDependencies": {
    "eslint": "^8",
    "prettier": "^3",
    "eslint-plugin-prettier": "^5",
    "eslint-config-prettier": "^9",
    "lint-staged": "^15",
    "husky": "^9"
  }
}

整个方案的逻辑很清晰：Prettier管格式，ESLint管质量，通过eslint-plugin-prettier和eslint-config-prettier把两者无缝衔接。团队按这个模板走，基本不会出大问题。

四 本地与提交时强制执行

规范定好了，关键是怎么确保每个人都在用，而不是束之高阁。

husky + lint-staged 是经典组合。安装好之后，每次git commit之前，会自动对暂存区的文件跑ESLint和Prettier，不合规的直接拦截，代码根本进不了仓库。

具体操作：npm i -D husky lint-staged，然后npx husky install。别忘了在package.json的prepare脚本里加上"husky install"，这样其他人clone下来跑npm install就能自动启用。

lint-staged的配置也很直观：

{
  "lint-staged": {
    "*.{js,jsx,ts,tsx}": [
      "eslint --fix",
      "prettier --write"
    ]
  }
}

开发者只需要正常git commit，后面的步骤工具自动完成。CI那边再配上npm run lint和npm run format:check做双重保险，不管谁来提交，代码风格都整齐划一。

五 团队规范文档与维护

光有工具还不够，文档得跟上。在仓库根目录维护一份CONTRIBUTING.md或STYLEGUIDE.md，把以下内容写清楚：

• 代码风格与质量工具链（Prettier/ESLint/EditorConfig）、对应版本及脚本入口；
• 命名规范、目录结构设计、注释要求（JSDoc尽量作为标配）；
• 错误处理策略、日志使用规范、依赖管理原则、安全约束；
• 提交信息规范（推荐约定式提交）及CI失败的处理流程。

文档本身也是活的，随着项目演进而更新。再加上CI里的npm audit等安全审计环节，依赖风险也能控制得住。一套完整的规范体系，才算真正落地。