最初对前端的观感是眼花缭乱，各种各样的工具链以及其对应的配置文件、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 代码。前端的运行环境更多的是在用户这边，这点不同于后端能比较自由地调整服务器运行环境，这可能就是前端缝缝补补的原因吧。
- 新 API：使用 Polyfill（填充物），为其实现缺少的 API，例如 core-js 库，就实现了 Array 的 flatMap 方法，这样在旧版本的 Node 环境，也可使用该方法。
- 新语法：例如 Promise，对于这样的语法糖，就无法直接为其编写方法，需要转换代码，有点类似翻译，通过 regenerator 库可以将含有 Promise 的代码转换为向后兼容的代码。
有很多这样的库用于解决某个特定的兼容性问题，一个个导入很麻烦，所以就有了 Babel，可以通过 Babel 的插件整合这些转换代码的库，需要安装对应的 Babel 插件依赖 并在 babel.config.js 中配置 plugins。
CSS 工具链
CSS 语法缺失（逻辑、函数等等），无法进行复杂的操作，所以就有了 CSS 预编译器：Less, Sass 等等的，与 JS 的处理方式一样，可以通过工具对其进行转换，转换为最朴素的 CSS，这样就没有兼容性的问题。解决了兼容性问题还需要解决 CSS 本身的问题。
- 浏览器前缀 (vendor prefixes)：类似 -webkit- 开头的样式，可以通过 autoprefixer 来自动添加浏览器前缀以确保网页在不同浏览器中的兼容性。
- 压缩：减少 CSS 文件的大小，从而提高网页加载速度，相关的库 cssnano。
- 剪枝：移除没有用到的 CSS，相关的库：purgecss。
- 类名冲突：通过 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
