前端工程化及工具链

最初对前端的观感是眼花缭乱，各种各样的工具链以及其对应的配置文件、VS Code 插件，各种技术百家争鸣，选择众多。后来才理解前端不同于后端，后端代码的运行环境相对可控，而前端代码运行在用户设备上，所以需要兼容不同的环境，而很大一部分的工具、配置都是解决兼容性的问题。

工程化的目的

工程化的目的在于降低开发成本提高开发效率。解决前端三大件（HTML, CSS, JS）存在的问题并对其进行增强，JS 通过 Babel 而 CSS 可以通过 Sass, Less, PostCSS 等工具实现进行增强，并且保证输出向后兼容的的 JS 或 CSS 代码。

模块化、包管理

模块化解决问题：1. 全局污染 2. 依赖管理 等等。JS 模块化标准（常用）：1. CommonJS（Node 标准）2. ES modules（JavaScript 官方标准模块化方案）。包（package）管理：npm（Node.js的标准包管理器），还有其他的 pnpm 和 yarn 等。

JS 工具链

JS 语言本身一直都在繁荣地发展，经常出现新的 API 和 语言特性，但是用户的运行环境（浏览器、Node等）的版本可能是五花八门的，可能会导致报错、兼容性等的问题，所以最朴素的解决方式就是把 JS 都转换为向后兼容的老版本 JS 代码。前端的运行环境更多的是在用户这边，这点不同于后端能比较自由地调整服务器运行环境，这可能就是前端缝缝补补的原因吧。

1. 新 API：使用 Polyfill（填充物），为其实现缺少的 API，例如 core-js 库，就实现了 Array 的 flatMap 方法，这样在旧版本的 Node 环境，也可使用该方法。
2. 新语法：例如 Promise，对于这样的语法糖，就无法直接为其编写方法，需要转换代码，有点类似翻译，通过 regenerator 库可以将含有 Promise 的代码转换为向后兼容的代码。

有很多这样的库用于解决某个特定的兼容性问题，一个个导入很麻烦，所以就有了 Babel，可以通过 Babel 的插件整合这些转换代码的库，需要安装对应的 Babel 插件依赖 并在 babel.config.js 中配置 plugins。

CSS 工具链

CSS 语法缺失（逻辑、函数等等），无法进行复杂的操作，所以就有了 CSS 预编译器：Less, Sass 等等的，与 JS 的处理方式一样，可以通过工具对其进行转换，转换为最朴素的 CSS，这样就没有兼容性的问题。解决了兼容性问题还需要解决 CSS 本身的问题。

1. 浏览器前缀 (vendor prefixes)：类似 -webkit- 开头的样式，可以通过 autoprefixer 来自动添加浏览器前缀以确保网页在不同浏览器中的兼容性。
2. 压缩：减少 CSS 文件的大小，从而提高网页加载速度，相关的库 cssnano。
3. 剪枝：移除没有用到的 CSS，相关的库：purgecss。
4. 类名冲突：通过 css module 来实现，相关的库：postcss-modules。

与处理 JS 的 Babel 类似，CSS 也有工具整合了上面这些工具，它就是 PostCSS，安装需要的 依赖后，还需要配置 postcss.config.js。与 Babel 类似，它也可以开箱即用，需要安装依赖并配置 postcss-preset-env。

构建工具和脚手架

开发和运行的代码不一致，开发阶段我们希望工程代码可以方便地开发维护，而在对于生产运行的代码，我们则希望它兼容性强、文件小、加载快等等。这中间就需要打包工具来进行转换，常用的打包工具有：webpack，它的主要作用：模块化管理、打包编译、资源优化、代码分割、开发服务器、Source Map。

与 Babel 和 PostCSS 相似，一旦有很多细碎的东西出现，就必然有工具可以进行整合并提供预设，对于整个代码工程来说，它就是脚手架：vue-cli, vite 等等，提供了交互式的界面辅助生成工程模版。

参考资料

ECMAScript 6 入门 - 阮一峰
工程化大师课
What is @babel/preset-env and why do I need it?
postcss 结合 tailwindcss