作为一名前端架构师，我是怎么搭建前端工程化滴

至简简
13,112 阅读1小时+

笔者作为公司的一名前端架构师，先后经历过各种大中小型前端项目，将自己的经验总结如下，从空文件到项目上线到后续维护。欢迎各位前端小伙伴Review，有不对地方请指出，互相学习

编码规范

开篇最重要的不是选用前端框架，也不是选用UI组件库，而是最重要的 JavaScript 编码规范。

编码规范是指对编写代码的一组规则和约定，主要目的是确保团队中的每个成员都遵循一致的编程风格，减少代码中的差异，提高代码的可读性和可维护性。它通常包括代码格式化、命名约定、代码结构、注释等方面的规定

在技术生涯中，笔者一直认为编码规范非常重要，代码首先是写给人看的，遵循合理的代码规范让代码便于阅读和修改。

JS社区对前端项目中合理的代码规范进行归纳总结，下面是比较受欢迎的两份JS代码规范：

Airbnb JavaScript Style Guide

Airbnb JavaScript Style Guide 是一个广泛使用的、针对 JavaScript 编程语言的编码规范，旨在帮助开发人员编写一致、易读且可维护的 JavaScript 代码。这个风格指南由 Airbnb 团队创建，并被许多开发者和公司采纳。它涵盖了 JavaScript 编程的各个方面，包括语法、代码风格、最佳实践等。

这份规范包含代码风格、语法与结构、命令约定、对象与数组、错误处理、异步代码和其他等

Google JavaScript Style Guide

Google JavaScript Style Guide 是由 Google 提供的一套 JavaScript 编程规范和最佳实践指南，旨在帮助开发者编写一致、清晰和高质量的 JavaScript 代码。它为 JavaScript 开发者提供了统一的编码风格，以确保代码的一致性、可读性和可维护性。Google 的这份 JavaScript 风格指南不仅适用于前端开发，还适用于 Node.js 等后端开发

Google JavaScript Style Guide 比较简洁，旨在提供实用的规则，以帮助开发者更好地编写符合最佳实践的代码。它的主要目标是确保团队合作时，代码风格的一致性

笔者是强烈推荐将这两份编码规范纳入公司的开发规范中，让团队中的小伙伴熟悉规范里的内容，非常有助于之后的协作

npm/Yarn/pnpm

上面说完编码规范，现在说说2025年了，现代化前端有哪些变化？在JQ流行的时候，讲究JQ一把梭，JQ可以搞点一切，但是后来开始流行前端工程化，前端圈大变天。

说到前端工程化，首先离不开 Node.js 和包管理器。

  • Node.js 是一个基于 Chrome V8 引擎 的开源 JavaScript 运行时环境，允许开发者在服务器端运行 JavaScript。它使得 JavaScript 从浏览器端的客户端语言，扩展到服务器端的应用开发，具有非阻塞、事件驱动的特性

  • 包管理器。npm、Yarn 和 pnpm 都是 JavaScript 包管理工具，它们的主要作用是帮助开发者管理项目中的依赖包。通过这些工具，开发者可以轻松地安装、升级、删除和管理项目所需的各种外部库或模块。

npm

npm 是 Node.js 默认的包管理工具，只要安装 Node.js，就包含对应版本的 npm。它允许开发者下载和管理 JavaScript 库、工具等依赖。它通过 package.json 文件来记录项目的依赖关系。

npm 作为 Node.js 默认的包管理工具，npm 使用广泛，生态系统成熟。

Yarn

Yarn 是 Facebook 提供的一个 JavaScript 包管理工具，旨在解决 npm 的一些问题，特别是关于速度和一致性的问题。它与 npm 兼容，但提供了一些额外的功能和优化。

Yarn 通过缓存和并行化安装等方式，Yarn 的安装速度通常比 npm 更快。yarn.lock 确保所有开发者都安装相同版本的依赖，避免了由于依赖版本不同而导致的潜在问题。如果之前安装过某个依赖，Yarn 可以从本地缓存中安装，而不需要重新从网络上下载。

pnpm

pnpm 是一种更高效的 JavaScript 包管理工具，旨在解决 npm 和 Yarn 在处理大量依赖时的性能瓶颈问题。pnpm 通过优化存储和管理方式来提高包管理效率。

pnpm 通过硬链接和全局缓存，pnpm 极大地减少了磁盘占用，尤其是在多个项目共享相同依赖的情况下。安装依赖时，不会为每个项目创建独立的依赖副本，而是通过共享缓存来节省空间。

pnpm 的优点有

  • 高效的磁盘使用：pnpm 使用硬链接技术，使得多个项目可以共享相同的依赖，减少了磁盘空间的浪费。
  • 性能优越：pnpm 对大量依赖的处理效率非常高，能够在不同的项目间重用依赖，减少冗余的下载和安装时间。
  • 更严格的依赖管理：pnpm 在安装依赖时采用严格的隔离策略，防止出现隐式的依赖，确保每个包只有显式声明的依赖。

总结对比

特性npmYarnpnpm
安装速度较慢（但近年有改善）更快（并行安装、缓存机制）非常快（高效缓存和硬链接技术）
依赖锁定使用 package-lock.json使用 yarn.lock使用 pnpm-lock.yaml
磁盘占用较高，重复依赖存储较高，类似于 npm较低，使用硬链接共享依赖
离线支持较弱良好（缓存机制）非常好（高效的离线安装支持）
兼容性与 Node.js 和 NPM 仓库完全兼容与 NPM 基本兼容兼容 NPM 和 Yarn 项目，但使用自己的存储和依赖解析方式
社区和生态最大的 JavaScript 社区，生态非常成熟由 Facebook 维护，广泛使用新兴工具，正在获得越来越多的关注

这些工具各有优缺点，具体使用哪一个取决于你的项目需求、团队习惯以及性能需求。笔者常用 Yarn

Webpack/Vite

说到前端工程化，自然离不开构建工具。Webpack 和 Vite 都是现代前端开发中常用的构建工具，主要用于打包 JavaScript 代码、CSS、图片等静态资源，并优化前端应用的构建和开发流程。它们的主要作用是提升开发效率、构建速度、代码优化等，但它们在实现方式和功能上有一些显著的区别。

Webpack是老牌的构建工具，而Vite是后起之秀，两个构建工具在原理上不一样

Webpack

Webpack 是一个模块打包工具，可以将应用中的各种资源（JS、CSS、图片、字体等）都看作模块，然后将它们打包成一个或多个最终文件。它提供了强大的插件和加载器机制，使得它在前端构建工具中非常灵活和强大。

主要功能包括不限于

  1. 模块打包：将 JS、CSS、图片等资源打包成最终的静态文件。
  2. 代码拆分：将大文件拆分成多个小文件，优化性能。
  3. 静态资源处理：通过各种 Loader 处理 CSS、图片、字体等静态资源。
  4. 热更新：提供开发模式下的热更新（HMR），加速开发过程。

Webpack的功能强大，生态丰富，适应多种需求。支持多种插件，扩展性强。但是Webpack 的配置文件通常比较复杂，需要一定的学习成本，学习曲线比较陡，另外构建速度较慢，尤其在大型项目中，构建速度可能较慢。

Vite

Vite 是一个现代化的构建工具，设计理念是快速开发和高效的构建，它的核心优势是采用了原生 ES 模块（ESM）作为开发模式，并且利用浏览器对 ESM 的支持，来避免传统打包工具中常见的冗长的打包时间。

主要功能包括不限于

  1. 开发时快速启动：Vite 利用原生 ES 模块，实现快速启动，几乎是即时热更新。
  2. 打包优化：使用 Rollup 作为生产环境下的打包工具，构建速度快且优化效果好。
  3. 模块热更新（HMR） ：比 Webpack 更加快速和精确，不需要全局重载。

Vite的开发环境启动速度极快，热更新响应非常快。默认有许多合理的配置，开发者无需进行复杂的配置，由于利用原生 ESM，无需编译整个项目，在开发模式下不需要进行打包。Vite是新工具，整个生态不如Webpack 丰富，某些插件和集成可能不如 Webpack 完备。生产模式下利用Rollup对项目打包，可能会带来某些问题

以下是 Vite 和 Webpack 的区别对比表：

特性ViteWebpack
启动速度利用原生 ES 模块实现即时启动，启动速度极快需要全量打包，启动速度较慢，特别是大型项目
热更新极快的热更新，基于 ES 模块的增量更新热更新速度较慢，需要重建整个模块
打包过程仅在生产环境下使用 Rollup 进行打包开发环境也进行打包，速度较慢
配置配置简洁，默认配置能满足大部分需求配置复杂，需要对插件和 Loader 有较多了解
生态和兼容性生态逐步扩展，但仍较年轻成熟的插件生态，几乎支持所有前端框架和工具
生产环境打包使用 Rollup 打包，优化较好，速度快使用 Webpack 打包，打包速度较慢，且配置复杂
支持的功能提供对现代框架的开箱即用支持，适合新项目支持更广泛的功能，适合传统的、复杂的项目
支持的模块系统基于原生 ES 模块进行开发支持 CommonJS 和 ES 模块系统，兼容性更好
适用场景适用于现代项目和快速开发适合大型项目、复杂的构建需求和老旧项目

总结：

  • Vite 在启动速度和开发体验上占优，适合现代项目和快速开发，但相对来说生态和插件支持还在不断完善中。
  • Webpack 在生态成熟度、配置灵活性和处理大型项目的能力上更强，适合需要高度定制和复杂打包需求的项目。

构建工具在前端工程化中非常重要，必须掌握如何使用构建工具。Webpack强调将所有模块打包成bundle文件，而Vite强调less bundle，在开发模式下直接利用浏览器加载ESM模块。这两个构建工具各有优缺点，在实际项目中都有应用场景。

如果你是一个正在构建新项目的开发者，尤其是小到中型项目，Vite 无疑是一个非常值得考虑的选择。对于需要大量定制化或者已有 Webpack 配置的大型项目，Webpack 仍然是一个非常强大的工具。

React/Vue/Angular

标题写了Angular，但是Angular在国内用的比较少，就不怎么谈论。重点看看React和Vue两个现代化前端框架

React 和 Vue 都是流行的前端 JavaScript 框架/库，用于构建用户界面，尤其是单页面应用（SPA）。它们都解决了前端开发中的组件化、状态管理、响应式渲染等问题，并且都是当今前端开发的重要工具。不过，React 和 Vue 在设计哲学、功能特性、开发体验等方面有一些显著的差异。

React

React 是由 Facebook 开发并维护的一个开源 JavaScript 库，主要用于构建用户界面，特别是在处理复杂的单页面应用时。它的核心概念是“组件化”和“声明式编程”，让开发者可以将 UI 分成小的、可重用的组件。

主要特点：

  1. 组件化：React 的应用是由组件构成的，每个组件是一个独立的、封装的 UI 单元。组件可以通过 props 和 state 来管理数据和行为。
  2. 虚拟 DOM：React 使用虚拟 DOM 来优化界面更新的性能，减少了不必要的 DOM 操作，提高渲染效率。
  3. 声明式 UI：React 的 UI 是声明式的，开发者描述想要的 UI，React 会根据数据的变化自动更新视图。
  4. 单向数据流：React 使用单向数据流，组件的数据通过 props 传递，数据更新通过 state 来触发视图更新。

优点：

  • 灵活性高：React 是一个库，而不是框架，所以它只关注视图层，开发者可以自由选择如何组织其他部分（如路由、状态管理）。
  • 社区支持强：React 拥有庞大的社区和丰富的生态系统，包括大量的第三方库、插件和工具。
  • React Native：React 也可以用于开发原生移动应用，React Native 使得 Web 开发者能够快速上手移动应用开发。

缺点：

  • 学习曲线：虽然 React 核心 API 简单，但要掌握 React 生态中的各种工具和库（如 React Router、Redux、Context API 等）可能需要一定的时间。
  • 繁琐的 JSX：React 使用 JSX 语法，这使得 HTML 和 JavaScript 混合在一起，可能对初学者不太友好。

Vue

Vue 是由前 Google 工程师尤雨溪（Evan You）开发的一个渐进式 JavaScript 框架。Vue 的设计目标是尽可能简单和灵活，特别注重开发体验。Vue 的学习曲线相对较低，非常适合入门级开发者。

主要特点：

  1. 双向数据绑定：Vue 提供了双向数据绑定功能，可以让数据的变化自动反映到视图层，反之亦然。这种特性借鉴了 Angular 的做法。
  2. 组件化：和 React 一样，Vue 也采用组件化开发，开发者可以将 UI 拆分成多个小的组件。
  3. 响应式系统：Vue 内置响应式系统，当数据发生变化时，视图会自动更新。这使得开发者不需要手动管理 DOM 更新。
  4. 渐进式框架：Vue 是一个渐进式框架，可以根据需要逐步引入不同的功能模块。开发者可以选择只使用它的一部分（如 Vue Router、Vuex）或者使用完整的 Vue 全家桶。

优点：

  • 开发体验优秀：Vue 的文档非常详细，学习曲线相对较平缓，适合初学者。
  • 内置的工具链：Vue 提供了 Vue Router 和 Vuex 等内置工具，开发者不需要依赖第三方库即可构建完整的应用。
  • 响应式数据：Vue 的响应式系统非常高效，开发者只需专注于数据和逻辑，框架会自动处理 UI 更新。
  • 模板语法简洁：Vue 使用类似 HTML 的模板语法，较为直观和易懂。

缺点：

  • 生态较小：虽然 Vue 的社区和生态不断壮大，但相比 React，其生态规模仍然较小，某些第三方库和工具可能没有 React 那么丰富。
  • 灵活性略低：Vue 是一个更为框架化的工具，提供了很多默认的配置和功能，有时可能让开发者感到约束。

主要区别

特性ReactVue
框架 vs 库React 是一个 UI 库，专注于视图层Vue 是一个渐进式框架，包含更多功能模块
数据绑定单向数据流（props 和 state）双向数据绑定（v-model）
学习曲线学习曲线较陡，需要学习很多工具和库学习曲线平缓，更易上手
灵活性非常灵活，开发者可以自由选择工具链提供了更多默认配置和工具，灵活性较低
虚拟 DOM使用虚拟 DOM 优化性能也使用虚拟 DOM 优化性能
模板语法JSX（JavaScript 和 HTML 混合）传统模板语法，HTML 和 JavaScript 分离
生态和社区支持社区庞大，插件和第三方库丰富社区规模较小，生态逐步发展
移动开发React Native 支持跨平台开发Vue 支持跨平台开发，但生态不如 React
状态管理使用 Redux 或 Context API使用 Vuex 状态管理

总结

  • React：更适合那些希望有极高自由度和灵活性的开发者，适合大规模应用、需要可重用组件以及高性能的项目。React 的生态成熟，适合那些需要大量定制化的项目。
  • Vue：更适合初学者以及追求简单、快速开发的项目，Vue 提供了一个更为完整的框架，内置了很多开发所需的功能模块。Vue 的开发体验非常好，非常适合中小型项目。

如果你是初学者，Vue 可能是一个比较容易上手的选择。如果你追求灵活性和想要更广泛的社区支持，React 会是一个很好的选择。

站在个人角度，我不喜欢说那个框架比另一个框架好，项目适合用那个框架就用那个框架！

React/Vue相关生态

说到React和Vue框架，就离不开配套使用其他第三方依赖。React 和 Vue 的生态系统是指它们周围围绕着的一系列工具、库、插件、框架和社区资源，旨在提升开发效率、提供扩展功能，并让开发者能够更加高效地构建和管理应用。这些生态系统的成熟度和广度对开发者的选择有很大的影响。

React 生态

React 的生态非常成熟、庞大，涵盖了开发过程中的方方面面。由于 React 是一个专注于视图层的库，它通常需要其他工具和库来配合使用。

1. 状态管理

  • Redux：React 最经典的状态管理库，用于全局状态的管理，尤其适用于大型应用。通过中心化存储和纯函数来管理应用状态。
  • React Context API：React 官方提供的轻量级状态管理方式，适用于小型应用或局部状态管理。
  • Recoil：由 Facebook 提供的轻量级状态管理库，特别适合处理 React 的复杂状态。
  • MobX：一个响应式的状态管理库，通过自动追踪状态和更新视图，简化了复杂状态的管理。

2. 路由

  • React Router：React 最常用的路由库，支持动态路由、嵌套路由、懒加载等功能，是 React 项目中几乎必不可少的工具。

3. 表单处理

  • Formik：一个高效的 React 表单库，用于管理表单的状态、验证和提交。
  • React Hook Form：另一个流行的 React 表单库，性能非常优秀，尤其适合大型表单。

4. UI 组件库

  • Material-UI (MUI) ：一个流行的 React UI 组件库，提供了丰富的 UI 组件，基于 Google 的 Material Design 规范。
  • Ant Design：一个企业级的 UI 组件库，适合构建复杂的管理后台和企业级应用。
  • Chakra UI：一个轻量级、现代化的 React UI 库，提供简洁的 API 和易于定制的组件。

5. 数据获取

  • Axios：一个流行的 HTTP 请求库，通常与 React 一起使用来进行网络请求。
  • React Query：一个强大的数据获取库，提供缓存、分页、自动刷新等功能，简化了异步数据管理。

6. 样式管理

  • Styled Components：一个 CSS-in-JS 库，允许开发者在 JavaScript 中直接写样式，提供了更强的样式封装性。
  • Emotion：与 Styled Components 类似，也是一个 CSS-in-JS 库，但性能上有些许差异，Emotion 更注重速度和灵活性。

7. 测试工具

  • Jest：React 官方推荐的 JavaScript 测试框架，集成了测试运行器、断言库和模拟功能，适用于单元测试和集成测试。
  • React Testing Library：一个专注于 UI 测试的工具，鼓励开发者编写更接近用户行为的测试用例。

8. 构建工具

  • Webpack：常用的构建工具，能够打包 JavaScript、CSS 和其他资源。React 项目中常与 Babel 和其它插件一起使用。
  • Create React App：一个官方的脚手架工具，帮助快速启动 React 项目，内置 Webpack 配置，方便开发者进行开发。
  • Vite：现代化的构建工具，支持更快的热更新和模块加载，越来越多的 React 开发者开始转向 Vite。

9. 跨平台开发

  • React Native：一个用 React 编写移动应用的框架，可以让开发者用相同的技术栈开发 iOS 和 Android 应用。

10. 开发工具

  • React DevTools：React 的开发者工具，提供了用于调试和查看 React 组件树、状态、Props 的功能。

Vue 生态

Vue 的生态系统也非常强大，尤其在 Vue 3 发布之后，它的生态逐渐完善并被广泛接受。与 React 相比，Vue 提供了一个更加完整的框架，许多常用的工具都由 Vue 官方或社区提供。

1. 状态管理

  • Vuex：Vue 官方的状态管理库，用于集中管理应用中的状态，支持模块化、插件、时间旅行调试等功能。

2. 路由

  • Vue Router：Vue 官方提供的路由库，支持动态路由、嵌套路由、懒加载等功能，与 Vue 配合得天衣无缝。

3. UI 组件库

  • Element Plus：一个流行的 Vue UI 组件库，适合开发后台管理系统，提供了一整套精美的组件。
  • Vuetify：基于 Material Design 的 Vue UI 组件库，提供丰富的组件和主题定制选项。
  • Quasar：一个全栈 UI 框架，提供了用于开发响应式应用的组件，还支持 SSR、PWA 和移动端应用开发。

4. 表单处理

  • VeeValidate：一个表单验证库，用于在 Vue 应用中轻松进行表单输入验证。
  • Vue Formulate：用于构建动态表单的库，提供了强大的表单元素和验证功能。

5. 数据获取

  • Axios：同样，Axios 在 Vue 中也很常见，用于执行 HTTP 请求。
  • Vue Query：一个高效的异步数据管理库，类似于 React Query，专为 Vue 设计，能够处理缓存、分页、自动更新等功能。

6. 样式管理

  • Vue Styleguidist：一个用于 Vue 组件库的开发工具，可以生成可交互的组件文档。
  • Vue Styled Components：类似于 React 中的 Styled Components，也是一个 CSS-in-Vue 的库，允许直接在 Vue 组件中编写样式。

7. 测试工具

  • Jest：Vue 支持 Jest 测试框架，用于单元测试和集成测试。
  • Vue Test Utils：Vue 官方提供的单元测试工具，专门用于测试 Vue 组件。

8. 构建工具

  • Vite：Vite 的出现使 Vue 构建和开发的速度大大提高。Vite 是一个现代化的构建工具，支持 Vue 项目的开发和打包。
  • Vue CLI：Vue 的官方脚手架工具，支持快速创建 Vue 项目并配置构建流程。

9. 跨平台开发

  • NativeScript Vue：一个基于 Vue 的跨平台框架，允许开发者用 Vue 写原生 iOS 和 Android 应用。

10. 开发工具

  • Vue DevTools：Vue 的官方开发者工具，提供了强大的调试功能，可以检查 Vue 组件、数据、事件等。

总结

  • React 生态：React 的生态系统非常庞大，涵盖了从状态管理到路由、UI 组件、构建工具等各个方面。React 的灵活性使得开发者可以根据需求选择适合的工具和库，但是这也意味着 React 开发者往往需要花更多时间去学习和集成不同的工具。
  • Vue 生态：Vue 提供了一个更为集成化的解决方案，官方和社区提供了从状态管理到路由、UI 组件库等多个功能模块。Vue 生态的工具通常与 Vue 紧密集成，适合那些希望使用一个“全家桶”来进行开发的团队。

两者的生态系统都非常强大，最终选择哪个取决于开发者的需求、项目规模以及对灵活性和集成度的偏好。

CSS

CSS一直是前端项目的重中之重。在前端工程化项目中，CSS 解决方案的选择对项目的可维护性、开发效率和性能有着重要影响。随着前端开发的不断演进，各种 CSS 解决方案应运而生，用于解决传统 CSS 中存在的一些问题，比如命名冲突、全局样式污染、模块化开发等问题。以下是一些常见的 CSS 解决方案及其特点：

这个表格清晰地展示了不同 CSS 解决方案的优缺点

样式方案优点缺点
传统 CSS- 简单直观，学习曲线低- 不需要引入额外的工具和框架- 命名冲突：样式通常是全局的，容易导致命名冲突- 样式污染：全局样式可能影响到其他部分- 随着项目规模扩大，样式管理复杂
CSS 预处理器（Sass、Less、Stylus）- 增强的功能：支持变量、嵌套规则、函数、混入等- 模块化：通过 @import 或 @use 实现样式模块化- 代码复用：通过混入、函数等复用代码- 编译步骤：需要通过构建工具编译为标准 CSS- 增加复杂度：对于小项目，引入预处理器增加不必要的复杂度
CSS-in-JS- 组件化：每个组件拥有自己的样式，避免了全局样式污染- 动态样式：根据 props 或状态动态生成样式- 支持 JS 变量：直接使用 JS 变量和逻辑- 性能开销：增加运行时性能开销- 学习成本：需要学习新的语法和工具，尤其对于不熟悉 JS 的开发者
BEM（块元素修饰符）命名规范- 避免命名冲突：确保类名唯一- 模块化：组件样式与组件关联- 可维护性：层次结构清晰，便于维护- 类名冗长：命名规则可能导致类名过长- 依赖手动命名：需要严格遵循命名规范，增加学习成本
PostCSS 和 Autoprefixer- 自动化：自动添加浏览器前缀，减少手动修改- 插件化：灵活配置插件，扩展功能- CSS 优化：进行压缩、合并等优化- 构建工具依赖：需要借助构建工具配置执行- 插件依赖：需要选择合适的插件进行支持
CSS Modules- 作用域隔离：避免全局样式污染，解决命名冲突- 易于集成：可以与 Sass 等一起使用- 配置要求：需要构建工具支持（如 Webpack）- 学习成本：适应模块化的方式需要时间
Tailwind CSS- 快速开发：大量预定义工具类，快速实现复杂 UI- 可定制性：高度配置选项，自定义颜色、间距、字体等- 响应式设计：内建支持响应式设计和状态变换- 类名冗长：HTML 中类名可能非常冗长- 学习曲线：需要掌握大量工具类，初学者可能不直观

总结

前端工程化项目中常用的 CSS 解决方案有很多，每种方案都针对不同的问题提供了解决方案。选择合适的 CSS 解决方案需要根据项目的规模、开发团队的需求以及应用的性能要求来权衡：

  • 传统 CSS 适合小型项目或简单的网页设计。
  • CSS 预处理器（如 Sass、Less）适合中小型项目，提供了更强的样式管理能力。
  • CSS-in-JS 适合组件化强的应用（如 React），可以将样式与组件逻辑结合。
  • BEM 适用于大型项目，通过规范化类名来确保样式的模块化和可维护性。
  • PostCSS 和 Autoprefixer 适合处理浏览器兼容性和样式优化。
  • Tailwind CSS 适合快速开发，尤其是那些要求快速构建 UI 的项目。

EditorConfig

EditorConfig 有助于跨不同编辑器和 IDE 处理同一项目的多个开发人员保持一致的编码风格。

对于多人协作的项目，有小伙伴喜欢用VSCode，还有小伙伴喜欢用 WebStorm，但是对于一些公共的文本格式需要保持统一，而EditorConfig可以做好这件事

EditorConfig 的重要规则如下

insert_final_newline

insert_final_newline 是一个在许多文本编辑器和版本控制系统（如 Git）中常见的设置选项。当这个选项被启用时，它会在文本文件的末尾自动插入一个空行（也称为最终新行或尾随新行）。

end_of_line

end_of_line 指定了文本文件中的行结束字符。在不同的操作系统（Unix/Windows/Linux等）中，行结束的表示方式可能不同：

  • 在 Unix/Linux 系统中，通常使用单个换行符（LF，即 \n）来表示行结束
  • 在 Windows 系统中，通常使用回车符（CR，即 \r）后跟换行符（LF，即 \n），即 \r\n 来表示行结束
  • 在早期 Mac 系统中，使用单个回车符（CR，即 \r）来表示行结束，但现代 Mac 系统已经改为使用 Unix 风格的换行符（LF）

end_of_line 设置的作用是确保文件在不同的操作系统之间传输或协作时，行结束符能够被正确识别和处理。例如，如果你在 Windows 系统上编写了一个文本文件，然后将它上传到 Git 仓库，end_of_line 设置可以确保文件在 Unix/Linux 系统上的用户拉取时，行结束符能够被转换为 Unix 风格的 \n，以避免出现不必要的差异或错误。

保持 end_of_line 设置的一致性对于跨平台项目和协作是非常重要的，因为它可以避免由于行结束符差异引起的不必要的文件差异或冲突。

indent_style

indent_style 用于控制代码或文本文件的缩进风格。缩进风格通常有两种主要类型：

  • 空格（space）：在这种风格中，缩进是通过使用空格字符来完成的
  • 制表符（tab）：在这种风格中，缩进是通过使用制表符字符来完成的

indent_size

indent_size 用于控制代码或文本文件的每一级缩进应该使用多少个空格或制表符。这个设置通常与 indent_style 配合使用，后者决定了缩进是使用空格还是制表符。

在实际使用中，如果你配置 indent_style 为 space，那么 indent_size 将决定每次缩进插入多少个空格，而 tab_width 则决定了当你在代码中遇到制表符时，它在编辑器中显示为多少个空格的宽度。如果你配置 indent_style 为 tab，那么 indent_size 可能会决定每次缩进插入一个制表符，而 tab_width 则决定了这个制表符在编辑器中显示为多少个空格的宽度。

在不同的编辑器和 IDE 中，这两个设置可能会有不同的默认值和配置方式。例如，在 Visual Studio Code 中，你可以通过设置面板搜索这两个选项来更改它们的值。在 .editorconfig 文件中，你也可能会看到这两个设置，以确保跨不同编辑器和开发环境的一致性。

charset

charset 用于表示文本的一组字符以及每个字符的编码方法。常见的字符集有 UTF-8、UTF-16 和 ASCII 等等，工作中主要使用 UTF-8。

image.png

可以通过 VS Code 底部状态栏查看当前文件的字符编码

有关 EditorConfig 的详细配置可以看看笔者写的 Oxc 出来了，我却还在学 EditorConfig文章

Prettier

Prettier 是一个强约束的代码格式化工具，将原始格式的源代码按照设定的规则进行格式化， 然后输出格式化后的代码。支持常见的 js、jsx、html、json 等等编程语言或数据格式。

有关 Prettier 的详细配置可以看看笔者写的 谈一谈格式化工具 Prettier文章

ESLint

ESLint 是一个流行的 JavaScript 静态代码分析工具，它用来识别和报告代码中的潜在问题或不符合规范的地方，从而帮助开发者写出更干净、更一致的代码。ESLint 主要的功能是：

  1. 代码质量检查：它能够检查代码中可能存在的错误，如未使用的变量、语法错误等。
  2. 风格一致性：它可以根据特定的规则来保证代码风格的一致性（如缩进、命名规范等），帮助团队在协作中保持一致的编码风格。
  3. 自定义规则：可以根据项目需求配置或编写自定义的规则。
  4. 插件和扩展：支持通过插件扩展，增加对不同语言（如 TypeScript）、框架（如 React）等的支持。

你可以通过配置文件（如 .eslintrc）来设置 ESLint，或者通过命令行工具集成到开发流程中。

ESLint 通常与代码编辑器的插件一起使用，或者在构建工具链中作为一个步骤（例如与 Webpack、Gulp、Grunt 等工具结合）。

Stylelint

Stylelint 是一个用于 CSS、Sass、Less 等样式表语言的静态代码分析工具，类似于 ESLint，但专注于样式代码的质量和一致性。它的作用是帮助开发者检测和修复样式代码中的潜在问题，确保样式代码符合一定的风格规范。

Stylelint 的主要作用：

  • 代码质量检查： 检查 CSS、Sass 等代码中的语法错误、无效的属性或重复的选择器等问题。
  • 风格一致性：保证样式代码的风格一致性，比如属性顺序、缩进方式、空格使用、命名规范等。这样团队可以在多人协作时保持统一的代码风格。
  • 自定义规则：你可以根据项目需求创建自定义规则，或者调整默认规则，来满足团队或个人的编码风格。
  • 插件支持：支持扩展插件，能够增强功能，比如支持新的 CSS 语法、添加对 CSS 预处理器（如 Sass、Less）的支持等。
  • 提高代码可维护性：强制一致的代码风格有助于提高样式表的可读性和可维护性，尤其是在大型项目中尤为重要。

使用方式：

Stylelint 可以作为开发工具链的一部分，在构建工具中自动运行（比如通过 Gulp、Webpack 等），或者通过编辑器插件实时提示潜在问题。

主要特点：

  • 支持多种样式语言（CSS、SCSS、Sass、Less 等）。
  • 强大的规则系统，可以灵活配置。
  • 能与其他工具（如 Prettier）配合使用，进一步增强代码的自动格式化功能。

总的来说，Stylelint 通过静态分析帮助开发者保持样式代码质量，并且减少因为风格不一致引起的潜在问题。

commitlint

Commitlint 是一个用于检查 Git 提交消息（commit message）是否符合预定规范的工具。它的目的是确保团队成员在提交代码时，遵循一致的提交规范，从而提升代码仓库的可读性、可维护性，并使得提交历史更加清晰和结构化。

Commitlint 的主要作用：

  1. 强制规范化提交信息：通过定义和检查提交消息格式，确保所有的提交信息符合预定的格式或规范（如 Conventional Commits）。这有助于统一团队的提交标准，避免不同风格的提交信息混杂在一起，导致历史记录难以阅读和理解。

  2. 自动化检查：Commitlint 通常集成在 Git 钩子中（如 commit-msg 钩子），在每次提交代码时自动检查提交信息是否符合规范。如果不符合规范，提交将被拒绝，强制开发者修改提交信息，直到符合要求为止。

  3. 增强版本管理和发布流程：当遵循类似 Conventional Commits 这样的标准时，可以自动化地生成 Changelog（变更日志），并且配合版本管理工具（如 Semantic Release）自动管理版本号（根据提交的类型，自动增加版本号）。

    • 例如：feat: 表示新增功能，fix: 表示修复问题，chore: 表示一些琐碎的任务等，借此可以自动化发布流程，轻松推送新版本。

  4. 提高团队协作效率：团队成员之间可以快速了解每次提交的目的和内容，尤其是在大型项目中，规范化的提交信息有助于提升团队沟通效率和代码审核流程的顺畅度。

常见的提交消息规范：

  1. Conventional Commits：这是一种常用的提交信息规范格式，通常包括以下几个部分：

    • <type>(<scope>): <message>
    • 例如：feat(user): add login functionality 或 fix(button): resolve styling issue.
    • type 可以是 feat（功能）、fix（修复）、chore（琐事）、docs（文档）等，scope 是可选的，用来描述影响的模块或功能。

  2. 其他规范：也有团队或项目可能采用自定义的格式来管理提交消息。Commitlint 提供了高度的自定义能力，可以根据项目需求来配置规则。

使用方式：

  • Git 钩子：通常使用 Husky 这样的工具来自动化执行 commitlint，确保每次提交都会被检查。
  • 命令行工具：开发者可以使用 commitlint 在命令行上手动检查提交消息。
  • 集成到 CI/CD 流程中：在 CI 工具（如 GitHub Actions、Jenkins 等）中集成 commitlint，确保提交规范在合并到主分支之前得到验证。

主要优点：

  • 可读性：规范化的提交信息使得其他开发者能够迅速了解每个提交的目的。
  • 自动化发布：配合工具，能够自动生成版本号、发布日志等。
  • 团队协作：提高团队开发效率和代码审查流程。

总之，Commitlint 通过确保提交信息格式的一致性，帮助团队更好地管理代码仓库，并增强发布流程的自动化。

CSpell

在编程中，百分之九十的问题可能是粗心大意导致的，而拼写错误是粗心大意的主要原因

社区中推出一个解决Typo的自动化工具 CSpell, 用于检查项目中的 typo。CSpell 是一个开源的拼写检查工具，专门用于检查源代码文件中的拼写错误。它通常用于开发环境，帮助开发者确保代码中的注释、文档、变量名、字符串等文本部分没有拼写错误，从而提升代码的可读性和质量

CSpell 提供 npm 安装包，下面开始在项目中安装 cspell

快速开始

在项目中安装 cspell

yarn add cspell -D

然后在根目录的 package.json 中添加 npm script

"cspell": "cspell src/**/*.{ts,tsx,js,mjs,jsx}"

在项目中的某个文件里写一个错误的单词

image.png

在终端里运行 yarn cspell， 其结果如下

image.png

cspell 会检查出有typo的单词，并且给出提示。

cspell "src/**/*.js"
# or
cspell lint "src/**/*.js"

表示检查 src 文件下所有的 js 文件

cspell "**"

检查项目中的所有文件

如何设置配置文件

CSpell 支持使用配置文件对 CSpell 进行更详细的控制。CSpell 可以使用 JSON、Yaml 和 JavaScript 文件进行配置。它会自动搜索以下之一：cspell.json、cspell.config.yaml、cspell.config.cjs。笔者使用 cspell.json

请看下面这个配置例子

{
  "$schema": "https://raw.githubusercontent.com/streetsidesoftware/cspell/main/cspell.schema.json",
  "version": "0.2",
  "dictionaryDefinitions": [
    {
      "name": "typo-words",
      "path": "./typo-words.txt",
      "addWords": true
    }
  ],
  "dictionaries": ["typo-words"],
  "ignorePaths": ["node_modules", "dist", "build"]
}
  • "name": "typo-words"：定义了一个自定义词典的名称，叫做 typo-words。
  • "path": "./typo-words.txt"：指定了自定义词典文件的路径，这里是当前目录下的 typo-words.txt 文件。
  • "addWords": true：表示可以向这个自定义词典中添加新词。
  • "dictionaries": ["typo-words"]：指定了要使用的词典，这里使用了前面定义的 typo-words 自定义词典。
  • "ignorePaths": ["node_modules", "dist", "build"]：指定了要忽略的路径，Code Spell Checker 在这些路径下的文件中不会进行拼写检查。这里忽略了 node_modules、dist 和 build 目录。

在根目录添加 typo-words.txt 文件，在里面添加 helol, 再执行 yarn cspell, 结果如下

image.png

其他命令参数

一般情况下，项目的文件很多，在执行 cspell 检查的时候，不需要显示查询进度，可以使用命令参数

cspell src/**/*.{ts,tsx,js,mjs,jsx} --no-progress

Unit Test

说完一些Lint工具，现在来看一下单元测试/集成测试/E2E测试和视觉回归测试

单元测试（Unit Testing）是指对前端应用中的单个最小功能单元进行测试，以验证其是否按预期工作。这个"最小功能单元"通常是一个函数、方法、组件或模块。

单元测试的目的是确保每个独立的单元在隔离环境下能够正常工作，通常不涉及外部依赖，比如后端接口或数据库等。

目前流行的单元测试框架主要是Jest和Vitest，这个两个测试框架的官方文档非常详细

Jest 是一个流行的 JavaScript 测试框架，由 Facebook 开发和维护。它广泛用于 React 应用程序的单元测试、集成测试和端到端测试。Jest 的主要特点包括：

  1. 零配置：Jest 是开箱即用的，你不需要做很多配置就可以开始写测试。
  2. 快照测试：Jest 支持快照测试，能够记录组件的输出，并在后续测试中比较这些输出是否发生了变化，这对于 React 组件尤为有用。
  3. 并行测试：Jest 会并行执行测试以提高速度。
  4. 内置断言库：Jest 内置了断言库，不需要额外安装其他库。
  5. 覆盖率报告：Jest 可以自动生成代码覆盖率报告，帮助开发者了解哪些部分的代码没有被测试到。
  6. 模拟功能：Jest 允许模拟函数和模块，以便进行隔离测试。

Vitest 是一个现代的、快速的 JavaScript 测试框架，专为 Vite 开发环境而设计。它与 Jest 类似，但有一些独特的优势，尤其是在与 Vite 配合使用时。Vitest 的目标是提供更高的性能和更现代的开发体验。

Vitest 的主要特点：

  1. 高性能：Vitest 使用 Vite 的构建工具，因此它能够非常快速地启动和运行测试，特别是在热重载和模块替换方面，比传统的测试框架更快。
  2. 与 Vite 完全集成：由于它是为 Vite 设计的，Vitest 在与 Vite 项目协作时表现得非常顺畅，支持 ES 模块、TypeScript 等，提供开发者友好的体验。
  3. Jest 兼容性：Vitest 在 API 设计上与 Jest 非常相似，许多 Jest 的测试语法和功能都可以直接在 Vitest 中使用。如果你已经熟悉 Jest，那么迁移到 Vitest 会比较容易。
  4. 内建模拟功能：Vitest 提供强大的模块模拟功能，可以在测试中模拟函数、模块和时间等，使得测试更加灵活和可靠。
  5. 断言库：Vitest 默认集成了断言库，如 expect，并且支持各种常用的测试方法和匹配器。
  6. 热重载：Vitest 支持热重载功能，可以实时反映代码修改，减少了手动重新运行测试的频率。
  7. 支持 TypeScript：Vitest 天生支持 TypeScript，能够在不需要额外配置的情况下进行类型检查和代码高亮。

Vitest 是一个现代化、快速且与 Vite 深度集成的测试框架，它旨在提供比传统框架（如 Jest）更好的性能和体验。如果你使用 Vite 作为构建工具，Vitest 会是一个非常理想的选择。

如果选用Webpack构建项目，选Jest作为测试框架比较适合，使用 Vite 作为构建工具，更倾向选 Vitest 作为测试框架。

选完测试框架后，接下来就是选用与测试框架配套使用的断言库等。在React项目中，还需要添加jsdom、happy-dom和@testing-library 系列依赖。在Vue项目中，还需要添加jsdom、happy-dom和@vue/test-utils等依赖

与单元测试相关还有如何mock外部资源，如何书写测试用例等内容，请小伙伴们阅读官方文档学习

有关单元测试有关的内容请看笔者的这篇文章《单元测试入门与进阶》

Integration Testing

集成测试（Integration Testing）是指对多个前端组件或模块进行组合测试，以确保它们在一起协作时能够正常工作。它的目的是检查不同模块之间的交互和数据流，验证前端应用在实际使用场景中的表现是否符合预期。

与单元测试不同，集成测试并不关注单个组件的实现，而是更侧重于多个组件或模块的结合点和接口是否正确。它的测试粒度比单元测试大，跟业务场景是强相关，

下面是常见的集成测试场景：

  • 多个组件的协作：测试不同前端组件或模块在组合后的行为，比如一个表单组件与数据处理组件的结合。
  • 与后端接口的交互：模拟前端与服务器的请求与响应，确保前端能够正确处理和展示从后端获取的数据。
  • 状态管理的正确性：如果应用使用了状态管理库（如 Redux、Vuex 等），集成测试会验证多个组件如何共享和更新状态。
  • UI 和 UX 测试：确保多个组件在用户交互后能够正常更新 UI，比如点击按钮后，UI 是否正确反应。

集成测试的常见工具：

  1. Jest/Vitest：一个广泛使用的 JavaScript 测试框架，可以与其他工具配合进行集成测试。
  2. React Testing Library/Vue Test Utils：专门为 React 和 Vue 设计的测试库，支持组件渲染、模拟交互等。
  3. Cypress：一个端到端的测试框架，也可以用于集成测试，模拟真实用户行为，进行跨组件或页面的测试。

集成测试的常见场景：

  • 表单提交与 API 通信：用户填写表单并提交数据，前端应该向后端发出请求并处理返回的响应。
  • 组件间数据流：父子组件通过 props 传递数据，或通过共享的状态进行交互，集成测试可以验证这种数据流是否正常。
  • 路由与页面跳转：验证点击链接或按钮后，路由是否正确跳转，页面是否正常加载。

为什么需要集成测试：

  1. 提高可靠性：集成测试能够及早发现组件之间集成时的潜在问题。
  2. 防止回归：随着项目复杂度的增加，集成测试能够确保新功能或修改不会破坏现有的功能。
  3. 模拟用户行为：集成测试通常涉及与用户界面的交互，能够更好地模拟真实使用场景。

总之，前端的集成测试对于确保各个模块、组件在一起正常运行非常重要。它帮助开发团队发现问题，减少集成阶段的调试工作，并提高整体应用的质量。

集成测试给我的感觉是对单元测试更高维度的一种概念，介于单元测试与 E2E 测试之间

E2E Test

E2E（End-to-End）测试是指对整个应用系统进行的全面测试，模拟用户的操作路径，从前端到后端，确保整个系统在真实使用环境中的功能和性能都符合预期。

前端的E2E测试

在前端开发中，E2E 测试主要关注的是应用的用户交互和 UI 行为是否符合设计要求。E2E 测试通常会模拟用户的完整操作流程，检查从前端到后端各个环节的交互是否正常。与单元测试或集成测试不同，E2E测试会涵盖整个应用，包括前端界面、API请求、数据库操作等。

常见场景有：

  1. 模拟用户行为：例如用户点击按钮、填写表单、提交请求、页面跳转等，确保这些操作能够顺利完成。
  2. 验证应用功能的正确性：检查应用的不同功能模块是否按预期工作。
  3. 确保系统的集成性：前端和后端的交互是否顺畅，API 调用是否正常，数据流是否符合预期。

前端E2E测试工具：

前端E2E测试通常借助一些自动化测试框架和工具来实现，常见的工具有：

  • Cypress：现代的前端E2E测试工具，支持快速的浏览器自动化，使用简单，文档完善，适合测试单页面应用（SPA）。
  • Playwright：一个由Microsoft开发的自动化测试框架，支持多浏览器测试，且具备高效的性能。
  • Puppeteer：由Google开发的Node库，主要用于Chrome浏览器的自动化测试。

现在流行使用 Playwright 来写 E2E 测试

前端E2E测试的步骤：

  1. 设置测试环境：启动应用的测试版本，通常会在测试环境中运行前端代码。
  2. 编写测试脚本：使用测试工具编写用户行为的模拟脚本，如点击按钮、输入文本、验证UI显示等。
  3. 执行测试：运行测试脚本，模拟真实用户的操作。
  4. 结果验证：检查测试结果，确保应用的各个部分能够正确地响应用户的操作，且无任何功能错误。
  5. 报告和修复：如果测试失败，根据报告的错误信息修复代码。

为什么要做前端的 E2E 测试？

  • 确保整体功能的完整性：单独的单元测试和集成测试可能无法覆盖整个应用的业务流程，而E2E测试通过模拟真实的用户行为，能确保前后端各部分的集成效果。
  • 提高用户体验：E2E测试能够提前发现并修复界面交互上的问题，避免用户在真实环境中遇到问题。
  • 自动化回归测试：在频繁发布新版本时，E2E测试能够帮助自动化检测系统的回归问题。

总的来说，前端 E2E 测试是确保前端应用功能与用户需求相符的一个重要环节，它关注的更多是从用户的角度来检验应用是否按预期工作。

前端E2E测试是非常重要的，它可以保证产品的稳定运行

Visual Regression Testing

视觉回归测试（Visual Regression Testing）是指通过对比应用的不同版本之间的界面视觉差异，确保 UI 在开发、更新或修复过程中没有出现不期望的变化。这种测试方法主要用于发现那些难以通过传统的功能性测试捕获的视觉问题，如布局错乱、颜色变化、字体变化等。

视觉回归测试的主要流程：

  1. 初始化基准（Baseline）截图：

    • 在测试的初始阶段，首先需要捕获当前应用的“基准”截图。这些截图应该涵盖应用的关键页面或组件，确保测试的广泛性。
    • 基准截图需要在稳定的环境下生成，确保没有干扰因素（如分辨率、浏览器版本等）。

  2. 开发和更改（开发新功能或修复 bug） ：

    • 开发人员在基准截图的基础上进行开发工作（如新增功能、修复 bug 或调整 UI）。
    • 这些开发更改可能会影响到 UI，尤其是在页面布局、样式、颜色等方面。

  3. 生成新截图：

    • 在更改完成后，再次捕获新版本的截图。这些截图应与基准截图相同，确保覆盖的页面、组件和分辨率一致。
    • 新截图的生成通常是在测试环境中进行的，以避免生产环境的波动影响测试结果。

  4. 对比截图：

    • 对比基准截图和新截图，检查它们之间的视觉差异。
    • 对比过程可以通过专门的工具自动完成，如 Percy、BackstopJS 或 Applitools 等。它们通常会高亮显示任何差异，帮助开发人员快速定位问题。

  5. 评估差异：

    • 根据测试工具的输出，开发团队可以评估视觉差异是否是预期中的。例如，某些变化可能是故意的（如新的 UI 设计），而其他变化则可能是无意的 bug 或破坏性更改。
    • 一些测试工具提供了差异阈值设置功能，允许开发团队定义可接受的视觉差异范围（如容忍微小像素差异）。

  6. 修复问题：

    • 如果发现了不希望的视觉差异，开发人员需要分析原因并进行修复。这可能涉及样式调整、布局修改或前端代码修复。
    • 在修复后，需要重新进行回归测试，确保修复没有引入新的视觉问题。

  7. 集成与持续测试：

    • 视觉回归测试通常会集成到持续集成（CI）管道中，以确保每次代码更新后都能自动执行视觉回归测试。
    • 这确保了任何视觉上的回归都会被及时捕捉，而不会在生产环境中造成问题。

视觉回归测试的工具：

  • Percy：一个自动化的视觉回归测试平台，支持与 CI/CD 流程集成。
  • BackstopJS：一个开源工具，支持基于截图的视觉回归测试，适用于任何 Web 应用程序。
  • Applitools：提供 AI 驱动的视觉回归测试，能够智能地检测并报告界面差异。
  • Storybook：与视觉回归测试工具（如 Percy）集成，用于测试 React 组件的 UI 变化。

视觉回归测试的解决方案主要有两种，第一种是利用webdriver，第二种使用playwright。笔者推荐使用playwright去做

上面提到的单元测试/集成测试/E2E测试和视觉回归测试的四种测试都要配置到CI中，每一次代码改动都需要进行代码把关

Github/Gitlab/Gitee/Gitea

GitHub、GitLab、Gitee 和 Gitea 都是 Git 仓库托管平台，用于代码托管、版本控制和团队协作。它们提供了类似的功能，但在一些细节上有所不同，尤其在部署方式、功能、使用场景等方面。

简单介绍：

  1. GitHub：

    • 全球最受欢迎的开源代码托管平台，提供强大的协作功能，广泛应用于开源项目和私有项目。
    • 支持公共和私有仓库，提供 Git 仓库托管、持续集成/持续部署（CI/CD）、问题跟踪、项目管理等功能。
    • GitHub Actions 提供 CI/CD 服务。

  2. GitLab：

    • 一个功能全面的 DevOps 平台，除了 Git 仓库托管，还提供从开发到生产的整个软件生命周期管理（如 CI/CD、监控、部署等）。
    • GitLab 提供自托管和 SaaS 服务，功能较 GitHub 更加全面，特别是在 DevOps 和 CI/CD 流程中。

  3. Gitee：

    • 由开源中国（OSChina）推出的代码托管平台，主要面向中国市场，具有较好的国内访问速度。
    • 提供类似 GitHub 的代码托管和协作功能，支持 Git 仓库、问题跟踪、CI/CD 等功能。

  4. Gitea：

    • 一个轻量级的 Git 仓库托管平台，适用于小型团队或个人，支持自托管。
    • Gitea 是开源的，并且资源消耗较小，适合在资源有限的情况下运行。它的界面和功能都比较简洁，常用于小型团队或个人项目的托管。

各平台的区别：

特性GitHubGitLabGiteeGitea
主要定位开源代码托管与协作平台全面的 DevOps 平台，支持 CI/CD中国本土的代码托管平台轻量级的自托管 Git 平台
是否支持自托管不支持自托管（提供 GitHub Enterprise）支持自托管（GitLab CE & EE）不支持自托管支持自托管
托管服务公共和私有仓库公共和私有仓库公共和私有仓库公共和私有仓库
CI/CD 支持GitHub Actions内置 CI/CD支持 CI/CD（但功能较简单）支持 CI/CD（通过插件）
社区活跃度最大的开源社区，全球化强大的社区，尤其在 DevOps 领域主要面向国内开发者小众社区，适合小型团队或个人使用
集成工具GitHub Actions、第三方工具（如 Travis CI）GitLab CI、Kubernetes、Jenkins 等支持集成第三方 CI 工具支持与外部工具集成（如 Jenkins、Travis）
项目管理功能Issues、Projects、DiscussionsIssues、Boards、Milestones、WikiIssues、Pull Requests、WikiIssues、Milestones、Labels、Wiki
开源与否非开源（私有版本为 GitHub Enterprise）GitLab CE（开源），GitLab EE（商业版）开源，提供免费版和企业版开源
目标用户开源社区开发者、大型企业开发者企业级用户、DevOps 工程师中国开发者，面向国内市场小型团队、个人开发者、简易自托管需求者
语言支持多语言（支持全球开发者）多语言（支持全球开发者）中文为主（但支持多语言）多语言（支持全球开发者）
性能与资源需求大型平台，资源消耗较大中型平台，资源消耗较大轻量级，性能较好（国内访问快）轻量级，资源消耗小
界面/使用体验用户友好，功能丰富界面功能全面，稍显复杂界面简洁，优化国内使用体验简洁，资源消耗小，适合快速部署

总结：

  • GitHub 适合开源项目，全球开发者社区最活跃，但不支持自托管。
  • GitLab 提供更全面的 DevOps 管理和 CI/CD 支持，适合企业级用户并支持自托管。
  • Gitee 适合国内开发者，提供良好的国内访问体验，并支持私有和公共仓库。
  • Gitea 是一个轻量级的 Git 仓库平台，适合需要自托管且对资源消耗要求较低的小型团队和个人。

相信各位小伙伴最熟悉的应该是GitHub，GitHub除了代码托管外，还提供非常丰富的其他功能，比如下文讲到的GitHub CI/CD等

Pull Request

Pull Request（PR） 是一种协作开发流程中用于合并代码的机制，常见于 Git 版本控制系统中（例如 GitHub、GitLab、Bitbucket 等平台）。开发者通过创建一个 PR 来请求将自己在某个分支上的更改合并到另一个分支，通常是主分支（main 或 master）或开发分支。

PR 的基本流程：

  1. 开发者创建一个分支：开发者首先从主分支（或其他合适的分支）创建一个新的分支，进行某项功能的开发或 bug 修复。
  2. 提交代码到分支：开发者在这个分支上进行代码修改，并将更改提交到版本控制系统中。
  3. 创建 Pull Request：开发者完成修改后，创建一个 PR，请求将自己分支的更改合并到目标分支（如主分支）。
  4. 代码审核（Code Review） ：项目的其他开发者（通常是团队成员或项目维护者）会查看 PR 中的代码更改，并进行审核。
  5. 评论和讨论：如果代码存在问题或需要改进，审查者可以在 PR 中评论，开发者根据反馈进行修改。PR 提供了讨论和交流的空间，帮助团队更好地协作。
  6. 合并（Merge） ：一旦代码审核通过并解决了所有问题，PR 就可以合并到目标分支中。通常，PR 会通过平台的界面进行合并操作，也可以使用命令行完成。

PR 的关键功能和优点：

  • 代码审查：通过 PR，团队成员可以互相审核彼此的代码，发现潜在问题，保持代码质量。代码审查有助于提高代码的可维护性、可读性和减少错误。
  • 讨论与协作：PR 提供了一个集中讨论代码变更的地方，开发者可以在此讨论设计、实现方案、技术细节等，提高团队协作效率。
  • 持续集成（CI）和自动化测试：PR 创建时，通常会触发自动化构建和测试，帮助开发者检查代码更改是否会破坏现有功能。很多项目配置了 CI 工具（如 Jenkins、GitHub Actions、GitLab CI）来自动进行构建和测试。
  • 版本控制：PR 使得团队能够更容易地跟踪不同分支之间的变更历史，清晰地记录每次代码的合并和变动。
  • 避免冲突：PR 通过分支管理避免了直接在主分支上开发的风险，使得不同开发者的工作可以并行进行，减少了代码冲突。

PR 常见的工作流：

  • Fork & PR：在开源项目中，开发者常常先 fork 一个项目的仓库到自己的账户中，做完修改后，通过提交 PR 将更改推送回原仓库。这种方式常见于 GitHub 等平台的开源项目。
  • Feature Branch Workflow：开发者为每个新特性或修复创建一个独立的分支，开发完成后通过 PR 将其合并到主分支。这个工作流非常适合团队开发，可以保持主分支的稳定性。
  • Gitflow Workflow：Gitflow 是一种基于分支的工作流，通常会使用不同的分支来管理功能开发、版本发布和修复。PR 是将功能分支合并到主分支或开发分支的常见方式。

PR 的合并方式：

  • Merge Commit：通过一个额外的合并提交将分支合并到目标分支，保留合并历史。
  • Squash and Merge：将 PR 的所有提交合并成一个提交后再合并到目标分支。这有助于保持主分支的提交历史干净。
  • Rebase and Merge：通过将目标分支的最新提交应用到当前分支的基础上，使得 PR 变得像是在目标分支上直接开发的，避免了合并提交的产生。

总结：

Pull Request 是一个非常重要的协作工具，帮助开发团队保持代码质量、追踪变更历史，并通过审查和讨论提升代码的质量和团队的协作效率。在现代软件开发流程中，PR 已经成为必不可少的一部分。

GitHub CI/CD

GitHub CI/CD 是 GitHub 提供的一种持续集成（CI）和持续部署（CD）服务。它允许开发者自动化代码的构建、测试、部署等过程，使得开发团队能够高效地进行版本控制、测试和发布。GitHub 的 CI/CD 功能通常通过 GitHub Actions 来实现。

GitHub CI/CD

GitHub Actions 是 GitHub 提供的 CI/CD 服务，它允许你自动化代码的构建、测试、部署等过程。GitHub Actions 使得 CI/CD 流程能够直接集成到 GitHub 仓库中，开发者无需依赖外部 CI/CD 工具。

GitHub Actions 的主要优点

  1. 集成紧密：GitHub Actions 集成在 GitHub 中，开发者无需跳转到外部 CI/CD 工具，直接在 GitHub 仓库中设置和查看工作流。
  2. 高度可定制：你可以自定义工作流、任务、步骤，甚至创建自己的 Action，满足各种不同的需求。
  3. 自动化与并行执行：支持并行执行任务，可以同时构建、测试多个平台或环境，提高效率。
  4. 易于配置：通过简单的 YAML 文件来配置 CI/CD 流程，格式简洁且易于理解。
  5. 集成 GitHub Marketplace：GitHub Actions 与 GitHub Marketplace 紧密集成，可以直接使用数千个现成的 Actions，快速集成第三方工具（如 AWS、Docker、Slack 等）。
  6. 免费额度：对于公共仓库，GitHub Actions 是免费的。对于私有仓库，GitHub 提供了免费额度，超出部分需要付费。

GitHub CI/CD 使用场景：

  1. 自动化构建和测试：每次代码提交后，自动化构建和测试可以确保新提交的代码不会破坏现有功能，保持代码质量。
  2. 自动化部署：当代码通过测试后，可以自动部署到测试、预生产或生产环境，简化发布流程。
  3. 集成第三方工具：例如将测试结果发送到 Slack、将构建结果上传到 Docker Hub、将日志发送到监控平台等。
  4. 开源项目自动化：开源项目通常需要频繁地构建和测试代码，GitHub Actions 使得这些操作更容易和高效。

总结：

GitHub CI/CD（通过 GitHub Actions）是一个强大的自动化工具，可以帮助开发者在 GitHub 仓库中直接实现持续集成、持续交付和持续部署。它提供了灵活的工作流管理、并行执行任务和自动化部署的功能，极大地提升了开发和发布效率，特别适合与 GitHub 仓库紧密集成的项目。

Docker

2025年了，前端开发人员也需要掌握Docker技术

Docker 是一个开源的容器化平台，它允许开发者将应用程序及其依赖打包到一个“容器”中。容器是一种轻量级的、可移植的、和操作系统隔离的运行环境，确保应用程序在不同环境下都能以相同的方式运行。

Docker 主要解决的问题是环境不一致性问题：传统的开发流程中，应用在开发环境、测试环境和生产环境中可能因为依赖版本、操作系统配置等问题而表现不同，而 Docker 则通过容器化技术使得应用在任何环境下都能保持一致。

作为前端工程师需要学习的 Docker 知识：

虽然 Docker 最初是为后端开发和运维设计的，但作为前端工程师，学习 Docker 也会给你带来很多便利，尤其是在以下几个方面：

  1. 理解 Docker 镜像和容器的基础：

    • 学习如何构建自己的镜像，理解镜像与容器之间的关系。
    • 理解 Dockerfile 的结构，学会如何创建一个合适的 Dockerfile 来构建前端应用的镜像。

  2. 容器化前端应用：

    • 学会将前端应用（如 React、Vue、Angular 等）容器化，使用 Docker 来打包前端应用，确保开发环境与生产环境的一致性。
    • 了解如何在 Docker 容器中运行前端构建工具，如 Webpack、Parcel 等。

  3. Docker Compose：

    • 学会使用 Docker Compose 来管理多容器的应用。例如，你可能需要一个前端容器和一个后端 API 容器，或者使用数据库（如 MySQL 或 MongoDB）。
    • 使用 docker-compose.yml 文件来配置这些服务的环境，方便开发和测试。

  4. 跨平台一致性：

    • 使用 Docker 来确保前端应用在不同平台（如 macOS、Linux、Windows）上具有一致的开发环境，解决因为操作系统差异导致的 “它在我机器上能跑”的问题。

  5. CI/CD 集成：

    • 在 CI/CD 流程中使用 Docker 进行前端自动化构建和测试。前端工程师可以在 Docker 容器中构建和测试代码，确保构建过程的可靠性。
    • 将 Docker 集成到 Jenkins、GitLab CI、GitHub Actions 等自动化构建工具中，以实现自动化部署。

  6. 调试与日志：

    • 学习如何使用 Docker 容器调试前端应用，检查容器中的日志，排查问题。Docker 容器提供了非常方便的命令行工具来查看容器的输出和日志。

  7. 前端开发环境的容器化：

    • 将前端开发环境（包括 Node.js、npm、yarn 等工具）容器化，确保开发人员可以在任何机器上获得相同的开发环境配置。
    • 使用 Docker 运行本地开发服务器（如开发时的 Webpack Dev Server），避免环境不一致导致的开发问题。

  8. 部署静态资源：

    • 将前端构建后的静态资源（如 HTML、CSS、JavaScript 文件）容器化，并通过 Docker 部署到生产环境中。

  9. 自动化测试：

    • 在 Docker 容器中进行端到端（E2E）测试，例如使用 Cypress 或 Selenium 进行浏览器测试，确保前端应用在不同环境下都能正常运行。

作为一名前端工程师，起码会购买云服务主机，域名，在云主机上安装docker，使用Nginx部署前端项目

Jenkins

Jenkins 是一个开源的自动化服务器，用于持续集成（CI）和持续交付（CD）过程。它可以帮助开发团队自动化构建、测试、部署等任务，从而提高开发效率和软件质量。Jenkins 主要用于自动化软件开发生命周期中的各个环节，尤其是在代码的构建、测试和部署过程中。

Jenkins 的核心功能：

  1. 持续集成（CI） ：

    • Jenkins 可以自动化地将开发者提交的代码集成到共享的版本控制仓库（如 Git）中。每当有新代码提交时，Jenkins 会自动拉取最新代码、编译、运行测试，并生成构建结果。

  2. 持续交付（CD） ：

    • Jenkins 还支持持续交付功能，将构建后的代码自动部署到测试环境或生产环境。通过自动化部署过程，减少手动操作和人为错误。

  3. 自动化测试：

    • Jenkins 可以集成自动化测试框架（如 JUnit、Selenium、Cypress 等），自动执行单元测试、集成测试和端到端测试，确保代码质量和应用稳定性。

  4. 可扩展性：

    • Jenkins 拥有丰富的插件生态系统，几乎可以与所有开发工具、版本控制系统、测试框架、云平台等进行集成。通过插件，Jenkins 可以支持自定义构建步骤、通知方式、代码质量检查等。

  5. Pipeline（流水线） ：

    • Jenkins 引入了流水线（Pipeline）概念，可以通过编写 Pipeline 脚本（通常是 Groovy 语言）来定义复杂的构建、测试和部署过程。流水线可以使自动化流程更加灵活和可控。

  6. 分布式构建：

    • Jenkins 支持分布式构建架构，可以通过配置多个 构建节点（slave）来将任务分配到不同的机器上，从而加快构建速度和扩展能力。

笔者认为前端工程师有必要了解Jenkins的使用

APM

当项目部署上线后，需要使用一系列工具监控产品的运行情况

APM是用于监控和管理应用程序性能的技术，旨在确保应用程序的可用性、稳定性和响应速度。APM 工具可以帮助开发团队和运维人员实时检测和诊断应用程序中的性能瓶颈，快速定位和解决问题，从而提高用户体验和业务效率。

New Relic、Sentry 和 Dynatrace 都是流行的应用性能管理（APM）和监控工具，它们帮助开发团队监控和诊断生产环境中的应用程序和系统。每个工具的焦点和功能有所不同，但它们都旨在提高应用程序的稳定性、性能和用户体验。

工具简介：

  1. New Relic：

    • New Relic 是一个全面的 应用性能管理（APM）工具，帮助团队监控应用的性能、实时获取健康状况、日志和用户行为等信息。它适用于多种技术栈（如 Java、Node.js、Python、Ruby 等），并支持全栈监控，包括前端、后端和基础设施。
    • 主要功能：应用性能监控、分布式追踪、日志管理、基础设施监控、实时分析。

  2. Sentry：

    • Sentry 是一个开源的错误跟踪平台，主要聚焦于 错误日志管理 和 异常跟踪。它帮助开发者实时捕获和跟踪应用中的错误、异常和崩溃，尤其是在生产环境中。Sentry 允许开发者快速定位问题，减少应用的停机时间。
    • 主要功能：错误和异常监控、实时错误报告、错误上下文分析、性能监控。

  3. Dynatrace：

    • Dynatrace 是一个 全栈智能监控平台，为企业提供综合的 应用性能管理（APM） 、基础设施监控 和 云监控。它不仅能够监控应用程序的性能，还能深入到每个交易、服务、容器和虚拟机的监控。Dynatrace 使用人工智能（AI）驱动的分析来自动检测异常。
    • 主要功能：自动化监控、分布式追踪、深度分析、智能日志、AI 驱动的异常检测、云原生监控。

工具的主要区别：

特性New RelicSentryDynatrace
主要功能应用性能管理（APM）、基础设施监控、日志管理错误和异常跟踪，性能监控应用性能管理（APM）、基础设施监控、云监控
聚焦领域全栈性能监控、分布式追踪错误捕获、异常跟踪和调试全栈监控、AI 驱动的智能分析
支持的技术栈支持多种技术栈，如 Java、Node.js、Python、Ruby 等JavaScript、Python、Django、React 等支持多种语言和平台，尤其在云原生环境中
错误追踪支持，但以性能监控为主强项，专注于实时错误跟踪和异常报告支持，但主要以应用性能为主
分布式追踪支持，追踪请求和事务的完整生命周期部分支持，但侧重于异常跟踪完全支持，深入到每个服务、交易和容器
实时监控提供实时性能数据，应用、基础设施、用户行为等仅提供错误和异常的实时报告提供实时的性能和健康状况监控
日志管理提供日志管理功能，集成日志分析无专门的日志管理功能提供智能日志管理，自动识别问题
AI 和自动化无 AI 自动化分析无 AI 自动化分析内置 AI 驱动的智能监控和异常检测
自动化根因分析提供自动根因分析，但不如 Dynatrace 强大不支持强大的自动根因分析，AI 驱动的智能分析
部署方式SaaS 和自托管两种方式云端服务SaaS 或自托管，并支持混合部署
适合的使用场景广泛适用于各种应用的全栈监控和性能管理主要用于开发中的错误跟踪和异常报告大型企业、云环境和微服务架构中的全栈监控
价格按使用量计费（基于指标和用户数）免费版和企业版，企业版按使用量计费高价，适用于大企业，按使用量计费

总结：

  • New Relic 是一个全面的 APM 平台，专注于应用性能和基础设施监控，适用于全栈监控，尤其适合大规模应用。
  • Sentry 是一个 错误跟踪平台，专注于 异常监控，适用于捕捉和处理应用中的错误和崩溃，特别适合开发者进行问题调试。
  • Dynatrace 提供强大的 AI 驱动的全栈监控，不仅监控应用性能，还可以深入到云原生架构、容器、微服务等多个层级，适用于企业级应用和复杂环境。

适用场景：

  • 如果你的主要需求是 应用性能监控 和 分布式追踪，并且需要全栈支持，New Relic 和 Dynatrace 是较好的选择。
  • 如果你主要关注 错误跟踪 和 异常管理，尤其是开发阶段，Sentry 更为合适。

这些工具之间的选择很大程度上取决于你的项目需求，团队规模以及你所在的技术栈。APM 产品有很多，大部分产品需要付费才能使用全部功能，根据业务需求和公司规定选择合适的工具

avatar
文章
阅读
粉丝