理解前端工程化

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

TL;DR

工程化的目的：降低开发成本提高开发效率

方式：解决前端三大件（HTML, CSS, JS）存在的问题并对其进行增强，JS 通过 Babel 而 CSS 可以通过 Sass, Less, PostCSS 等工具实现进行增强，并且保证输出向后兼容的的 JS 或 CSS 代码

模块化、包管理

分解聚合：拆分复杂任务，降低复杂度（分而治之）

模块化解决问题：1. 全局污染 2. 依赖管理等等

JS 模块化标准（常用）：1. CommonJS （Node 标准）2. ES modules（JavaScript 官方标准模块化方案）
实现：1. 浏览器只支持 ESM 2. Node 和构建工具上面两种标准都支持

包 (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。这样还是很麻烦，所以我们可以直接使用 Babel 的预设，其中最常用的就是：@babel/preset-env，安装依赖以后完成以下的 babel.config.js 配置，即可开箱即用：

js 复制代码

// common js
module.exports = {
    presets: [
        // 预设名称 & 配置
        ['@babel/preset-env', {
            targets: {
                edge: '17',
                firefox: '60',
                chrome: '67',
                safari: '11.1'
            },
            // 按需导入 polyfill，未使用的 API 不导入
            useBuiltIns: 'usage',
            corejs: '3.37.0',
        }]
    ]

    // 插件的配置方式
    // plugins: [
    //     '@babel/plugin-transform-optional-chaining'
    // ]
}

有了这种思维之后，就可以通过 转换代码 的方式任意地增强 JS 的能力，就像：JSX 和 TypeScript ，它们最终还是会被编译为纯 JS 代码

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

js 复制代码

module.exports = {
  map: false,
  plugins: {
    tailwindcss: {},
    'postcss-preset-env': {},
  },
};

构建工具和脚手架

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

模块化管理：使得项目结构清晰、依赖关系明确
打包编译：将各个模块按照其依赖关系进行打包编译，将它们转换为浏览器可识别的静态资源文件
资源优化：压缩 JavaScript、CSS、图片等文件，以减小文件体积，提高加载速度
代码分割：实现按需加载，提高页面加载性能
开发服务器：自动编译并运行服务（热更新），便于开发
Source Map：存储了编译后代码与源代码之间的映射关系，便于调试代码

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

参考资料

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