一、模块化体系:ESM vs CJS 深入
1.语法与静态性
(1)ESM:静态语法,可被打包器做 Tree-shaking
export function play() {}
export default ...
import { play } from './mod.js'
(2)CJS:运行时 require() , 分析能力弱,不利于 Tree-shaking
2.Node 解析规则
(1)package.json 有 "type": "module" → .js 当 ESM,CJS 用 .cjs
(2)没有"type":"moudle" → .js 当 CJS,ESM 用 .mjs
(3)ESM模式下导入需带后缀:import './mod.js'
3.互操作常见坑
(1)从 CJS 默认导出到 ESM: import pkg from 'cjs-pkg' 可能需要 default ,视包而定
(2)ESM的顶层 await import() 可用于懒加载(浏览器需<script type="module">)
4.浏览器直载 ESM:<script type="module" src="/src/index.js"> 可工作,但生产一般仍用打包器做压缩/缓存/分隔
二、npm 与依赖管理
1.依赖分层
(1) dependencies : 运行时要用(浏览器/Node 产物实际需要)
(2) devDependencies:仅开发/构建/测试(如 webpack 、typescript )
2.版本策略:^1.2.3:允许次/补丁更新;~1.2.3:只允许补丁更新。线上稳定期可固定版本
3.脚本编排: build/dev/test/lint/format 统一入口,CI 直接调用,幂等可重试
4.锁文件:固定依赖树,保证本地与 CI 一致性;发布或回归时避免“幽灵问题”
三、打包器的价值与核心概念
1.为什么要打包
(1)体积与性能:压缩、去未用代码、缓存友好命名
(2)兼容性与生态:TS/SCSS/图片/字体/JSON 等统一处理与优化
(3)架构能力:代码分割(按需)、预渲染、资源内联/懒载
2.Tree-shaking:需要 ESM 静态导入;包需标记 sideEffects:false(或为有副作用文件列白名单)
3.代码分割
(1)静态多入口:
entry: { app: '...', admin: '...' }
(2)动态导入:
import('./scenes/scene1_birth')
→ 自动生成独立 chunk
4.缓存策略
(1)文件名包含 [contenthash] ,浏览器长期缓存;HTML/入口负责指向最新名
(2)依赖库与业务分离提升复用缓存命中率
四、Webpack 入门到实践要点
1.最小依赖
webpack
webpack-cli
typescript
ts-loader
2.基本配置点
entry/output
filename: [name].[contenthash].js
clean: true
resolve.extensions: ['.ts', '.js']
module.rules
ts-loader
.ts
optimization.splitChunks: { chunks: 'all' }
3.动态导入分包
ts
// 假设放在 src/index.ts document.querySelector('#playScene1')?.addEventListener('click', async () => {const mod = await import('./scenes/scene1_birth'); // 产出独立 chunkmod.play(); });
4.副作用控制:
package.json
"sideEffects": false
5.资源处理:简单可使用 asset/resource (内置)或拷贝插件,把 assets/ 拷到 build/assets/
6.HTML输出:html-webpack-plugin 自动注入最新 hash 脚本,避免手改文件名
五、Vite / esbuild 对比
1.Vite (推荐开发体验)
(1)Dev:原生 ESM + 极速 HMR
(2)Build:走 Rollup,分包/CSS/资源生态成熟
(3)TS支持好、配置轻
2. esbuild (极快):打包速度快;复杂生态与 HTML 注入等需额外方案
3.Webpack(覆盖面最全):复杂/历史项目强;配置相对繁琐,Dev 体验不如 Vite