Node.js的npm包管理器基础使用教程(node 包管理)

推荐整理分享Node.js的npm包管理器基础使用教程(node 包管理)，希望有所帮助，仅作参考，欢迎阅读内容。

文章相关热门搜索词:node.js安装npm,nodejs内置的包管理器,nodejs内置的包管理器,nodejs内置的包管理器,node npm webpack,npm does not support node.js,nodejs内置的包管理器,node 包管理,内容如对您有帮助，希望把文章链接给更多的朋友！

配置

上面命令等于为npm init设置了默认值，以后执行npm init的时候，package.json的作者姓名、邮件、主页、许可证字段就会自动写入预设的值。这些信息会存放在用户主目录的~/.npmrc文件，使得用户不用每个项目都输入。如果某个项目有不同的设置，可以针对该项目运行npm config。1.

上面命令设置加入模块时，package.json将记录模块的确切版本，而不是一个可选的版本范围。

2.

3.

npm使用安装：

安装之前，npm install会先检查，node_modules目录之中是否已经存在指定模块。如果存在，就不再重新安装了，即使远程仓库已经有了一个新版本，也是如此。如果你希望，一个模块不管是否安装过，npm 都要强制重新安装，可以使用-f或--force参数。

本地安装: package会被下载到当前所在目录，也只能在当前目录下使用。安装结束后，当前目录下回多出一个node_modules目录，grunt-cli就安装在里面。

全局安装:package会被下载到到特定的系统目录下，安装的package能够在所有目录下使用。现在变成了/usr/local/lib/node_modules/grunt-cli，/usr/local/lib/node_modules/也就是之前所说的全局安装目录啦。1.安装当前目录package.json文件中配置的devDependencies模块

2.安装本地的模块文件

3.安装指定URL的模块

4.安装本地文件系统中指定的目录包含的模块

5.安装并更新package.json中的版本配置

（1）添加?save 参数安装的模块的名字及其版本信息会出现在package.json的dependencies选项中（2）添加?save-dev 参数安装的模块的名字及其版本信息会出现在package.json的devDependencies选项中（3）添加?save-optional 参数安装的模块的名字及其版本信息会出现在package.json的optionalDependencies选项中6.安装模块的指定版本

7.安装模块指定版本号范围内的某一个版本

Example:

?force强制拉取远程资源，即使本地已经安装这个模块Example:

8.-g或?global全局安装模块，如果没有这个参数，会安装在当前目录的node_modules子目录下Example:

如果你希望，所有模块都要强制重新安装，那就删除node_modules目录，重新执行npm install。

更新

更新指定name列表中的模块。-g参数更新全局安装的模块。如果没有指定name，且不是在某个模块内，会更新当前目录依赖的所有包都会被更新（包括全局和模块内）；如果当前目录在某个模块目录内，会更新该模块依赖的模块，所以不指定name直接运行npm update时，最好在某个模块内运行，以免更新到其他不想更新的模块。

卸载

查看查看安装了那些包

查看特定包具体信息

搜索

发布1.package.jsonpackage.json说明：npm命令运行时会读取当前目录的 package.json 文件和解释这个文件，这个文件基于 Packages/1.1规范。在这个文件里你可以定义你的应用名称( name )、应用描述( description )、关键字( keywords )、版本号( version )、应用的配置项( config )、主页( homepage )、作者( author )、资源仓库地址( repository )、bug的提交地址( bugs )，授权方式( licenses )、目录( directories )、应用入口文件( main )、命令行文件( bin )、应用依赖模块( dependencies )、开发环境依赖模块( devDependencies )、运行引擎( engines )和脚本( scripts )等。

对于开发者而言，开发和发布模块都依赖于他对这个文件 package.json 所包含的意义的正确理解。我们下面用一个本文共用的例子来说明：

这个例子里我们定义了应用的入口文件( 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 或 link 加上参数 —dev 安装到当前模块的 node_modules 目录下。

name: package的名字（由于他会成为url的一部分，所以 non-url-safe 的字母不会通过，也不允许出现"."、"_"），最好先在[]( package的版本，当package发生变化时，version也应该跟着一起变化，同时，你声明的版本需要通过semver的校验（semver可自行谷歌）dependencies: package的应用依赖模块，即别人要使用这个package，至少需要安装哪些东东。应用依赖模块会安装到当前模块的node_modules目录下。devDependencies：package的开发依赖模块，插件发布的时候自动删除不相关代码。用个文件记录一下当前项目中安装或者需要的插件，即别人要在这个package上进行开发，可以一键安装项目所需插件。

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

例子:0.4.2

+ 大版本(0)+ 小版本(4)+ 补丁版本(2)一个软件发布的时候，默认就是 1.0.0 版。如果以后发布补丁，就增加最后一位数字，比如1.0.1；如果增加新功能，且不影响原有的功能，就增加中间的数字（即小版本号），比如1.1.0；如果引入的变化，破坏了向后兼容性，就增加第一位数字（即大版本号），比如2.0.0。

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

生成

用来初始化生成一个新的package.json文件。它会向用户提问一系列问题，如果你觉得不用修改默认配置，一路回车就可以了。如果使用了-f（代表force）、-y（代表yes），则跳过提问阶段，直接生成一个新的package.json文件。

node.js 动态执行脚本 node.js最近新增了虚拟机模块，其实也不能说是新增的，只是把一些内部接口暴露出来罢了，从2.x就有了。我们可以从node/src/node.js看到这些代码：varScript

node.js cookie-parser 中间件介绍 之前加入了一个学习笔记本群，通过学习笔记来分享学习成果。也在这里发一份吧。当我们在写web的时候，难免会要使用到cookie，由于node.js有了express这

node.js cookie-parser之parser.js cookie-parser的作用，官方的说法是：ParseCookieheaderandpopulatereq.cookieswithanobjectkeyedbythecookienames.我的理解是，转换headers中的cookie并跟req.cookies合并。作为cookie