package.json各个属性说明详解
什么是Node.js的模块（Module）？
在Node.js中，模块是⼀个库或框架，也是⼀个Node.js项⽬。Node.js项⽬遵循模块化的架构，当我们创建了⼀个Node.js项⽬，意味着创建了⼀个模块，这个模块的描述⽂件，被称为package.json ——  【长城_changcheng】
⼀般package.json放置在项⽬根⽬录下，其基本结构如下图所⽰：
package.json 结构图
属性介绍
description
字符串。⽤来描述当前项⽬的⼤致功能。
name
此项⽬包的名称。在不确定⾃⼰的包名能否使⽤之前，请先npm registry ⼀下，看看当前你喜欢的包名是
否已经被占⽤。
version
当前项⽬包的版本号。每⼀次项⽬改动时，在即将发布时，都要同步的去更改项⽬的版本号。⼀般格式为：x.y.z。意思是：⼤版本.中版本.⼩版本
keywords
放简介，字符串。⽅便屌丝们在 npm search中搜索
homepage
项⽬官⽹的url
bugs
你项⽬的提交问题的url和（或）邮件地址。这对遇到问题的屌丝很有帮助。
{ "url" : "github/owner/project/issues" , "email" : "project@hostname" }
你可以指定⼀个或者指定两个。如果你只想提供⼀个url，那就不⽤对象了，字符串就⾏。如果提供了url，它会被npm bugs命令使⽤。
license
你应该要指定⼀个许可证，让⼈知道使⽤的权利和限制的。最简单的⽅法是，假如你⽤⼀个像BSD或者MIT这样通⽤的许可证，就只需要指定⼀个许可证的名字，像这样：
{ "license" : "BSD" }
author
项⽬作者。可以指定name，email，url字段信息。也可以单独使⽤字符串来表⽰。
{“ author ”: { "name" : "Barney Rubble" , "email" : "b@rubble" , "url" : "barnyrubble.tumblr/" } } contributors
项⽬相关贡献者。是数组。⽤于罗列对应的贡献⼈。可以是单独的字符串，也可以分别指定name,email,url等属性。
{"contributors ":[ { "name" : "Barney Rubble" , "email" : "b@rubble" , "url" : "barnyrubble.tumblr/" } ]}
files
files是⼀个包含项⽬中的⽂件的数组。如果命名了⼀个⽂件夹，那也会包含⽂件夹中的⽂件。（除⾮被其他条件忽略了）你也可以提供⼀个.npmignore⽂件，让即使被包含在files字段中得⽂件被留下。其实就像.gitignore⼀样。
{ "files": [ "bin/", "templates/", "test/" ]}
main
main字段是⼀个模块ID，它是⼀个指向你程序的主要项⽬。就是说，如果你包的名字叫foo，然后⽤户安装它，然后require("foo")，然后你的main模块的exports对象会被返回。这应该是⼀个相对于根⽬录的模块ID。对于⼤多数模块，它是⾮常有意义的，其他的都没啥。
{ "main": "bin/index.js"}
bin
很多包都有⼀个或多个可执⾏的⽂件希望被放到PATH中。（实际上，就是这个功能让npm可执⾏的）。要⽤这个功能，给package.json中的bin字段⼀个命令名到⽂件位置的map。初始化的时候npm会将他链接到prefix/bin（全局初始化）或
者./node_modules/.bin/（本地初始化）。
{ "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程序使⽤。如果只提供⼀个单⼀的⽂件，那么它初始化后就是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创建。
repository
指定你的代码存放的地⽅。这个对希望贡献的⼈有帮助。如果git仓库在github上，那么npm docs命令能到你。
scripts
“scripts”是⼀个由脚本命令组成的hash对象，他们在包不同的⽣命周期中被执⾏。key是⽣命周期事件，value是要运⾏的命令。
config
"config" hash可以⽤来配置⽤于包脚本中的跨版本参数。在实例中，如果⼀个包有下⾯的配置
{ "name" : "foo" , "config" : { "port" : "8080" } }
然后有⼀个“start”命令引⽤了npm_package_config_port环境变量，⽤户可以通过npm config set foo:por
t 8001来重写他。
dependencies
依赖是给⼀组包名指定版本范围的⼀个hash。这个版本范围是⼀个由⼀个或多个空格分隔的字符串。依赖还可以⽤tarball或者
git URL。
请不要将测试或过渡性的依赖放在dependencies。
对于引⽤包的版本号格式，以下都是合法的：
{ "dependencies" :  { "foo" : "1.0.0 - 2.9999.9999"  , "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/"  , "til" : "~1.2"  ,
"elf" : "~1.2.3"  , "two" : "2.x"  , "thr" : "3.3.x"  ,"vue":"*", "element-ui":"" } }
devDependencies
如果有⼈要⽤你的模块，但他们可能不需要你开发所使⽤的外部测试或者⽂档框架。在这种情况下，最好将这些附属的项⽬列在devDependencies中。这些东西会在根⽬录执⾏npm link或者npm install的时候初始化，并可以像其他npm配置参数⼀样管理。
peerDependencies
你的模块可能要暴露⼀个特定的接⼝，并由host⽂档来预期和指定。⽐如：
{  "name": "tea-latte",  "version": "1.3.5"  "peerDependencies": {    "tea": "2.x"  } }
这能保证你的package可以只和tea的2.x版本⼀起初始化。试图初始化另⼀个有会冲突的依赖的插件将导致⼀个错误。因此，确保你的插件的需求约束越弱越好，⽽不要去把它锁定到⼀个特定的版本。此属性尽量避免使⽤
bundledDependencies
⼀组包名，他们会在发布的时候被打包进去
engines
指定项⽬⼯作的环境。除⾮⽤户设置engine-strict标记，这个字段只是建议值。
{ "engines" : { "node" : ">=0.10.3 <0.12", "npm" : "~1.0.20" } }
engineStrict
如果你确定你的模块⼀定不会运⾏在你指定版本之外的node或者npm上，你可以在package.json⽂件中设置"engineStrict":true。它会重写⽤户的engine-strict设置。除⾮你⾮常⾮常确定，否则不要这样做。如果你的engines hash过度地限制，很可能轻易让⾃⼰陷⼊窘境。慎重地考虑这个选择。如果⼤家滥⽤它，它会再以后的npm版本中被删除。
os
可以指定你的模块要运⾏在哪些操作系统中
"os" : [ "darwin", "linux" ]
vue json字符串转数组
你也可以⽤⿊名单代替⽩名单，在名字前⾯加上“!”就可以了：
"os" : [ "!win32" ]
操作系统⽤process.platform来探测。虽然没有很好地理由，但它是同时⽀持⿊名单和⽩名单的。
cpu
如果你的代码只能运⾏在特定的cpu架构下，你可以指定⼀个
"cpu" : [ "x64", "ia32" ]
就像os选项，你也可以⿊⼀个架构：
"cpu" : [ "!arm", "!mips" ]
cpu架构⽤process.arch探测。
preferGlobal
如果包主要是需要全局安装的命令⾏程序，就设置它为true来提供⼀个warning给只在局部安装的⼈。它不会真正的防⽌⽤户在局部安装，但如果它没有按预期⼯作它会帮助防⽌产⽣误会。
{" preferGlobal ":true}
private
如果你设置"private": true，npm就不会发布它。
这是⼀个防⽌意外发布私有库的⽅式。如果你要确定给定的包是只发布在特定registry（如内部registry）的，⽤publishConfighash的描述来重写registry的publish-time配置参数。
publishConfig
这是⼀个在publish-time使⽤的配置集合。当你想设置tag或者registry的时候它⾮常有⽤，所以你可以确定⼀个给定的包没有打上“lastest”的tag或者被默认发布到全局的公开registry。任何配置都可以被重写，但当然可能只有“tag”和“registry”与发布的意图有关。
到此这篇关于package.json各个属性说明详解的⽂章就介绍到这了，更多相关package.json属性内容请搜索以前的⽂章或继续浏览下⾯的相关⽂章希望⼤家以后多多⽀持！

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。