如何管理Javascript中的依赖_怎样使用Javascript模块打包工具?

JavaScript依赖管理核心是代码加载时机与方式,浏览器原生ESM限制多(需type="module"、带后缀路径、不支持node_modules直接引入),故真实项目必须用Webpack或Vite等打包工具处理模块解析、tree-shaking等。

JavaScript 依赖管理的核心不是“装多少包”,而是“谁在什么时候、以什么方式加载了什么代码”。现代项目几乎必须用模块打包工具,否则 import 会直接报错,node_modules 中的包也无法被浏览器执行。

为什么 import 在浏览器里直接写会报错?

原生浏览器只支持 ES 模块(ESM),但有硬性限制:必须显式声明 type="module",且所有 import 路径必须带后缀(如 ./utils.js),不能省略;同时不支持 importnode_modules 直接引入(例如 import _ from 'lodash' 会 404)。

  • 浏览器原生 ESM 不解析 package.jsonexportsmain
  • 没有自动路径别名、无 node_modules 查找逻辑
  • 无法处理 CommonJS(require())或 JSON 导入等 Node 特性

所以,光靠浏览器跑 import 只适用于极简静态模块,真实项目必须走打包流程。

npm install 装的是什么?devDependenciesdependencies 怎么分?

npm install 把包下载到 node_modules,但只是“存着”,不会自动接入代码。是否真正参与构建/运行,取决于你是否在源码中 importrequire 它,以及打包工具是否将其纳入输出。

  • dependencies:运行时必需,比如 reactaxios —— 打包后仍需存在于最终 JS 中
  • devDependencies:仅开发期用,比如 webpackeslint@vitejs/plugin-react —— 不会进入生产产物
  • 混淆点:typescriptdevDependency,但 @types/react 也是,因为类型只用于编译检查,不产出 JS

Vite 和 Webpack 做的事本质一样,但启动和构建逻辑完全不同

Vite 利用浏览器原生 ESM,在开发时按需编译单个文件(冷启动快);Webpack 则是先全量构建依赖图,再启动服务(启动慢,但兼容性更可控)。两者都解决同一个问题:把 import 'lodash' 这种语句,转成浏览器能加载的真实路径,并处理循环依赖、tree-shaking、代码分割等。

import { debounce } from 'lodash-es';

export function setupSearch() {
  const input = document.getElementById('search');
  input.addEventListener('input', debounce(handleSearch, 300));
}

上面这段代码在 Vite 中可直接运行;在 Webpack 中也行,但若你用的是 lodash(非 lodash-es),Webpack 需额外配置 babel-plugin-lodash 或 alias 才能避免打包整个库 —— 这就是模块格式(CJS vs ESM)对打包结果的直接影响。

不打包也能跑 import?可以,但代价是放弃灵活性

deno runnode --experimental-modules 确实能直接执行 ESM,但它们不处理:

  • 路径别名(@/componentssrc/components
  • CSS / 图片等非 JS 资源导入(import './style.css'
  • 环境变量注入(import.meta.env.VITE_API_URL
  • 动态 import() 的代码分割与预加载提示

也就是说,跳过打包工具 = 主动放弃工程化能力。小脚本可以试,中大型项目会卡在第 3 天的样式加载失败或环境变量读不到上。