标签：至少1个，最多5个
新款mbp镇楼 !
某天发生一件比较奇怪的事情，从git上clone下来的代码，执行完npm install && bower install之后，app不能正常工作。
根据报错信息发现是angular出了些莫明奇妙的错误，而同样版本的代码，在上个月setup在同一台机器上另外一个目录是可以work的。我大致推断出，可能是依赖的第三方包冲突了，查了下昨天angular确实发布了新版本1.6.0，我打开bower_components/angular/package.json 中的version字段，确实被升级成1.6.0了，而可以work的那个目录下的angular由于是上个月安装的所以版本号是1.5.8。我把angular的版本退回了1.5.8就可以正常work了。
所以说第三方包的日常更新，很可能会影响到我们项目的运行。打开根目录下的package.json或者bower.json我们会在dependencies中找到各个依赖包的名字和版本号定义，一般情况下这个版本号大致有以下3种套路
"dependencies": {
"angular":"^1.4.10"
"dependencies": {
"angular":"~1.4.10"
"dependencies": {
"angular":"1.4.10"
说到这里就要提一下版本号的一种定义规则叫做
版本格式：主版本号.次版本号.修订号，版本号递增规则如下：
主版本号：当你做了不兼容的 API 修改，
次版本号：当你做了向下兼容的功能性新增，
修订号：当你做了向下兼容的问题修正。
先行版本号及版本编译信息可以加到“主版本号.次版本号.修订号”的后面，作为延伸。
而 ^ 和 ～ 的作用就是用来控制install时候选择版本的策略
"angular":"^1.4.10" 意味着，本次安装会选择GitHub 上angular 1.x.x版本中最高的版本，即使angular的最新版本是2.x.x,不会去升级主版本号，但是谁挑选此版本号中最高的装
"angular":"~1.4.10" 意味着， 本次安装会选择GitHub 上angular 1.4.x 版本中最高的版本，比如1.4.20 不会去升级主版本号和次版本号
"angular":"1.4.10" 就是写死了，每次都是固定版本。
由于package.json ／ bower.json很多地方都是用了^策略，所以当次版本号改变时，往往是比较大的更新，很有可能会引发冲突。
铺垫了这么多，终于要步入正题了。辣么，如果这类问题发生了我们该如何去排错呢，这里就要给大家安利一款本人写的vscode插件，叫做 library-version，它可以方便的把项目下node_moudules / bower_components下所有依赖包的版本号统一列出来，不需要你一个个点开各自的pacakge.json文件去查找了。是不是很有用？把前后2份生成的version list对比一下就知道哪些包被升级了，从而开始着手排查问题，或者从新制定安装策略。
关于插件library-version
最后希望大家帮忙安装下，帮我increase一下download count如果大家对这款插件的开发有兴趣，我有时间也会另开一篇文章来讲讲这个插件的实现思路。插件可以直接使用你的vscode安装，搜library-versionmarketplace地址：github地址：
根据评论中同学的推荐，使用了yarn这个包管理工具，这个工具会在第一次执行的install的时候生成一份yarn.lock文件，里面就锁定了依赖包的具体版本，如果以后在其它路径下再按装的话，如果include了之前的yarn.lock文件，那么就会严格按照之前的版本去安装依赖包，而不会根据Semantic规则去自动升级包了。
另外，今天也在另外个team的node工程里看到一个npm-shrinkwrap.json的文件，我好奇打开一看发现里面的配置和yarn.lock的配置大同小异，心想会不会npm install的时候也有类似lock版本号的功能，于是查了下npm的doc发现，确实是有的， 不过这个生成lock文件的功能需要自己手动执行 npm shrinkwrap。
2 收藏&&|&&0
你可能感兴趣的文章
25 收藏，6k
3 收藏，427
225 收藏，81.5k
天哪。。。- -尽然如此冷清。。。
天哪。。。- -尽然如此冷清。。。
"angular":"~1.4.10" 最后两个都写成~了 (●??｀●)
&angular&:&~1.4.10& 最后两个都写成~了 (●??｀●)
楼主棒棒的！这个情况确实经常发生，所以不是都转投yarn了吗
楼主棒棒的！这个情况确实经常发生，所以不是都转投yarn了吗
谢谢支持，yarn还没去研究过，等过完年上班的时候看看。
谢谢支持，yarn还没去研究过，等过完年上班的时候看看。
今天看了下yarn，原来有了yarn.lock就可以保证上一次安装时候依赖的具体版本了
今天看了下yarn，原来有了yarn.lock就可以保证上一次安装时候依赖的具体版本了
分享到微博？
技术专栏，帮你记录编程中的点滴，提升你对技术的理解收藏感兴趣的文章，丰富自己的知识库
明天提醒我
我要该，理由是：问题对人有帮助，内容完整，我也想知道答案
问题没有实际价值，缺少关键内容，没有改进余地
遇到一个问题，引用stylus失败，已解决，但是有点困惑
背景如下：npm目前升级到了5.0.3npm install的时候目录会多一个package-lock.json这个文件此时我在package.json的devDependencies中添加了
"stylus": "^0.54.5",
"stylus-loader": "^3.0.1"
然后在终端重新运行npm install的时候，项目中的node_modules并没有出现stylus文件夹查了下资料说是新版本的坑给的解决办法是切换回之前的npm版本……
我的解决过程1、删除package-lock.json,重新npm install，node_modules中出现了stylus文件夹了，然而还是报错2、在终端直接运行 sudo npm install stylus-loader stylus --save-dev 结果就编译成功了
如有小伙伴有同样的问题，可以按照我这样试试，然后想问问大神们，这个有啥好的办法啊，莫非之后我在package.json里面写的依赖都要在终端自己指定安装一下……
答案对人有帮助，有参考价值
答案没帮助，是错误的答案，答非所问
这个我也发现了，我查了一下，是说这个是npm5.0 的坑，我的理解是想要安装只能指定版本。这是我在Stack Overflow看到的答案，不过外语不好，只能意会一部分。 你这个问题，分在vue.js 不是很好，可以换一下npm或者node.js试试，也许会有人更清楚。
答案对人有帮助，有参考价值
答案没帮助，是错误的答案，答非所问
我也遇到了这个问题。删除node_modules，然后再删除lock文件，再重新npm install即可
答案对人有帮助，有参考价值
答案没帮助，是错误的答案，答非所问
没去看文档，暂时有个方法就是删除lock文件 再 npm i 就可以了
答案对人有帮助，有参考价值
答案没帮助，是错误的答案，答非所问
?它类似yarn.lock文件，这个package-lock.json是npm5新特性，帮助你锁定依赖版本的，避免‘这个程序在我电脑能跑的’问题。。。是需要check-in到版本控制的，这样同组的伙伴不至于因为依赖更新导致版本坑。
答案对人有帮助，有参考价值
答案没帮助，是错误的答案，答非所问
这个文件是保证你的package.json文件中所有的安装包版本和安装包版本所依赖的二级安装包的版本不会发生变化，解决办法，如果package.json文件有更新，在npm install之前，rm -rf package-lock.json ，删除该文件，然后再执行npm install即可，不需要删除node_modules（删除node_modules相当于把所有的重装一遍，这是不需要的）
答案对人有帮助，有参考价值
答案没帮助，是错误的答案，答非所问
lz直接对package.json进行修改以增加依赖项的做法，其实真的不如在终端中直接npm install对应模块。有两种比较推荐的方法
直接用@方法安装指定版本的npm包
将旧版本包先uninstall，然后再次安装
答案对人有帮助，有参考价值
答案没帮助，是错误的答案，答非所问
有个万能的npm-check，或者outdate来检查更新和安装指定版本的包
答案对人有帮助，有参考价值
答案没帮助，是错误的答案，答非所问
在package-lock.json同级目录下添加自定义npm-shrinkwrap.json文件，package-lock.json会失效。
同步到新浪微博
分享到微博？
Hi，欢迎来到 SegmentFault 技术社区！⊙▽⊙ 在这里，你可以提出编程相关的疑惑，关注感兴趣的问题，对认可的回答投赞同票；大家会帮你解决编程的问题，和你探讨技术更新，为你的回答投上赞同票。
明天提醒我
关闭理由：
删除理由：
忽略理由：
推广（招聘、广告、SEO 等）方面的内容
与已有问题重复（请编辑该提问指向已有相同问题）
答非所问，不符合答题要求
宜作评论而非答案
带有人身攻击、辱骂、仇恨等违反条款的内容
无法获得确切结果的问题
非开发直接相关的问题
非技术提问的讨论型问题
其他原因（请补充说明）
我要该，理由是：npm使用入门 - 简书
npm使用入门
npm makes it easy for JavaScript developers to share and reuse code, and it makes it easy to update the code that you're sharing.
简单来说，npm就是javascript的包管理工具，类似java语法当中的maven, gradle, python的pip。
npm是和Node.js一起发布的，只要安装了Node.js，npm也安装好了，可以从Node.js的下载对应操作系统的安装包安装即可。 安装好后，执行如下命令，检查是否安装成功。
但是由于npm自身的更新频率比Node.js高很多，所以通过上面的命令安装的npm可能不是最新版本，可以通过下面的命令单独更新npm
$ npm install npm@latest -g
$ npm install &package_name&
便可以安装对应的包到执行命令的当前目录，并创建一个node_modules的文件夹,然后把需要安装的安装包下载到里面。
使用package.json
通过上面的命令，直接安装的包默认都是最新版本的。但是在项目中，我们怎么让一起开发的同事知道项目中用了哪些包，具体包的版本信息呢？这时package.json就上场了，可以把它想成是java语言中的pom.xml,python语言中的requirements.txt。
一个基本的package.json文件至少需要包含两个重要信息: 包名name和版本信息version。例如:
"name": "my-awesome-package",
"version": "1.0.0"
创建package.json
我们可以使用命令npm init来初始化一个package.json文件，运行这个命令后，它会询问一些关于包的基本信息，根据实际情况回答即可。如果不喜欢这种方式，可以使用npm init --yes命令直接使用默认的配置来创建package.json文件，最后根据需要修改创建好的package.json文件即可。
package.json文件创建好后，我们来看看它长得什么样子吧！
"name": "my_package",
"description": "",
"version": "1.0.0",
"description": "",
"main": "index.js",
"scripts": {
"test": "echo \"Error: no test specified\" && exit 1"
"repository": {
"type": "git",
"url": "/ashleygwilliams/my_package.git"
"keywords": [],
"author": "",
"license": "ISC",
"url": "/ashleygwilliams/my_package/issues"
"homepage": "/ashleygwilliams/my_package"
主要字段的含义如下:
name: 模块名, 模块的名称有如下要求:
只能是一个词语，没有空格
允许使用破折号和下划线作为单词分隔符
version: 模块版本信息
description：关于模块功能的简单描述，如果这个字段为空的话，默认会从当前目录的READMD.md或README文件读取第一行内容作为它的默认值。
main: 模块被引入后，首先加载的文件，默认为index.js。
定义一些常用命令入口
类似git一样，npm也可以做一些简单的配置来设置一些我们常用的信息
$ npm set init.author.email ""
$ npm set init.author.name "ag_dubs"
$ npm set init.license "MIT"
这样下次执行npm init的时候，就会用上我们配置的一些默认信息啦！
使用npm install会读取package.json文件来安装模块。安装的模块分为两类dependencies和devDependencies，分别对应生产环境需要的安装包和开发环境需要的安装包。
同样在安装模块的时候，可以通过指定参数来修改package.json文件，如
$ npm install &package_name& --save
$ npm install &package_name& --save-dev
来将新安装的模块信息记录到package.json文件。
$ npm update
$ npm uninstall &package_name&
如果要在卸载模块的同时，也将他从package.json文件中移除，可以添加跟安装时候一样的参数，例如:
$ npm uninstall --save lodash
全局包管理
默认情况下。我们执行默认的安装命令安装的包都是安装到当前目录下的，只能在当前目录下使用。但是假如我们需要使用一些全局的软件，如grunt，我们可以在安装的时候，添加-g选项来安装，方便后面在任何目录下都可以使用grunt相关的命令
$ npm install -g grunt
同理，更新全局的安装包只需要执行命令
$ npm update -g
为了查看当前哪些包需要更新，可以使用如下命令来查看
$ npm outdated -g --depth=0
webpack-dev-server
卸载全局安装的包也只需要加上-g选项即可。如
$ npm uninstall -g jshint
创建自己的Node.js模块
一个Node.js模块就是一个可以发布到npm，供其他开发者下载和使用的模块。那么，到底怎样和其他开发者分享我们的模块呢？
首先，我们必须创建一个package.json文件，添加上关于我们想要分享的模块信息，如：模块功能，开发者信息等。
一旦package.json文件创建好后，我们需要创建一个模块被引入时，就加载的文件。即package.json中main字段指定的文件，默认为index.js。我们需要在文件中将一个函数赋值给exports模块，方便其他开发者调用我们的模块。如
exports.printMsg = function() {
console.log("This is a message from the demo package");
包(Pacakges)和模块(Modules)
在使用npm的时候，有两个概念容易搞混，那就是包(Pacakges)和模块(Modules)。简单来说，包和模块的区别如下：
包是一个被package.json文件描述了的文件或者目录
模块是可以被Node.js引用的文件或目录
什么是包？
a) a folder containing a program described by a package.json fileb) a gzipped tarball containing (a)c) a url that resolves to (b)d) a &name&@&version& that is published on the registry with (c)e) a &name&@&tag& that points to (d)f) a &name& that has a latest tag satisfying (e)g) a git url that, when cloned, results in (a).
什么是模块？
A folder with a package.json file containing a main field.
A folder with an index.js file in it.
A JavaScript file.
在使用npm时，我们可以根据个人的需要，指定很多配置信息。npm的配置信息加载优先级如下(从高到低)
命令行参数
项目级别的npmrc文件(/path/to/my/project/.npmrc)
用户级别的npmrc文件（~/.npmrc）
全局的npmrc文件($PREFIX/etc/npmrc)
npm内置的npmrc文件(/path/to/npm/npmrc)
$ npm config list -l
最后介绍一个比较重要的配置，当我们使用默认配置从npm官网下载模块时，由于网络的因素，会导致我们的下载速度特别慢。所以，我们可以配置一些国内的镜像来加快我们的下载速度。在这里，我推荐使用, 具体使用方式如下:
临时使用, 安装包的时候通过--registry参数即可
$ npm install express --registry https://registry.npm.taobao.org
$ npm config set registry https://registry.npm.taobao.org
// 配置后可通过下面方式来验证是否成功
npm config get registry
npm info express
使用cnpm使用
// 安装cnpm
npm install -g cnpm --registry=https://registry.npm.taobao.org
// 使用cnpm安装包
cnpm install express
人生的道路上，要时常停下来想一想，是否偏离了最初的目标。
写作是与自己心灵的交流！nodejs npm package.json中文文档_node.js
作者：用户
本文讲的是nodejs npm package.json中文文档_node.js，
本文档有所有package.json中必要的配置。它必须是真正的json，而不是js对象。
本文档中描述的很多行为都受npm-config(7)的影响。
npm会根据包内容设置一些默认值。
复制代码 代码如下:
本有所有package.json中必要的配置。它必须是真正的json，而不是js对象。
本文档中描述的很多行为都受npm-config(7)的影响。
npm会根据包内容设置一些默认值。
复制代码 代码如下:
"scripts": {"start": "node server.js"}
如果包的根目录有server.js文件，npm会默认将start命令设置为node server.js。
"scripts":{"preinstall": "node-waf clean || node-waf configure build"}
如果包的根目录有wscript文件，npm会默认将preinstall命令用node-waf进行编译。
"scripts":{"preinstall": "node-gyp rebuild"}
如果包的根目录有binding.gyp文件，npm会默认将preinstall命令用node-gyp进行编译。
"contributors": [...]
如果包的根目录有AUTHORS文件，npm会默认逐行按Name &email& (url)格式处理，邮箱和url是可选的。#号和空格开头的行会被忽略。
在package.json中最重要的就是name和version字段。他们都是必须的，如果没有就无法install。name和version一起组成的标识在假设中是唯一的。改变包应该同时改变version。
name是这个东西的名字。注意：
1.不要把node或者js放在名字中。因为你写了package.json它就被假定成为了js，不过你可以用”engine”字段指定一个引擎（见后文）。
2.这个名字会作为在URL的一部分、命令行的参数或者文件夹的名字。任何non-url-safe的字符都是不能用的。
3.这个名字可能会作为参数被传入require()，所以它应该比较短，但也要意义清晰。
4.在你爱上你的名字之前，你可能要去npm registry查看一下这个名字是否已经被使用了。http://registry.npmjs.org/
在package.json中最重要的就是name和version字段。他们都是必须的，如果没有就无法install。name和version一起组成的标识在假设中是唯一的。改变包应该同时改变version。
version必须能被node-semver解析，它被包在npm的依赖中。（要自己用可以执行npm install semver）
可用的“数字”或者“范围”见semver(7).
description
放简介，字符串。方便屌丝们在npm search中搜索。
关键字，数组、字符串。还是方便屌丝们在npm search中搜索。
项目官网的url。
注意：这和“url”不一样。如果你放一个“url”字段，registry会以为是一个跳转到你发布在其他地方的地址，然后喊你滚粗。
嗯，滚粗，没开玩笑。
你项目的提交问题的url和（或）邮件地址。这对遇到问题的屌丝很有帮助。
差不多长这样：
复制代码 代码如下:
{ "url" : "/owner/project/issues"
, "email" : ""
你可以指定一个或者指定两个。如果你只想提供一个url，那就不用对象了，字符串就行。
如果提供了url，它会被npm bugs命令使用。
你应该要指定一个许可证，让人知道使用的权利和限制的。
最简单的方法是，假如你用一个像BSD或者MIT这样通用的许可证，就只需要指定一个许可证的名字，像这样：
复制代码 代码如下:
{ "license" : "BSD" }
如果你又更复杂的许可条件，或者想要提供给更多地细节，可以这样:
复制代码 代码如下:
"licenses" : [
{ "type" : "MyLicense"
, "url" : "/owner/project/path/to/license"
在根目录中提供一个许可证文件也蛮好的。
people fields: author, contributors
author是一个人。contributors是一堆人的数组。person是一个有name字段，可选的有url、email字段的对象，像这样：
复制代码 代码如下:
{ "name" : "Barney Rubble"
, "email" : ""
, "url" : "/"
或者可以把所有的东西都放到一个字符串里，npm会给你解析：
复制代码 代码如下:
"Barney Rubble && (/)
email和url在两种形式中都是可选的。
也可以在你的npm用户信息中设置一个顶级的maintainers字段。
files是一个包含项目中的文件的数组。如果命名了一个文件夹，那也会包含文件夹中的文件。（除非被其他条件忽略了）
你也可以提供一个.npmignore文件，让即使被包含在files字段中得文件被留下。其实就像.gitignore一样。
main字段是一个模块ID，它是一个指向你程序的主要项目。就是说，如果你包的名字叫foo，然后用户安装它，然后require("foo")，然后你的main模块的exports对象会被返回。
这应该是一个相对于根目录的模块ID。
对于大多数模块，它是非常有意义的，其他的都没啥。
很多包都有一个或多个可执行的文件希望被放到PATH中。npm让妈妈再也不用担心了（实际上，就是这个功能让npm可执行的）。
要用这个功能，给package.json中的bin字段一个命令名到文件位置的map。初始化的时候npm会将他链接到prefix/bin（全局初始化）或者./node_modules/.bin/（本地初始化）。
比如，npm有：
复制代码 代码如下:
{ "bin" : { "npm" : "./cli.js" } }
所以，当你初始化npm，它会创建一个符号链接到cli.js脚本到/usr/local/bin/npm。
如果你只有一个可执行文件，并且名字和包名一样。那么你可以只用一个字符串，比如：
复制代码 代码如下:
{ "name": "my-program"
, "version": "1.2.5"
, "bin": "./path/to/program" }
结果和这个一样：
复制代码 代码如下:
{ "name": "my-program"
, "version": "1.2.5"
, "bin" : { "my-program" : "./path/to/program" } }
指定一个单一的文件或者一个文件数组供man程序使用。
如果只提供一个单一的文件，那么它初始化后就是man &pkgname&的结果，而不管实际的文件名是神马，比如：
复制代码 代码如下:
{ "name" : "foo"
, "version" : "1.2.3"
, "description" : "A packaged foo fooer for fooing foos"
, "main" : "foo.js"
, "man" : "./man/doc.1"
这样man foo就可以用到./man/doc.1文件了。
如果文件名不是以包名开头，那么它会被冠以前缀，下面的：
复制代码 代码如下:
{ "name" : "foo"
, "version" : "1.2.3"
, "description" : "A packaged foo fooer for fooing foos"
, "main" : "foo.js"
, "man" : [ "./man/foo.1", "./man/bar.1" ]
会为man foo和man foo-bar创建文件。
man文件需要以数字结束，然后可选地压缩后以.gz为后缀。The number dictates which man section the file is installed into.
复制代码 代码如下:
{ "name" : "foo"
, "version" : "1.2.3"
, "description" : "A packaged foo fooer for fooing foos"
, "main" : "foo.js"
, "man" : [ "./man/foo.1", "./man/foo.2" ]
会为man foo和man 2 foo创建。
directories
CommonJS Packages规范说明了几种方式让你可以用directorieshash标示出包得结构。如果看一下npm's package.json，你会看到有directories标示出doc, lib, and man。
在未来，这个信息可能会被用到。
directories.lib
告诉屌丝们你的库文件夹在哪里。目前没有什么特别的东西需要用到lib文件夹，但确实是重要的元信息。
directories.bin
如果你指定一个“bin”目录，然后在那个文件夹中得所有文件都会被当做”bin”字段使用。
如果你已经指定了“bin”字段，那这个就无效。
directories.man
一个放满man页面的文件夹。贴心地创建一个“man”字段。
A folder that is full of man pages. Sugar to generate a “man” array by
walking the folder.
directories.doc
将markdown文件放在这里。最后，这些会被很好地展示出来，也许，某一天。
Put markdown files in here. Eventually, these will be displayed nicely,
maybe, someday.
directories.example
将事例脚本放在这里。某一天，它可能会以聪明的方式展示出来。
repository
指定你的代码存放的地方。这个对希望贡献的人有帮助。如果git仓库在github上，那么npm docs命令能找到你。
复制代码 代码如下:
"repository" :
{ "type" : "git"
, "url" : "/isaacs/npm.git"
"repository" :
{ "type" : "svn"
, "url" : "/svn/trunk/"
URL应该是公开的（即便是只读的）能直接被未经过修改的版本控制程序处理的url。不应该是一个html的项目页面。因为它是给机看的。
“scripts”是一个由脚本命令组成的hash对象，他们在包不同的生命周期中被执行。key是生命周期事件，value是要运行的命令。
参见 npm-scripts(7)
“config” hash可以用来配置用于包脚本中的跨版本参数。在实例中，如果一个包有下面的配置：
复制代码 代码如下:
{ "name" : "foo"
, "config" : { "port" : "8080" } }
然后有一个“start”命令引用了npm_package_config_port环境变量，用户可以通过npm config set foo:port 8001来重写他。
参见 npm-config(7) 和 npm-scripts(7)。
dependencies
依赖是给一组包名指定版本范围的一个hash。这个版本范围是一个由一个或多个空格分隔的字符串。依赖还可以用tarball或者git URL。
请不要将测试或过渡性的依赖放在dependencieshash中。见下文的devDependencies。
详见semver(7).
1.version 必须完全和version一致
2.&version 必须比version大
3.&=version 同上
4.&version 同上
5.&=version 同上
6.~version 大约一样，见semver(7)
7.1.2.x 1.2.0, 1.2.1, 等，但不包括1.3.0
8.http://... 见下文'依赖URL'
10."" 空，同*
11.version1 - version2 同 &=version1 &=version2.
12.range1 || range2 二选一。
13.git... 见下文'依赖Git URL'
14.user/repo 见下文'GitHub URLs'
15.比如下面都是合法的：
复制代码 代码如下:
{ "dependencies" :
{ "foo" : "1.0.0 - 2."
, "bar" : "&=1.0.2 &2.1.2"
, "baz" : "&1.0.2 &=2.3.4"
, "boo" : "2.0.1"
, "qux" : "&1.0.0 || &=2.3.1 &2.4.5 || &=2.5.2 &3.0.0"
, "asd" : "/asdf.tar.gz"
, "til" : "~1.2"
, "elf" : "~1.2.3"
, "two" : "2.x"
, "thr" : "3.3.x"
可以指定一个tarball URL，这个tarball将在包被初始化的时候下载并初始化。
依赖Git URL
Git urls 可以是下面几种形式：
复制代码 代码如下:
git:///user/project.git#commit-ish
git+ssh://user@hostname:project.git#commit-ish
git+ssh://user@hostname/project.git#commit-ish
git+http://user@hostname/project/blah.git#commit-ish
git+https://user@hostname/project/blah.git#commit-ish
commit-ish是可以被git checkout的任何tag、sha或者branch。默认为master。
GitHub URLs
1.1.65版后，你可以仅仅用“user/foo-project”引用GitHub urls，比如：
复制代码 代码如下:
"name": "foo",
"version": "0.0.0",
"dependencies": {
"express": "visionmedia/express"
devDependencies
如果有人计划在他们的程序中下载并使用你的模块，那么他们可能不想或者不需要去下载并构建你使用的外部测试或者文档框架。
在这种情况下，它最好把这些附属的项目列示在devDependencies hash中。
这些东西会在根目录执行npm link或者npm install的时候初始化，并可以像其他npm配置参数一样管理。详见npm-config(7)。
对于非特定平台的构建步骤，比如编译CoffeeScript或者其他语言到Javascript，用prepublish脚本去实现并把他放在devDependency中。
复制代码 代码如下:
{ "name": "ethopia-waza",
"description": "a delightfully fruity coffee varietal",
"version": "1.2.3",
"devDependencies": {
"coffee-script": "~1.6.3"
"scripts": {
"prepublish": "coffee -o lib/ -c src/waza.coffee"
"main": "lib/waza.js"
prepublish脚本会在publishing前运行，这样用户就不用自己去require来编译就能使用。并且在开发模式中（比如本地运行npm install）会运行这个脚本以便更好地测试。
peerDependencies
在一些场景中，如在一个host中不必须进行require时候，你想表现你的package与一个host工具或者库的兼容关键。这一般用来引用插件。尤其是你的模块可能要暴露一个特定的接口，并由host文档来预期和指定。
复制代码 代码如下:
"name": "tea-latte",
"version": "1.3.5"
"peerDependencies": {
"tea": "2.x"
这能保证你的package可以只和tea的2.x版本一起初始化。npm install tea-latte可能会产生下面的依赖关系
复制代码 代码如下:
?”oe?”??”? tea-latte@1.3.5
?””?”??”? tea@2.2.0
试图初始化另一个有会冲突的依赖的插件将导致一个错误。因此，确保你的插件的需求约束越弱越好，而不要去把它锁定到一个特定的版本。
假设这个host遵守semver规范，只改变这个package的主版本会打破你的插件。因此，如果你在package中用过每个1.x版本，就用”^1.0″或者”1.x”来表示。如果你依赖于功能介绍1.5.2，用”&= 1.5.2 & 2″。
bundledDependencies
一组包名，他们会在发布的时候被打包进去。
拼成"bundleDependencies"（缺d）也可以。
optionalDependencies
如果一个依赖可用，但你希望在它安装错误的时候npm也能继续初始化，那么你可以把它放在optionalDependencies hash中。这是一个包名到版本或者url的map，就像dependencies hash一样。只是它运行错误。
处理缺乏依赖也是你的程序的责任。比如像这样：
复制代码 代码如下:
var foo = require('foo')
var fooVersion = require('foo/package.json').version
} catch (er) {
foo = null
if ( notGoodFooVersion(fooVersion) ) {
foo = null
// .. then later in your program ..
if (foo) {
foo.doFooThings()
optionalDependencies会覆盖dependencies中同名的项，所以通常比只放在一个地方好。
你可以指定工作的node的版本：
复制代码 代码如下:
{ "engines" : { "node" : "&=0.10.3 &0.12" } }
并且，像dependensies一样，如果你不指定版本或者指定“*”作为版本，那么所有版本的node都可以。
如果指定一个“engines”字段，那么npm会需要node在里面，如果“engines”被省略，npm会假定它在node上工作。
你也可以用“engines”字段来指定哪一个npm版本能更好地初始化你的程序，如：
复制代码 代码如下:
{ "engines" : { "npm" : "~1.0.20" } }
记住，除非用户设置engine-strict标记，这个字段只是建议值。
engineStrict
如果你确定你的模块一定不会运行在你指定版本之外的node或者npm上，你可以在package.json文件中设置"engineStrict":true。它会重写用户的engine-strict设置。
除非你非常非常确定，否则不要这样做。如果你的engines hash过度地限制，很可能轻易让自己陷入窘境。慎重地考虑这个选择。如果大家滥用它，它会再以后的npm版本中被删除。
你可以指定你的模块要运行在哪些操作系统中：
复制代码 代码如下:
"os" : [ "darwin", "linux" ]
你也可以用黑名单代替白名单，在名字前面加上“!”就可以了：
复制代码 代码如下:
"os" : [ "!win32" ]
操作系统用process.platform来探测。
虽然没有很好地理由，但它是同时支持黑名单和白名单的。
如果你的代码只能运行在特定的cpu架构下，你可以指定一个：
复制代码 代码如下:
"cpu" : [ "x64", "ia32" ]
就像os选项，你也可以黑一个架构：
复制代码 代码如下:
"cpu" : [ "!arm", "!mips" ]
cpu架构用process.arch探测。
preferGlobal
如果包主要是需要全局安装的命令行程序，就设置它为true来提供一个warning给只在局部安装的人。
它不会真正的防止用户在局部安装，但如果它没有按预期工作它会帮助防止产生误会。
如果你设置"private": true，npm就不会发布它。
这是一个防止意外发布私有库的方式。如果你要确定给定的包是只发布在特定registry（如内部registry）的，用publishConfighash的描述来重写registry的publish-time配置参数。
publishConfig
这是一个在publish-time使用的配置集合。当你想设置tag或者registry的时候它非常有用，所以你可以确定一个给定的包没有打上“lastest”的tag或者被默认发布到全局的公开registry。
任何配置都可以被重写，但当然可能只有“tag”和“registry”与发布的意图有关。
参见npm-config(7)有可以被重写的。
以上是云栖社区小编为您精心准备的的内容，在云栖社区的博客、问答、公众号、人物、课程等栏目也有的相关内容，欢迎继续使用右上角搜索按钮进行搜索nodejs
package.json
nodejs package.json、nodejs的package.json、nodejs npm、nodejs 安装npm、mac卸载nodejs及npm，以便于您获取更多的相关知识。
稳定可靠、可弹性伸缩的在线数据库服务，全球最受欢迎的开源数据库之一
6款热门基础云产品6个月免费体验；2款产品1年体验;1款产品2年体验
弹性可伸缩的计算服务，助您降低 IT 成本，提升运维效率
开发者常用软件，超百款实用软件一站式提供
云栖社区()为您免费提供相关信息，包括
，所有相关内容均不代表云栖社区的意见！}