内容来自npm官方文档，本文以中文讲解。name,version首先，需要包名。还需要版本号。npm规定一个包由它的名字加上版本号来唯一标识。例如，express@4.2。0、koa@2.1.1，不同的包名或版本号，对应的内容不同。以上内容通俗易懂。接下来补充几点：包名必须小于等于214个字符，包名不能是.或_开头的包名不能包含大写字母（历史原因，有些旧的包还有大写字母，新的不能再使用大写字母）另外，一些URL规范中不允许使用的字符不能使用（具体字符你自己查）建议包名中不要包含js`node`等词，因为npm默认是js或者node因为包名最终会在require语句中用到，所以越短越好，但要注意清楚表达你的目的在你开发包之前，你最好去npm官网看看这个名字是否已经被占用（很重要）。对于版本号，npm使用行业标准的{major}.{feature}.{patch}pattern所以1.4.1到1.4.2可能会修复一个小错误。1.4.1到1.5.0可能会添加新功能。1.4.1到2.0.0可能是两个变化很大的东西。Tips如果要发布包到npm，相同的包名，相同的版本号，只能发布一次，所以如果修改代码，需要更新版本号才能发布，修改哪一个要看如何muchyoumodified.description,两个关键字放在一起。这两个字段是用来在npm官网上搜索的。不同的是，一个是字符串，一个是字符串数组。不难理解，npm对description会进行分词搜索，对关键词会进行Precise搜索。Tips官方没有解释，以上分词与否纯属猜测。主页如果你有时间，你可以为你的包做一个官方网站。大型项目很常见。bugs字段不是这个包有bug，先来看例子{"url":"https://github.com/owner/project/issues","email":"project@hostname.com"}这个字段其实是提供给用户报告bug的方式，可以填写email或者issueaddressTips如果你只是想提供一个issue地址，那么bugs可以只是一个stringlicense。。。不想多说，自己去理解author,contributors这个是关于作者或者其他开发者信息的字段，意思很好理解，我们来看一个例子：{"name":"BarneyRubble","email":"b@rubble.com","url":"http://barnyrubble.tumblr.com/"}author和contributors是placementtype是一个类似上面的对象，用来描述人物信息。不同的是作者是一个人，而贡献者是一个数组。提示为非必需信息，可在成名后添加。Files不是必选项，也不常用，但是很重要，因为如果配置了这个信息会显得很专业。files是一个数组，描述了你npmpublish时推送到npm服务器的文件列表，支持目录和通配符如"files":["LICENSE","History.md","Readme.md","index.js","lib/"]，反过来可以通过一个.npmignore文件排除一些文件，防止大量垃圾文件被推送到npm，规则和你使用的gitignore一样.Tips如果你的项目下有一个.gitignore文件，它也可以作为.npmignore的功能。这意味着如果没有特殊要求，.gitignore就可以了。main是一个重要的属性，原文对此描述的比较绕口，其实可以理解为入口文件“main”：“./src/index.js”。还是上面的例子，如果你的包名是foo，当用户代码require('foo')时，相当于require你包目录下的./src/index.js文件。如果不提供该字段，则默认为项目根目录下的index.jsbin。这也是一个重要的属性，它定义了一系列可用的Execute命令，在全局安装的命令行包中尤其常见。这是一个pm2bin示例："bin":{"pm2":"./bin/pm2","pm2-dev":"./bin/pm2-dev","pm2-docker":"./bin/pm2-docker","pm2-runtime":"./bin/pm2-runtime"}，上面的对象表示安装后输入pm2实际运行{模块目录}/bin/pm2，等等。带有bin信息的包，本地安装后，可执行文件会在./node_modules/.bin下，如果是全局安装，可执行文件在$PATH下，对应npm目录。Tips有些朋友安装node环境的方式很奇怪。他们没有把全局安装的路径加到$PATH中，导致npminstall-g后提示找不到命令。最好查看自己的$PATHman这里是manuel，意思是manual，不是man，也不是上面说的main。这是指定一个（或多个）文件，用于在执行man{packagename}时向用户显示手册的内容。稍微了解一下linux的基础知识，就不细说了。目录这个领域挺无语的。它是一个对象，其中包含诸如lib`binmandocexampletest`之类的属性。主要是用来告诉用户我的一些功能目录放在哪里。专业的特点。除此之外，暂时没有实际应用。"directories":{"bin":"./bin","doc":"./doc","lib":"./lib","man":"./man"}，repository属性很明显，就是放你的git地址，格式如下："repository":{"type":"git","url":"https://github.com/npm/npm.git"}，Tips部分有一些缩写，自己看原文。scripts是重点！"scripts":{"start":"nodeapp.js","any":"anycommand&&exit0",}，以上两个配置提供了两个命令npm对应的实际运行启动并npm运行任何。至于什么时候需要运行，什么时候不需要运行，具体可以看npmscripts，足以单独开一章讲解。Tips除了定义一些fast快捷命令、脚本和一些预定义的类似钩子的命令，如preinstall和postinstall，可以在包安装前后自动执行一些操作。详情请参考以上连结。config这是一个对象结构体，定义了执行脚本时的一些配置参数等等，跟scripts属性有很大关系。我还没有用过，等我研究了再补充。目前可以参考npm-config依赖的前两个devDependencies和peerDependencies。提醒的是，你要自己判断dev安装的是哪个package。值得注意的是，peerDependencies是一个不常见的属性。它用于您的包，不依赖于模块A，但要使用您的包，您必须将其安装在当前项目中。A.比如你的my-project引入了people模块，还有一个people-fly，只有你的my-project对people有用的时候才可以用，但是people-fly的源码并没有直接使用人。这时候people-fly的package.json会声明peerDependencies包含people。上面这一段多看几遍应该就明白了。bundledDependencies是特定场景的属性。我个人从未使用过它。bundledDependencies是一个字符串数组，内容只能是dependencies和devDependencies中声明的包。这样就可以在npmpublish和npmpack中打包一些依赖了。Tips:dependencies中简单声明的包会在时安装，然后从npm重新安装。打包好的会在当前模块安装的时候一起下载。想想如何自己应用它。我没用过。optionalDependencies是可选的依赖？npm通常会在某些依赖安装失败时报错并中断运行，但是写在optionalDependencies中的依赖不会。要正确支持这个功能，你还应该注意判断这些特定的依赖是否存在于你的源代码中。其实是很麻烦和废话的操作。engines"engines":{"node":">=0.10.3<0.12"}这个属性可以声明你的包需要在什么样的node环境下运行（npm也可以声明）。但是，只有在用户配置了npm的engine-strict后才有意义，否则只会出现警告（程序员看不到警告）被engineStrict忽略，最新的npm已经弃用了这个。os看两个例子"os":["darwin","linux"]"os":["!win32"]显然Opinion是操作系统的黑白名单，比如你开发的工具只支持OSX，不支持Windows（这是合理的！），你可以用这个来声明cpu看两个例子“cpu":["x64","ia32"]"cpu":["!arm","!mips"]不想解释了，会玩这个属性的人就不用看了.如果private设置为true，npmpublish将无法进行。怎么说呢，有没有用？publishConfig定义了一个package发布到npm时的一些配置项，具体可以参考npm-config了解更多。..package.json其实就是一个json文件，你赋予一些字段更多的功能，就有意义了。自己开发功能的时候，可以自己发明一些字段来输入，只要对自己有用就可以了。例如，在我最近的一个项目中，我在package.json中添加了一个ci_cd对象，你知道的。
