天界程序员的博客

PullRequst 直译过来就是拉取请求，那么拉取请求和提交代码有什么关系呢。这里面有一个比喻，我们可以把代码比作一个团队，对于一个陌生人来讲，你很难获取信任，让你直接插手团队的管理。这个时候上帝给了你一次证明的机会，就是复制一个一模一样的团队给你。你经过一段时间的优化管理后，可以把你的复制团队和原有团队的对比记录发送给原团队的管理者证明你优化的效果，请求将你的改进合并到原团队之中，这种行为就是代码世界的 PullRequest。

代码覆盖率才是评价一个项目品质的标准。在挑选一个项目的时候，有经验的使用者都会根据代码覆盖率来确定代码的可靠性。虽然自动化测试工具可以自动验证代码的正确性，但是如果只有部分代码经过了测试，或者只是简单地跑通了代码，也不能说是一个合格的代码。比如组件库只测试一部分的组件，或者每个组件只测试了默认设置。譬如，按钮中某个属性或者某几个属性间的排列组合并没有得到测试，这样的测试还不能保证组件库的功能完全正确。那么如何来客观评价这个测试的完备程度呢？

README 文档对于开源项目的重要性甚至会超过代码本身。你试想一下，你打开一个 Github 项目，第一时间就会看到 README 文档，而这时候同一类的项目你可能有很多选择，如果这个README不正规，无法快速上手，你可能直接就弃用这个项目。

文档网站需要发布到互联网上才能让更多的人知道。传统的发布方法需要做以下准备。这里面租用服务器和域名需要一笔花费。安装 Linux、Nginx，配置域名与 HTTPS 证书需要相应的服务器端知识。注册 HTTPS 证书和实名认证都需要准备和寄送材料，传统的部署方式可以说是费时费力。假设你只想简单的发布一个静态网页，完全没有必要采用这个方案。目前，最佳的解决方案是使用 Serverless 页面托管云服务。这些云服务只需简单配置就可以自动发布 Github 上面的页面；图形化界面操作省去了学习服务器端知识。

组件库会包含几十甚至上百个组件，但是应用的时候往往只使用其中的一部分。这个时候如果全部引入到项目中，就会使输出产物体积变大。按需加载的支持是组件库中必须考虑的问题。

组件库一般都会配有周边产品，比如Admin、Template、CLI工具等等。周边产品相当于有关联的多个项目，更准确的说法是多个软件包。这个时候就应该使用Monorepo方式组织代码，方便频繁在多个项目间同时交替开发，同时发布，保持版本间没有冲突。Mutirepo所谓传统方式，我们称之为Multirepo方式，或者可以称之为方式。就是说遇到多个软件包的场景，使用多个Repo仓库的方式组织代码。换句话说就是，一个软件包一个Repo仓库。其实我们常见的前端项目默认就是这样的模式。

版本格式：主版本号.次版本号.修订号（MAJOR.MINOR.PATCH），版本号递增规则如下：主版本号：当你做了不兼容的 API 修改；次版本号：当你做了向下兼容的功能性新增；修订号：当你做了向下兼容的问题修正。

软件是一种著作，天然是拥有版权的。很多人会认为放在Github上的就是开源软件，既然放了源代码，我就可以随便使用了。其实版权法规定著作是禁止共享的，也就是说没有许可证的软件等于保留版权。虽然源代码公开了，但并不表明你可以随便使用，一用就会侵犯版权。如果软件侵犯版权，必须明确授予用户开源许可证。另外，有一些没有道德的公司会大量使用开源的产品，进行组合封装修改后当做自己的劳动创造。GPL协议就是防止这种情况发生的。软件著作权的明确，作者（版权方）的权益明确，保护知识成果。

是一个集成服务，你可以认为它是一台远程运行的服务器。其中运行单元测试的命令还进行了一些修改，因为 vitest 是默认伺服模式，也就是说，它不会在运行完成后退出，所以就需要增加一个非伺服模式的命令。每个项目都遇到的常用操作，比如 checkout 检出代码、安装 pnpm 依赖等等，这些步骤显然不需要自己编写，直接使用脚本就可以了。持续集成可以认为是一种优秀的开发实践，它可以在代码变更的时候及时反映代码状态。，其实就是在使用虚拟机。根据触发器的配置，持续集成脚本会在每次提交 push 代码的时候触发。

代码压缩是指去除代码中的空格、制表符、换行符等内容，将代码压缩至几行内容甚至一行，这样可以提高网站的加载速度。混淆的主要目的是增加反向工程的难度，同时也可以相对减少代码的体积，比如将变量名缩短就会减少代码的体积。为了方便用户使用，一款成熟的类库都会提供多种模块封装形式，比如大家最常用到的 Vue，就提供了cjs、esm、umd 等多种封装模式，并且还会提供对应的压缩版本，方便在生产环境下使用。它记录了转换压缩后的代码所对应的转换前的源代码位置，是源代码和生产代码的映射。就很容易还原原始代码。

主要是完成对于代码语法的检查工作，比如：是否有声明但是没有使用的变量。需要配置自动化脚本，确保代码在提交前通过了代码验证工具的检验。当你提交代码没有按照规范填写 commit message 时，就会出现报错并且阻止你提交代码。代码的规范性建设非常重要。规范中，主要就是要求提交内容要进行分类并填写内容，更为严格的规定是要求标注开发模块。首先配置一个钩子，在 commit 提交前，必须执行 lint 代码校验。提交规范主要是为了让开发者提交完整的更新信息。配置完成后，commit 一次代码测试一下是否有效。

Vitest 是一个基于 Vite 的测试框架，它可以做到与 Vite 通用配置。也就是说，如果你在 Vite 中使用插件支持了JSX语法，做单元测试的时候就无需再配置一遍了，这点非常重要。并且 Vite 兼容了大部分 Jest 的使用方法，这样以往 Jest 的使用经验依然可以用在 Vitest 中使用，没有太多的重复学习过程。另外 Vitest 更加注重性能，尽可能多地使用 Worker 线程并发执行，可以提高测试的运行效率。

单元测试是针对开发的最小单位展开的测试，通常是函数。遇到函数调用函数的情况，比如 A 函数调用 B 函数，测试的主体是 A 函数，B 函数应该与测试无关，应该孤立 B 函数来测试 A 函数。最佳的选择是后者，因为你的测试程序会放到不同的环境中执行，你不可能要求 CI 服务器中也有浏览器。在测试程序中，被测试函数创建了一个 div 元素，接着就可以在 dom 仿真中获取 div 元素了。调用时不会发生真正的网络请求，只会返回预定的结果。是创建Mock函数最简单的方式，如果没有定义函数内部的实现，

文档建设一般会是一个静态网站的形式 ，这次采用 Vitepress 完成文档建设工作。Vitepress 是一款基于Vite 的静态站点生成工具。开发的初衷就是为了建设 Vue 的文档。Vitepress 的方便之处在于，可以使用流行的 Markdown 语法进行编写，也可以直接运行 Vue 的代码。也就是说，它能很方便地完成展示组件 Demo 的任务。使用 Vitepress 作为文档建设工具还有另外一个好处。由于 Vitepress 是基于 Vite 的，所以它也很好的继承了 Bundless 特

UnoCSS的GitHub地址UnoCSS的文档地址原子样式也有很多选择，最著名的就是 。 虽然好，但是性能上有一些不足。由于 会生成大量样式定义。全量的 文件往往体积会多至数 。这个对于页面性能是完全不可接受的。如果在开发时进行动态的按需剪裁，又会影响编译性能，降低开发体验。为了解决性能问题，开源界一个叫做 的大神设计了 。 是一个拥有高性能且具灵活性的即时原子化 引擎，可以兼顾产物体积和开发性能。引入 样式实现组件属性定制按钮样式实现【Icon图标按钮】其中的 是字体图标库文件名：下面就

组件库开发：vite + vue开发一个组件

到此说明 Vite 已经可以正常地调试 Typescript 代码了。浏览器查看网址，是否正常显示。正常显示说明vite安装正常。在浏览器访问此地址，无报错，说明Vite环境已经搭建完成。浏览器控制台打印结果。