npm进阶（五）NPM 管理 node

这个例子定义了应用入口文件( `main` )为 `index` ，当其他应用通过 `require('test')` 引用了我们的模块时，这个 `main` 的值 `index.js` 文件被调用。脚本( `scripts` )使用`hash` 表定义了几个不同的命令。


`script.start` 里的定义的 `node server.js` 会在 `npm start` 时被调用，同样的 `npm test` 调用时对应的 `scripts.test` 里定义的命令被调用。在有些 `native` 模块需要编译的话，可以定义预编译和编译的命令。本例中还定义了应用依赖模块( `dependencies` )和开发环境依赖模块( `devDependencies` )。应用依赖模块会在安装时安装到当前模块的 `node_modules` 目录下。开发环境依赖模块主要是在开发环境中用到的依赖模块，用命令 `npm install` 或`npm link`加上参数 `—-dev` 将安装到当前模块的 `node_modules` 目录下。


大家也注意到 `package.json` 里的版本号有些是 `>= 0.6.7` 有些是 `1.x.x`，这有什么区别？`npm` 使用于语义化的版本识别来进行版本管理。并不是所有的模块都会提供向后兼容性，有时候某些模块因为某些原因导致不向后兼容。所以需要定义一些规则来保证模块能够在某些特定的版本中可用，并且保证能用最新的版本，因为那些版本总是修改了一些 `bug` 或提升了性能等。我们来看一下版本定义的字段：



> 
> **0.4.2**
> 
> 
> * 主版本( 0 )
> * 副版本( 4 )
> * 补丁版本( 2 )
> 
> 
> 


在上面 `package.json` 的定义里我们确信模块在所有的 `Nodejs 0.4`及以上和`0.5`以下版本里都能运行。依赖模块 `redis` 在所有大于或等于0.6.7的版本上都能运行，依赖模块 `ejs` 只能确保运行在0.4.2版本里，依赖模块 `express` 确保能够兼容大于或等于1.0.0并且小于2.0.0。


### 三、npm 配置


`npm` 拥有很多默认配置。可以使用这些默认配置，也可以修改这些默认配置，甚至可以在环境变量或命令行下修改这些配置。配置的权重是如下顺序定义的：


* 命令行，使用`--`为前缀的参数。比如 `--foo bar`，设定变量 `foo` 的值为 `bar` ，`--foo` 后不带值的参数，设定 `foo` 的值为 `true` 。
* 环境变量，所有 `npm_config_` 为前缀的环境变量。比如 `npm_config_foo = bar` ，设定变量 foo 为 “ bar "。
* 用户定义。所有的变量存储在 `$HOME/.npmrc` 文件里的变量。
* 全局。所有 `$PREFIX/etc/npmrc` 文件里的变量。`$PREFIX` 变量可通过 `npm prefix -g` 获取，一般默认是 `/usr/local`。
* 内置配置。通过安装时运行 `./configure` 所定义的变量。可通过命令`curl http://npmjs.org/install.sh | env npm_config_foo=bar sh` 设置。


使用配置能给我们带来很大的灵活性。比如使用 `npm install` 时，对默认的资源库地址 `https://registry.npmjs.org/` 不是很满意，可以使用下面的命令来更改资源库地址:

npm --registry “an other registry” install express

或者下面的命令

env npm_config_registry=“an other registry”
npm install express

或是对 `npm` 默认的 `vi` 编辑器不满意，直接命令 `npm set editor mate` 。`npm` 的配置可通过命令 `npm config ls` 获取。这个命令是获取修改后的配置，要获取包括默认配置的全部配置加上 `-l` 参数。


值得注意的是，开发者通过 `npm config set registry "an other registry"` 的方式修改 `registry` 这个属性值，一定要明白这个修改这个值所带来的负面效应。一旦设置了 `registry` 这个值，当你要 `publish` 一个模块，会把模块发布到修改后的资源库里，而不是原始默认的资源库。其他的资源库是原始默认的资源库的一个复制品，定时从默认的资源库取资源。一般来说，没有把其新加的模块同步到默认的资源库的能力。这样会导致发生你的模块在修改后的资源库里能够找到，而在其它的资源库里找不到的事情。


### 四、npm install 命令


`npm install`是下载`node_modules`文件夹里的依赖。


安装模块只需要 `npm install express connect` 命令带来了很大的方便。安装模块的路径分两种：


* 全局路径，也就是带上参数 `-g` 的安装模式。这个命令会把模块安装在 `$PREFIX/lib/node_modules` 下，可通过命令 `npm root -g` 查看全局模块的安装目录。 `package.json` 里定义的`bin`会安装到 `$PREFIX/bin` 目录下，如果模块带有 `man page` 会安装到 `$PREFIX/share/man` 目录下。
* 本地路径，不带 `-g` 参数。从当前目录一直查找到根目录`/`下有没有 `node_modules` 目录，有的话，模块安装到这个目录下的 `node_modules` 目录里，如果没有找到则把模块安装到当前目录 `node_modules` 目录下。`package.josn` 定义的 `bin` 会安装到 `node_modules/.bin` 目录下，`man page` 则不会安装。


那么，我们需要选择什么样的安装方式呢？全局模式可以让你不用担心找不到模块，但是，如果不需要还是尽量避免全局模式。


如果我们只是 `require('pkg')` 一个模块，我们不需要使用全局模式。


如果我们需要在命令行中调用，我们需要使用全局模式。因为这个安装把 `package.json`里 `bin` 下的定义安装到 `$PATH` 目录下。


有些模块我们既需要在命令行中调用又想 `require('pkg')` ，比如 `Coffee-script` 。那么我们可以使用全局模式安装，然后使用下一节要讲的命`令 npm link` 把它链接到本地的 `node_modules` 目录下。


不要担心 `package.json` 里 `script` 中定义的命令会不会因为不是全局安装而不能运行。比如在例子里定义的 `devDependencies` 的 `vows` 。在调用 `npm test` 时 `npm` 会`把 node_modules/.bin` 目录放到环境变量 $PATH 的最前面。


### 五、npm link 命令


对开发者而言，这算是最有价值的命令。假设我们开发了一个模块叫 test ，然后我们在 test-example 里引用这个模块 ，每次 test 模块的变动我们都需要反映到 test-example 模块里。不要担心，有了 `npm link` 命令一切变的非常容易。


首先我们需要把 test 链接到全局模式下：

cd ~/work/node/test # 进入test模块目录
npm link #创建链接到$PREFIX/lib/node\_modules

那么 test 的模块将被链接到 `$PREFIX/lib/node_modules` 下，就像我的机器上 `$PREFIX` 指到 `/usr/local` ，那么 `/usr/local/lib/node_modules/test` 将会链接到 `~/work/node/test` 下。执行脚本 `bin/test.js` 被链接到 `/usr/local/bin/test` 上。


接下来我们需要把 test 引用到 test-example 项目中来：

cd ~/work/node/test-example # 进入test-example模块目录
npm link test # 把全局模式的模块链接到本地

`npm link test` 命令会去 `$PREFIX/lib/node_modules` 目录下查找名叫 test 的模块，找到这个模块后把 `$PREFIX/lib/node_modules/test` 的目录链接到 `~/work/node/test-example/node_modules/test` 这个目录上来。


现在任何 test 模块上的改动都会直接映射到 test-example 上来。再比如假设我们开发很多应用，每个应用都用到 `Coffee-script` ：

npm install coffee-script -g # 全局模式下安装coffee-script
cd ~/work/node/test # 进入开发目录
npm link coffee-script # 把全局模式的coffee-script模块链接到本地的node_modules下
cd ../test-example # 进入另外的一个开发目录
npm link coffee-script # 把全局模式的coffee-script模块链接到本地
npm update coffee-script -g # 更新全局模式的coffee-script，所有link过去的项目同时更新了。

就像你看到，`npm link` 在开发时一个模块被多个模块引用时的应用场景非常有用。`windows` 用户会想，我这儿没有 `UNIX` 下的 `link` 工具怎么办？别担心只要你的 `Node.js` 支持 `fs.symlink` 就可用到这个特性。


### 六、其它 npm 命令


`npm` 命令里还有很多有用的命令。


* `npm explore . -- git pull origin master` ，更新当前的 `git` 资源库。
* `npm edit .` ，编辑当前模块的所有依赖模块。
* `npm docs coffee-script` ，打开 `coffee-script` 模块的文档。
* `npm outdated coffee-script` ，查看 `coffee-script` 是否有新版本。
* `npm submodule .` ，可以要求依赖模块是从 `git` 资源库安装的，而不是从 `registry` 安装。因为作者的 `git` 资源库总是最新的版本，`registry` 上的是模块作者发布上去的稳定版本。


甚至可以用 `npm` 来编程。





### 总结

我在成长过程中也是一路摸爬滚打，没有任何人的指点，所以走的很艰难。例如在大三的时候，如果有个学长可以阶段性的指点一二，如果有已经工作的师兄可以告诉我工作上需要什么，我应该前面的三年可以缩短一半；后来去面试bat，失败了有5、6次，每次也不知道具体是什么原因，都是靠面试回忆去猜测可能是哪方面的问题，回来学习和完善，当你真正去招人的时候，你就会知道面试记录是多么重要，面试官可以从面试记录里看到你的成长，总是去面试，总是没有成长，就会被定义为缺乏潜力。

**[开源分享：【大厂前端面试题解析+核心总结学习笔记+真实项目实战+最新讲解视频】](https://bbs.csdn.net/topics/618166371)**

![image](https://img-blog.csdnimg.cn/img_convert/a2550f5b14bf474e471918c4b41efb54.webp?x-oss-process=image/format,png)
面试记录里看到你的成长，总是去面试，总是没有成长，就会被定义为缺乏潜力。

**[开源分享：【大厂前端面试题解析+核心总结学习笔记+真实项目实战+最新讲解视频】](https://bbs.csdn.net/topics/618166371)**

[外链图片转存中...(img-rlclFQ9I-1714316477348)]
![image](https://img-blog.csdnimg.cn/img_convert/f72ea4856ec71646e323ba280a3943dc.webp?x-oss-process=image/format,png)