环境准备:Node.js 与 npm/yarn/pnpm 安装、版本管理工具 nvm、项目初始化与 package.json

好,咱们正式开始动手。这一章我会带你搭好开发环境。别小看这一步,我在项目里见过太多因为环境不一致导致的诡异 bug——「我本地能跑啊,怎么你那就报错?」说白了,就是环境没统一。

咱们的目标很明确:装好 Node.js,配好包管理器,学会用 nvm 切版本,最后初始化一个项目,把 package.json 吃透。走完这一章,你的电脑就能跑任何前端项目了。

2.1 Node.js 与 npm:前端基建的基石

Node.js 是什么?简单说,它让 JavaScript 跑在了服务器上。但对我们前端来说,它更重要的身份是「工具链的运行时」——Webpack、Vite、Rollup,全都依赖它。

npm 是 Node.js 自带的包管理器。你装好 Node.js,npm 就跟着来了。我个人习惯用 LTS(长期支持)版本,稳定,坑少。

安装方式对比

方式 适用场景 优点 缺点
官网下载安装包 新手、一次性安装 图形化,简单直接 版本切换麻烦
包管理器安装 macOS/Linux 用户 命令行,可脚本化 版本可能滞后
nvm 安装 多项目并行开发 版本随意切换 需要额外安装 nvm
我的建议:直接上 nvm。你以后同时维护两三个项目,每个项目要求的 Node 版本不一样,没有 nvm 你会疯掉。

2.2 nvm:版本管理的神器

nvm(Node Version Manager)就是 Node 版本的「遥控器」。想用 16 就用 16,想切 18 就切 18,一条命令搞定。

安装 nvm

macOS/Linux 用户,打开终端,执行:

curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.7/install.sh | bash

Windows 用户,去 nvm-windows 的 GitHub Releases 页面下载安装包。嗯,这里要注意:Windows 版的 nvm 和 macOS/Linux 版不是同一个项目,别搞混了。

装完后重启终端,验证一下:

nvm --version

如果看到版本号,说明装好了。没看到?检查一下环境变量。我曾经在一台新 Mac 上折腾了半小时,最后发现是 .zshrc 没生效——source 一下就好。

常用 nvm 命令

命令 作用
nvm ls 查看已安装的 Node 版本
nvm ls-remote 查看所有可安装的版本
nvm install 18.17.0 安装指定版本
nvm use 18.17.0 切换当前会话的 Node 版本
nvm alias default 18.17.0 设置默认版本
避坑:nvm use 只对当前终端窗口生效。新开窗口会回到默认版本。所以一定要设置 default 别名,否则每次都要手动切。

2.3 包管理器三兄弟:npm、yarn、pnpm

装好 Node.js,npm 就有了。但前端社区还有 yarn 和 pnpm。它们解决的都是同一个问题:依赖管理。但思路不一样。

核心差异

特性 npm yarn pnpm
安装速度 中等 快 极快(硬链接)
磁盘占用 高(每个项目重复下载) 高 低(全局存储 + 硬链接)
lock 文件 package-lock.json yarn.lock pnpm-lock.yaml
严格模式 否 否 是(幽灵依赖问题少)

我个人现在主力用 pnpm。为什么?因为快,而且省磁盘。你想想看,电脑上十几个项目,每个都装一遍 react、vue、lodash……那得占多少空间?pnpm 用硬链接共享,只存一份。

但如果你刚入门,用 npm 完全没问题。等遇到「依赖装不上」或者「磁盘不够了」再换也不迟。

安装 yarn 和 pnpm

npm install -g yarn
npm install -g pnpm

验证:

yarn --version
pnpm --version
关键点:一个项目里,不要混用 npm 和 yarn 的 lock 文件。团队协作时,统一用一个包管理器,否则 lock 文件冲突会让你怀疑人生。

2.4 项目初始化与 package.json

环境搭好了,咱们来初始化一个项目。打开终端,找个目录:

mkdir my-material-library
cd my-material-library
npm init -y

执行完,目录里多了一个 package.json。这就是项目的「身份证」和「说明书」。

package.json 核心字段

字段 说明 示例
name 项目名称,发布到 npm 时唯一标识 "my-material-library"
version 语义化版本号 "1.0.0"
description 项目描述 "一个材料库组件集合"
main 入口文件 "dist/index.js"
scripts 可执行命令 "build": "vite build"
dependencies 生产依赖 "react": "^18.2.0"
devDependencies 开发依赖 "vite": "^5.0.0"

安装依赖

以 pnpm 为例,安装一个组件库作为依赖:

pnpm add antd

这会在 dependencies 里加上 antd,并生成 pnpm-lock.yaml。如果加 -D 参数,就装到 devDependencies:

pnpm add -D @types/react

为什么要区分?生产依赖是运行时需要的,比如 React、Ant Design。开发依赖是构建时需要的,比如 TypeScript 类型、Vite、ESLint。打包时,开发依赖不会被包含进去。

小技巧:用 pnpm why <包名> 可以查看某个包为什么被安装。排查依赖问题时特别好用。

2.5 知识体系总览

下面这张图把本章的核心逻辑串起来了。你可以把它当作一张「环境搭建路线图」。

环境准备知识体系 环境准备知识体系 开发环境准备 Node.js 运行时 包管理器 nvm 版本管理 LTS 版本 安装方式 npm yarn pnpm 版本切换与别名 项目初始化 package.json 核心字段 name/version scripts dependencies devDependencies lock 文件 main/module

2.6 常见问题与避坑

  • 权限问题:macOS/Linux 下用 sudo npm install -g 会污染系统目录。我建议用 nvm 管理,或者配置 npm 的全局路径到用户目录。
  • node_modules 黑洞:项目大了,node_modules 可能几百 MB。用 pnpm 能省不少空间。实在不行,用 npkill 一键清理。
  • lock 文件冲突:团队协作时,lock 文件一定要提交到 Git。合并冲突时,删掉 lock 文件重新 install 是最快的办法。
  • 版本号语义:^1.2.3 允许安装 1.x.x 的最新版,~1.2.3 只允许 1.2.x。生产环境建议锁定版本,用 1.2.3 不带符号。
曾经有个坑:我接手过一个项目,package.json 里 dependencies 和 devDependencies 乱放,构建时把 babel 和 webpack 都打进了生产包。结果线上包体积大了 3 倍。所以,装依赖时想清楚:这个包是运行时需要,还是构建时需要?