name: 项目名称

version: 项目版本号

description: 项目描述

keywords: {Array}关键词，便于用户搜索到我们的项目

homepage: 项目url主页

bugs: 项目问题反馈的Url或email配置，如：

{ 
    "url" : "https://github.com/owner/project/issues", 
    "email" : "project@hostname.com" 
}

license

项目许可证，让使用者知道是如何被允许使用此项目。默认是"ISC"

author,contributors: 坐着和贡献者。格式设置如下：

{ 
    "name" : "Barney Rubble",
    "email" : "b@rubble.com",
    "url" : "http://barnyrubble.tumblr.com/" 
}

files

包含在项目中的文件数组。如果在数组里面声明了一个文件夹，那也会包含文件夹中的文件。可以声明一些规则来忽略部分文件。可以在项目根目录或者子目录里声明一个.npmignore。

package.json 
README (and its variants) 
CHANGELOG (and its variants) 
LICENSE / LICENCE 
Conversely, some files are always ignored:

.git 
CVS 
.svn 
.hg 
.lock-wscript 
.wafpickle-N 
*.swp 
.DS_Store 
._* 
npm-debug.log

main

主文件。比如默认是index.js，项目名称叫mymodule。那么require(‘mymodule’)将返回index.js返回的内容

bin

项目用到的可执行文件配置

man

指定一个单一的文件名或一个文件名数组。意思类似于linux命令中的man 命令，来查看一个命令的用法

如果只给man字段提供一个文件，则安装完毕后，它就是man 的结果，这和此文件名无关

{ 
    "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后缀(当它被压缩时)。这个数字说明了这个文件被安装到哪个节中

{ 
    "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规范说明了几种你可以用directories对象来标示你的包结构的方法

directories.lib

告诉你库文件夹的位置，目前没有什么地方需要用到lib文件夹，但是这是重要的元信息

directories.bin

如果你在directories.bin中指定一个bin目录，在这个目录中的所有文件都会被当做在bin来使用。

由于bin指令的工作方式，同时指定一个bin路径和设置directories.bin将是一个错误。如果你想指定独立的文件，使用bin，如果想执行某个文件夹里的所有文件，使用directories.bin。

directories.doc

把markdown文件放在这。也许某一天这些文件将被漂亮地展示出来，不过这仅仅是也许

directories.man

directories.man指定的文件夹里都是man文件，系统通过遍历这个文件夹来生成一个man的数组

directories.example

把示例脚本放在这。也许某一天会被用到

repository

项目代码存放地方

"repository" : { 
    "type" : "git",
    "url" : "https://github.com/npm/npm.git" 
} 
"repository" : {
    "type" : "svn",
    "url" : "https://v8.googlecode.com/svn/trunk/" 
}

scripts

声明一系列npm脚本指令

prepublish: 在包发布之前运行，也会在npm install安装到本地时运行
publish,postpublish: 包被发布之后运行
preinstall: 包被安装前运行
install,postinstall: 包被安装后运行
preuninstall,uninstall: 包被卸载前运行
postuninstall: 包被卸载后运行
preversion: bump包版本前运行
postversion: bump包版本后运行
pretest,test,posttest: 通过npm test命令运行
prestop,stop,poststop: 通过npm stop命令运行
prestart,start,poststart: 通过npm start命令运行
prerestart,restart,postrestart: 通过npm restart运行

config

配置项目中需要的配置参数：

{ 
    "name" : "foo" ,
    "config" : { 
        "port" : "8080"
    } , 
    "scripts" : { 
        "start" : "node server.js"
    } 
}

server.js中使用process.env.npm_package_config_port来访问port

用户也可以这样修改：npm config set foo:port 80

dependencies

项目在生产环境中依赖的包

devDependencies

项目在开发和测试环境中依赖的包

peerDependencies

在某些情况下，当一个主机无法require依赖包时，你会想要告诉它还有哪些工具或库与这个依赖包兼容。这通常被成为一个插件。尤其是在host文档中声明的模块会暴露一个特定的接口

{ 
    "name": "tea-latte", 
    "version": "1.3.5", 
    "peerDependencies": { 
        "tea": "2.x" 
    } 
} 
这将确保tea-latte这个包只会和2.x版本的tea一起被安装。执行npm install tea-latte可能产生以下关系图： 
├── tea-latte@1.3.5 
└── tea@2.2.0

bundledDependencies

{Array}，发布时会被一起打包的模块

optionalDependencies

如果一个依赖模块可以被使用，同时你也希望在该模块找不到或无法获取时npm继续运行，你可以把这个模块依赖放到optionalDependencies配置中。这个配置的写法和dependencies的写法一样，不同的是这里边写的模块安装失败不会导致npm install失败。当然，这种模块就需要你自己在代码中处理模块确实的情况了，例如：

try { 
    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() 
}

engines

声明项目需要的node或npm版本范围

{ "engines" : { "npm" : "~1.0.20" } } 
{ "engines" : { "node" : ">=0.10.3 <0.12" } }

os

指定你的项目将运行在什么操作系统上

cpu

指定你的项目将运行在什么cpu架构上

preferGlobal

如果你的包需要全局安装，通过命令行来运行，那么设置为true。如果这个包被本地安装则会出现一个警告

private

如果设置为true, 那么npm会拒绝发布它

publishConfig

yarn upgrade 同步更新package.json版本信息

下载npm-check-updates

// 先下载
yarn global add npm-check-updates
// 更新包（yarn.lock和package.json同步更新）
ncu --upgrade --upgradeAll && yarn upgrade

yarn upgrade-interactive --latest

yarn upgrade-interactive --latest
// 需要手动选择升级的依赖包，按空格键选择，a 键切换所有，i 键反选选择

yarn upgrade package@version

yarn upgrade package@version
// yarn.lock和package.json都会更新，但是会进行版本锁定 "echarts": "4.2.0-rc.2"

package.json配置说明

参考文档