JavaScript项目依赖与构建管理需明确分工、约束安装、固化流程：用dependencies/devDependencies隔离职责，scripts封装命令，lock文件锁定版本，优先使用成熟脚手架而非从零配置。
JavaScript 项目依赖与构建工具不是靠“教程”堆出来的，而是靠明确角色分工、约束安装行为、固化执行流程来管住的。直接上手 npm / pnpm + scripts + 简单配置就能覆盖 80% 场景，不需要一上来就配 Webpack 或引入 Turborepo。
用 package.json 的 dependencies 和 devDependencies 做职责隔离
依赖分类错位是后期构建失败、体积膨胀、CI 报错的常见源头。比如把 webpack 放进 dependencies，会导致生产环境也安装它；把 lodash 放进 devDependencies，则运行时可能报 Cannot find module 'lodash'。
-
dependencies：运行时真正需要的包（如react、axios、express） -
devDependencies：仅开发/构建阶段需要的（如typescript、jest、vite、eslint） - 用
npm install <pkg></pkg>默认进dependencies；加--save-dev或-D才进devDependencies - pnpm 更严格：默认只进
devDependencies，装运行时依赖必须显式加--prod
用 package.json#scripts 封装构建命令，别裸写 CLI
把构建逻辑藏在 scripts 里，不只是为了少打字，更是为了统一入口、避免本地环境差异。比如直接跑 vite build 可能因本地全局安装版本和项目不一致而失败，但 npm run build 总是调用 node_modules/.bin/vite 里的那个。
- 所有常用操作都应有对应 script：
start、build、test、lint、prepublishOnly - 脚本里避免硬编码路径或参数，用
$npm_config_<key></key>传参（如"build:prod": "vite build --mode production"→"build": "vite build --mode $npm_config_mode"） - 多个步骤用
&&连接，但超过 3 步建议拆成子 script，方便复用和调试
锁死依赖版本用 package-lock.json 或 pnpm-lock.yaml，别删
删 lock 文件等于放弃可重现构建。哪怕你用的是 ^1.2.3，不同时间 npm install 可能装出两个语义化版本完全不同的 1.x 包——尤其当上游发了带 bug 的补丁版时。
立即学习“Java免费学习笔记（深入）”；
- npm 自动生成
package-lock.json，必须提交到 Git；pnpm 生成pnpm-lock.yaml，同样不可忽略 - 不要手动编辑 lock 文件，它不是配置项，是安装快照
- CI 环境务必用
npm ci（不是npm install），它跳过解析，直接按 lock 文件精确还原，更快更稳 - 升级依赖时，用
npm update <pkg></pkg>或pnpm update <pkg></pkg>，而不是删 node_modules 重装
构建工具选型：先看 create-<xxx>-app</xxx>，再看要不要自定义
Vite、Next.js、Remix、Create React App 这些脚手架已经内置了合理默认：模块解析、HMR、代码分割、环境变量注入、生产优化。自己从零配 Webpack 或 Rollup，90% 情况下只是重复造轮子，还更容易配错 sourcemap 或 tree-shaking。
- 新项目优先用
npm create vite@latest或npx create-next-app@latest - 只有当你需要特殊插件（如定制资源内联）、非标打包目标（如 WebAssembly 模块导出）、或已有复杂构建逻辑迁移时，才考虑自定义构建配置
- 自定义前先确认：这个需求是不是已有插件支持？比如
vite-plugin-svg-icons比手写 rollup 插件安全得多
依赖和构建最麻烦的地方不在“怎么配”，而在“谁改的、为什么改、改完有没有验证”。一个没被 prepublishOnly 拦住的本地 console.log，可能比 Webpack 配置错误更难排查。
