企业官网建设流程全解析

• 前端
• 构建工具

本文基于 PurgeCSS 仓库的 CONTRIBUTING.md 编写，面向希望为这个 "Remove unused CSS" 开源项目贡献代码的开发者。你将掌握仓库的贡献规范（SemVer、Code of Conduct）、Pull Request 提交清单，以及build、lint、test等完整开发工作流命令，并了解其背后 monorepo（Lerna + npm workspaces）与 Jest 测试体系的实际运作方式。

贡献前须知：行为准则与版本规范

PurgeCSS 采用 Contributor Covenant（贡献者公约）作为所有子项目的行为准则，任何形式的贡献（代码、Issue、文档、评论）都需遵守这一约定。项目维护方（FullHuman）希望贡献者先阅读准则全文，理解在参与本项目时应有的沟通与合作方式。

在版本管理上，PurgeCSS 严格遵循 SemVer（语义化版本） 规范。这从仓库的 lerna.json 中可以直接看到：当前仓库版本为7.0.2，由 Lerna 统一管理多包版本。这意味着：

• 修复 bug 的改动发布patch版本（如7.0.2→7.0.3）；
• 向后兼容的新功能发布minor版本（如7.0.1→7.1.0）；
• 不兼容的 API 变更才发布major版本（如6.x→7.0）。

对你的贡献来说，理解这一点意味着：如果改动改变了公开 API（例如修改PurgeCSS类的构造参数或purge()方法的返回值），会被视为 major 级变更，需要更谨慎的评审。

提交 Pull Request 前的检查清单

CONTRIBUTING.md 明确列出了提交 PR 之前必须完成的四项准备工作：

1. Fork 仓库并从main分支创建你的特性分支——不要直接在main上开发，也不要在自己的分支上堆积无关改动；
2. 如果新增了应被测试的代码，请添加对应测试——贡献指南要求 PR 必须包含针对任何新功能的单元测试，以确保未来不会在不知情的情况下破坏你的代码；
3. 如果改变了 API，请同步更新文档——PurgeCSS 的文档位于 docs 目录（VuePress 站点），API 变更需要同步更新对应指南；
4. 确保测试套件全部通过（npm test），并保证代码通过 lint 检查（npm run lint）。

这一检查清单的核心目的是可维护性：测试保证功能不被回归破坏，文档保证使用者不会因 API 变化而困惑，lint 保证代码风格统一。

开发环境搭建：克隆与依赖安装

按照原文档说明，克隆仓库后需要先执行：

npm i && npm run bootstrap

需要说明的是：在当前仓库状态中，根目录 package.json 的scripts里并未定义bootstrap脚本，因为该仓库采用 npm workspaces（"workspaces": ["packages/*"]），依赖安装由 npm 自动处理packages/下所有子包，因此实际上npm i即可完成全部依赖安装。仓库是只读镜像，如果你要实际开发，请从上游 fork 并 clone 后操作。

从 package.json 可以看到仓库的完整工具链：

• Lerna + npm workspaces：管理packages/下的 11 个子包（purgecss、purgecss-from-html、gulp-purgecss、postcss-purgecss、purgecss-webpack-plugin、rollup-plugin-purgecss等），根目录的build、test脚本均通过lerna run分发到各子包；
• Jest + ts-jest：统一的测试框架（见 jest.config.ts，testMatch匹配__tests__/**/*test.ts，覆盖packages/purgecss/__tests__/下大量.test.ts文件）；
• ESLint + @typescript-eslint：代码风格检查（见 eslint.config.mjs）；
• Husky：通过根目录"prepare": "husky || true"在安装时启用 Git hooks。

开发工作流常用命令详解

CONTRIBUTING.md 给出了 5 条核心命令，下面结合仓库配置逐一说明其实际行为。

npm run build：构建 CJS 与 ES Module

该命令会构建所有PurgeCSS 子包，将 TypeScript 源码编译为 CommonJS（CJS）与 ES Module（ESM）两种格式，产物输出到各包的lib目录。以核心包 packages/purgecss/package.json 为例：

• "main": "lib/purgecss.js"——CJS 入口，供 Node.js 的require()使用；
• "module": "./lib/purgecss.esm.js"——ESM 入口，供打包工具做 tree-shaking；
• "types": "./lib/purgecss.d.ts"——TypeScript 类型声明。

各子包的构建脚本均为"build": "ts-node build.ts"，也就是说构建逻辑写在每个包根目录的build.ts文件中，由ts-node直接执行。任何对src/下源码的改动，都必须重新构建才能在lib/中生效。

npm run lint：代码风格检查

该命令由根目录 package.json 定义为eslint . --fix --ignore-pattern **/lib/** --ignore-pattern **/bin/**。注意两个细节：

• 使用--fix自动修复可修复的格式问题；
• 明确忽略lib（构建产物）与bin（CLI 可执行文件）目录，它们不应被 lint。

从 eslint.config.mjs 可以看到规则配置：基于eslint:recommended与@typescript-eslint/recommended，并启用了eslint-plugin-tsdoc对 TSDoc 注释语法做告警级检查（"tsdoc/syntax": "warn"），这要求为公共 API 编写符合 TSDoc 规范的注释。仓库还使用 Prettier（"prettier": "prettier --write --parser typescript '**/*.ts'"）统一格式化。

npm test：运行完整测试套件

该命令通过lerna run test递归运行所有子包的 Jest 测试。以核心包 packages/purgecss/jest.config.ts 为例，它调用根目录 jest.config.ts 中的createConfig工厂函数生成配置，统一使用ts-jest预置，并做了模块映射（如purgecss-from-html指向其src目录）。

测试用例集中在各包的__tests__目录，例如 packages/purgecss/tests/index.test.ts 覆盖了配置文件的加载、未使用选择器的过滤、自定义 extractor 处理特殊字符、缺失 content 文件时的告警等场景。测试辅助工具定义在 packages/purgecss/tests/utils.ts，其中findInCSS/notFindInCSS用于断言 CSS 中某个选择器应存在/应被移除。

npm test -- --watch：交互式测试监听

以 watch 模式运行 Jest，当你修改源码或测试文件时自动重新执行相关测试，适合开发迭代过程中使用。

npm test <pattern>：按文件名模式过滤测试

例如npm test safelist只运行文件名匹配safelist的测试文件，对应仓库中的 packages/purgecss/tests/safelist.test.ts 等按功能拆分的测试文件（还包括keyframes.test.ts、media-queries.test.ts、pseudo-class.test.ts、comments.test.ts、rejectedCss.test.ts、sourcemap.test.ts等）。

测试的编写要求与参考范式

贡献指南明确要求：PR 必须包含针对任何新功能的单元测试，这样才能保证未来重构时不会静默破坏已有行为。PurgeCSS 的测试范式非常清晰，以 packages/purgecss/tests/index.test.ts 为例：

describe("filters out unused selectors", () => { let purgedCSS: string; beforeAll(async () => { const resultsPurge = await new PurgeCSS().purge({ content: [`${ROOT_TEST_EXAMPLES}others/remove_unused.js`], css: [`${ROOT_TEST_EXAMPLES}others/remove_unused.css`], }); purgedCSS = resultsPurge[0].css; }); it("contains .used-class", () => { expect(purgedCSS.includes(".used-class")).toBe(true); }); it("removes .unused-class", () => { expect(purgedCSS.includes(".unused-class")).toBe(false); }); });

基本模式是：在beforeAll中调用new PurgeCSS().purge({...})得到清理后的 CSS，再用断言验证“使用的选择器被保留、未使用的选择器被移除”。配套的测试夹具存放在各包的__tests__/test_examples/与fixtures/目录中（如assets/tailwind.css、safelist/、keyframes/等），新增测试时通常需要同步提供对应的.css与.html/.js输入样例，以及expected/下的期望输出。

如果你想快速验证某个行为（例如 safelist 或 keyframes 的处理逻辑），可以在packages/purgecss目录下执行npm test safelist或npm test keyframes只跑相关文件，而不必运行全部 11 个子包的测试。

多包架构对贡献的影响

理解仓库的 monorepo 结构有助于写出符合预期的 PR。packages/下除核心 packages/purgecss 外，还包括各类集成与插件包：

• 内容提取器：packages/purgecss-from-html、packages/purgecss-from-jsx、packages/purgecss-from-tsx、packages/purgecss-from-pug；
• 构建工具集成：packages/purgecss-webpack-plugin、packages/rollup-plugin-purgecss、packages/postcss-purgecss、packages/gulp-purgecss、packages/grunt-purgecss。

如果你的改动影响核心包的公共 API，通常需要同步检查这些插件包是否依赖了被修改的接口；如果只是修复某个选择器处理逻辑，则核心包 packages/purgecss/src/index.ts 及其对应测试文件即可覆盖。

许可证

本项目采用 MIT License，详见 LICENSE 文件。你的贡献同样在此许可下发布。作为参考，packages/purgecss/package.json 的publishConfig.access为public，意味着所有子包均以公开包的形式发布到 npm。

小结

为 PurgeCSS 贡献代码的完整路径是：Fork 仓库 → 从main创建特性分支 →npm i安装依赖 → 编写带单元测试的代码（npm test <pattern>定向验证）→ 必要时更新 docs 文档 →npm run lint与npm test全量通过 → 提交 PR。遵循 SemVer 语义、保持测试覆盖与代码风格一致，是让改动顺利合并的关键。

• 前端
• 构建工具