json中文文档2020欧洲杯冠军竞猜官方网站

时间:2019-07-25 17:45来源:2020欧洲杯冠军竞猜官方网站
简介 nodejs npm package.json中文文书档案,nodejspackage.json 简介 本文书档案有全部package.json中必备的布局。它必须是的确的json,实际不是js对象。 正文书档案中描述的多多表现都受npm-confi

简介

nodejs npm package.json中文文书档案,nodejspackage.json

简介

本文书档案有全部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 || true; node-waf configure build"}
假若包的根目录有wscript文件,npm会私下认可将preinstall命令用node-waf举行编写翻译。

"scripts":{"preinstall": "node-gyp rebuild"}
假使包的根目录有binding.gyp文件,npm会暗中同意将preinstall命令用node-gyp进行编写翻译。

"contributors": [...]
若是包的根目录有AUTHOTiguanS文件,npm会暗中同意逐行按Name <email> (url)格式处理,邮箱和url是可选的。#号和空格开首的行会被忽视。

name

在package.json中最关键的便是name和version字段。他们都以必须的,若无就不可能install。name和version一齐构成的标志在如若中是唯一的。改换包应该同一时间改造version。

name是以那件事物的名字。注意:

1.不用把node大概js放在名字中。因为您写了package.json它就被假定成为了js,然则你可以用”engine”字段钦定多少个引擎(见后文)。
2.这几个名字会作为在UMuranoL的一有的、命令行的参数只怕文件夹的名字。任何non-url-safe的字符都是无法用的。
3.以此名字只怕会作为参数被传出require(),所以它应当非常短,但也要意义清晰。
4.在您爱上您的名字以前,你大概要去npm registry查看一下这些名字是还是不是早就被应用了。

version

在package.json中最重视的便是name和version字段。他们都以必须的,若无就十分的小概install。name和version一同组成的标记在假如中是独一的。更动包应该何况更换version。

version必须能被node-semver剖判,它被包在npm的注重中。(要自个儿用能够举行npm install semver)

可用的“数字”或者“范围”见semver(7).

description

放简要介绍,字符串。方便土冒们在npm search中搜寻。

keywords

第一字,数组、字符串。照旧方便土憋们在npm search中找找。

homepage

品种官方网址的url。

留神:那和“url”不等同。即便您放一个“url”字段,registry会以为是三个跳转到你宣布在别的地点的地址,然后喊你滚粗。

啊,滚粗,没开玩笑。

bugs

你项目标交给难题的url和(或)邮件地址。那对碰到难点的土憋很有救助。

大致少长度那样:

复制代码 代码如下:

{ "url" : ""
, "email" : "[email protected]"
}

你能够钦赐多少个依旧钦赐多个。即便您只想提供三个url,那就毫无对象了,字符串就行。

假诺提供了url,它会被npm bugs命令使用。

license

您应有要钦定二个许可证,令人领会使用的权利和限量的。

最简易的方法是,纵然你用叁个像BSD只怕MIT那样通用的证件照,就只须要内定三个许可证的名字,像这么:

复制代码 代码如下:

{ "license" : "BSD" }

借令你又更复杂的批准条件,或然想要提必要更加多地细节,能够这么:

复制代码 代码如下:

"licenses" : [
  { "type" : "MyLicense"
  , "url" : ""
  }
]

在根目录中提供叁个许可证文件也非常好的。

people fields: author, contributors

author是一人。contributors是一批人的数组。person是一个有name字段,可选的有url、email字段的目的,像这么:

复制代码 代码如下:

{ "name" : "Barney Rubble"
, "email" : "[email protected]"
, "url" : ""
}

或许能够把装有的东西都停放多个字符串里,npm会给您深入分析:

复制代码 代码如下:

"Barney Rubble <[email protected]> ()

email和url在二种样式中都以可选的。

也可以在您的npm用户消息中安装三个一等的maintainers字段。

files

files是一个包涵项目中的文件的数组。假若命名了三个文本夹,这也会包罗文件夹中的文件。(除非被别的规范忽略了)

您也得以提供二个.npmignore文书,让纵然被含有在files字段中得文件被留下。其实就好像.gitignore同样。

main

main字段是三个模块ID,它是叁个指向你程序的严重性类型。就是说,如果您包的名字叫foo,然后用户安装它,然后require("foo"),然后您的main模块的exports对象会被重返。

那应该是一个针锋相对于根目录的模块ID。

对此绝大许多模块,它是特别有意义的,其余的都没啥。

bin

洋洋包都有一个或多少个可实行的文书希望被内置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程序使用。

比如只提供一个单一的公文,那么它发轫化后正是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文件夹,但真的是任重(Ren Zhong)而道远的元新闻。

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" : ""
  }
"repository" :
  { "type" : "svn"
  , "url" : ""
  }

U奥迪Q5L应该是公然的(即就是只读的)能一贯被未经过修改的版本调整程序管理的url。不应有是多个html的类型页面。因为它是给Computer看的。

scripts

“scripts”是三个由脚本命令组成的hash对象,他们在包差别的生命周期中被实行。key是生命周期事件,value是要运营的吩咐。

参见 npm-scripts(7)

config

“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 ULacrosseL。

请不要将测验或过渡性的依赖播在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'
9.* 所有
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.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" : ""
  , "til" : "~1.2"
  , "elf" : "~1.2.3"
  , "two" : "2.x"
  , "thr" : "3.3.x"
  }
}

依赖URL

能够钦点三个tarball U昂科威L,这几个tarball将要包被开头化的时候下载并开头化。

依赖Git URL

Git urls 能够是底下二种方式:

复制代码 代码如下:

git://github.com/user/project.git#commit-ish
git ssh://[email protected]:project.git#commit-ish
git ssh://[email protected]/project.git#commit-ish
git  protected]](
git  protected]](

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或然会时有发生下边包车型地铁依据关系

复制代码 代码如下:

├── [email protected]
└── [email protected]

精算开头化另叁个有会冲突的信赖的插件将招致三个谬误。因而,确定保证您的插件的须求约束越弱越好,而毫无去把它锁定到二个一定的本子。

要是这么些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同样。只是它运转错误。

拍卖缺少依赖也是你的次第的任务。举例像这么:

复制代码 代码如下:

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

optionalDependencies会覆盖dependencies中同名的项,所以一般比只放在三个地点好。

engines

你能够钦赐专门的学业的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

您能够内定你的模块要运营在哪些操作系统中:

复制代码 代码如下:

"os" : [ "darwin", "linux" ]

你也得以用黑名单取代白名单,在名字前边加上“!”就足以了:

复制代码 代码如下:

"os" : [ "!win32" ]

操作系统用process.platform来探测。

尽管如此从未很好地理由,但它是同期帮衬黑名单和白名单的。

cpu

假定您的代码只好运维在特定的cpu架构下,你能够内定三个:

复制代码 代码如下:

"cpu" : [ "x64", "ia32" ]

就如os选项,你也足以黑贰个架构:

复制代码 代码如下:

"cpu" : [ "!arm", "!mips" ]

cpu架构用process.arch探测。

preferGlobal

要是包首假使亟需全局安装的一声令下行程序,就设置它为true来提供叁个warning给只在部分安装的人。

它不会真的的严防用户在一部分安装,但一旦它从不按预期专门的工作它会拉拉扯扯防止发生误会。

private

举例你设置"private": true,npm就不会宣布它。

这是三个预防意外发表私有库的办法。若是你要规定给定的包是只颁发在一定registry(如内部registry)的,用publishConfighash的陈述来重写registry的publish-time配置参数。

publishConfig

这是二个在publish-time使用的配置集合。当您想设置tag大概registry的时候它不行有用,所以您能够鲜明三个加以的包未有打上“lastest”的tag只怕被私下认可发表到全局的公然registry。

别的配置都得以被重写,但当然可能独有“tag”和“registry”与公布的意图有关。

参见npm-config(7)有能够被重写的列表。

package.json

Specifics of npm's package.json handling (npm@1.3.15) —— 高兴木匠艾瑞克翻译 Issue

初稿链接:http://www.mujiang.info/translation/npmjs/files/package.json.html

正文书档案有所有package.json中必备的配置。它必须是真正的json,并非js对象。

nodejs的npm彰显为无效命令

找到node的安装目录。找到npm命令。将该路径放到情况变量中。  

DESCRIPTION

正文书档案有全部package.json中至关重要的布局。它必须是的确的json,并不是js对象。
本文书档案中描述的浩大作为都受npm-config(7)的影响。

正文书档案中描述的累累行为都受npm-config(7)的震慑。

node里面npm注册用户报错,解释

参见bug集:github.com/npm/npm/issues/4363

使用下边发号施令设置email,能够消除
npm config set email [email protected]  

npm package.json普通话文书档案,nodejspackage.json 简要介绍本文书档案有全部package.json中不可缺少的安顿。它必须是真的的json,实际不是js对象。 本文书档案中描述...

name

在package.json中首要的正是name和version字段。他们都以必须的,若无就不也许install。name和version一齐构成的标志在如果中是独一无二的。更动包应该同有时候改换version。
name是其一东西的名字。注意:
并不是把node可能js放在名字中。因为您写了package.json它就被假定成为了js,不过你可以用"engine"字段内定三个引擎(见后文)。
以此名字会作为在UCR-VL的一部分、命令行的参数或许文件夹的名字。任何non-url-safe的字符都以无法用的。
本条名字大概会作为参数被传播require(),所以它应该相当的短,但也要意义清晰。
在您爱上您的名字以前,你可能要去npm registry查看一下那个名字是不是早就被选取了。 http://registry.npmjs.org/

默认值

version

在package.json中重大的正是name和version字段。他们都以必须的,若无就无法install。name和version一齐组成的标记在如果中是举世无双的。改造包应该并且退换version。
version必须能被 node-semver解析,它被包在npm的重视性中。(要和煦用能够实行npm install semver)
愈来愈多可用的“数字”也许“范围”见semver(7).
description
Put a description in it. It's a string. This helps people discover your package, as it's listed in npm search
.

npm会依据包内容设置有个别暗中同意值。

keywords

放简要介绍,字符串。方便土憋们在 npm search中找找。

复制代码 代码如下:

homepage

品种官网的url。
注意:这和“url”同等。假如你放三个“url”字段,registry会感到是三个跳转到你发表在其他地点的地方,然后喊你滚粗。 嗯,滚粗,没开玩笑。
啊,滚粗,没开玩笑。

"scripts": {"start": "node server.js"}
假设包的根目录有server.js文件,npm会私下认可将start命令设置为node server.js。

bugs

您项指标交给难点的url和(或)邮件地址。这对境遇标题标土憋很有支持。
大约长那样:

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

您能够钦定一个要么钦赐五个。假设你只想提供四个url,那就不用对象了,字符串就行。
假诺提供了url,它会被npm bugs命令使用。

"scripts":{"preinstall": "node-waf clean || true; node-waf configure build"}
设若包的根目录有wscript文件,npm会暗许将preinstall命令用node-waf进行编写翻译。

license

你必供给内定二个牌照,令人领略使用的义务和范围的。
最简便的措施是,借令你用贰个像BSD大概MIT那样通用的证件本,就只须要钦命三个证件本的名字,像那样:

{ "license" : "BSD" }

只要您有更头昏眼花的批准条件,或者想要提须求更加多地细节,能够那样:

"licenses" : [ 
   { 
       "type" : "MyLicense" , 
       "url" : "http://github.com/owner/project/path/to/license" 
   }
]

在根目录中提供二个证件本文件也蛮好的。
people fields: author, contributors
author是一人。contributors是一群人的数组。person是壹个有name字段,可选的有url、email字段的靶子,像那样:

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

要么能够把具备的事物都放置三个字符串里,npm会给您剖析:
"Barney Rubble b@rubble.com (http://barnyrubble.tumblr.com/)

email和url在二种情势中都是可选的。
也能够在你的npm用户信息中装置二个世界级的maintainers字段。

"scripts":{"preinstall": "node-gyp rebuild"}
要是包的根目录有binding.gyp文件,npm会私下认可将preinstall命令用node-gyp举行编写翻译。

files

files是四个涵盖项目中的文件的数组。如若命名了一个文件夹,那也会包蕴文件夹中的文件。(除非被其余标准忽略了)
您也足以提供叁个.npmignore文本,让尽管被含有在files字段中得文件被留下。其实仿佛.gitignore同样。

"contributors": [...]
设若包的根目录有AUTHO瑞鹰S文件,npm会暗中同意逐行按Name <email> (url)格式管理,邮箱和url是可选的。#号和空格开首的行会被忽略。

main

main字段配置壹个文件名指向模块的输入程序。固然你包的名字叫foo,然后用户require("foo"),main配置的模块的exports对象会被再次回到。
那应该是二个针锋相对于根目录的公文路线。
对此领先48%模块,它是非常有意义的,其余的都没啥。

name

bin

无数包都有八个或七个可实践的公文希望被置于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" } }

在package.json中最要害的正是name和version字段。他们都以必须的,若无就无法install。name和version一齐构成的标志在借使中是唯一的。更动包应该同有的时候间退换version。

man

点名几个纯净的文件只怕三个文件数组供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创建。

name是其一东西的名字。注意:

directories

CommonJS Packages职业表明了两种艺术让您能够用directories
hash标示出包得协会。如若看一下npm's package.json,你会看出有directories标示出doc, lib, and man。
在今后,那些音信大概会被用到。

1.永不把node只怕js放在名字中。因为您写了package.json它就被假定成为了js,可是你可以用”engine”字段钦定八个引擎(见后文)。
2.以此名字会作为在U奥迪Q5L的一局地、命令行的参数或许文件夹的名字。任何non-url-safe的字符都以不能够用的。
3.那几个名字或许会作为参数被盛传require(),所以它应有相当的短,但也要意义清晰。
4.在您爱上您的名字在此之前,你只怕要去npm registry查看一下这么些名字是或不是曾经被接纳了。

directories.lib

报告土冒们你的库文件夹在何地。近期向来不怎么特别的事物须求用到lib文件夹,但着实是关键的元消息。

version

directories.bin

固然你内定二个“bin”目录,然后在老大文件夹中得全部文件都会被看作"bin"字段使用。
譬喻您早已钦点了“bin”字段,这这一个就不算。

在package.json中最入眼的正是name和version字段。他们都以必须的,若无就不恐怕install。name和version一同构成的标记在即便中是当世无双的。改造包应该同期改造version。

directories.man

贰个放满man页面的公文夹。贴心地创造八个“man”字段。A folder that is full of man pages. Sugar to generate a "man" array bywalking the folder.

version必须能被node-semver解析,它被包在npm的正视中。(要谐和用可以实践npm install semver)

directories.doc

将markdown文件放在此处。最终,那些会被很好地出示出来,大概,某一天。Put markdown files in here. Eventually, these will be displayed nicely,maybe, someday.

可用的“数字”或者“范围”见semver(7).

directories.example

将事例脚本放在那边。某一天,它也许会以智慧的措施展现出来。

description

repository

点名你的代码贮存的地点。这几个对愿意贡献的人有扶持。借使git货仓在github上,那么npm docs
命令能找到您。
这样做:

"repository" : { 
  "type" : "git" , 
  "url" : "http://github.com/isaacs/npm.git" 
}

"repository" : { 
  "type" : "svn" , 
  "url" : "http://v8.googlecode.com/svn/trunk/" 
}

UPRADOL应该是当面包车型大巴(即便是只读的)能一向被未经过改造的版本调整造进程序管理的url。不应当是二个html的品种页面。因为它是给计算机看的。

放简单介绍,字符串。方便土憋们在npm search中搜索。

scripts

“scripts”是多少个由脚本命令组成的hash对象,他们在包不相同的生命周期中被实行。key是生命周期事件,value是要运转的授命。
参见 npm-scripts(7)

keywords

config

"config" hash能够用来布局用于包脚本中的跨版本参数。在实例中,借使二个包有上边包车型地铁配置:

{ "name" : "foo", "config" : { "port" : "8080" } }

然后有八个“start”命令引用了npm_package_config_port
情状变量,用户能够通过npm config set foo:port 8001
来重写她。
参见 npm-config(7) 和 npm-scripts(7)。

要害字,数组、字符串。依旧有益土憋们在npm search中追寻。

dependencies

借助于是给一组包名内定版本范围的八个hash。这几个版本范围是一个由一个或多个空格分隔的字符串。信赖还足以用tarball大概git U大切诺基L。
请不要将测量检验或过渡性的依附放在dependencies中。
见下文的devDependencies
详见semver(7).
version必须完全和version一致

version 必须比version 大
=version 同上
<version 同上
<=version 同上
~version 约等于,见semver(7)
1.2.x 、1.2.0、 1.2.1 等,但不包括1.3.0

举个例子上边都以官方的:

{ 
"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" : "http://asdf.com/asdf.tar.gz" , 
    "til" : "~1.2" , 
    "elf" : "~1.2.3" , 
    "two" : "2.x" , 
    "thr" : "3.3.x" 
  }
}
  • ##### 依赖URL

能够内定多个tarball URL,这些tarball就要包被初阶化的时候下载并伊始化。
依赖Git URL
Git urls 可以是底下三种样式:

git://github.com/user/project.git#commit-ishgit 
ssh://user@hostname:project.git#commit-ishgit 
ssh://user@hostname/project.git#commit-ishgit 
http://user@hostname/project/blah.git#commit-ishgit 
https://user@hostname/project/blah.git#commit-ishgit
  • ##### 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" 
  }
}

homepage

devDependencies

仅在开垦条件下选用的依赖性包,放在devDependencies中。

线上宣布时,假使dev正视中的包无需,那么能够实行:
npm prune --production 来删除已安装的dev信赖包,以缩减项目体积。

对于塑造步骤,比如要求编译CoffeeScript,能够用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
兴许会爆发上面包车型的士重视关系
├── 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"。

类型官方网站的url。

bundledDependencies

一组包名,他们会在揭发的时候被打包进去。
拼成"bundleDependencies"
(缺d)也可以。

小心:那和“url”不同。假使您放三个“url”字段,registry会认为是一个跳转到你宣布在别的地点的地点,然后喊你滚粗。

optionalDependencies

比如一个注重可用,但你指望在它安装不当的时候npm也能延续开首化,那么您可以把它身处optionalDependencieshash中。那是八个包名到版本也许url的map,仿佛dependencies hash一样。

线上揭露时能够挑选不安装此目录下的注重性:
npm install --no-optional

管理缺乏信赖也是你的先后的义务。比如像这么:

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

optionalDependencies会覆盖dependencies中同名的项,所以一般比只放在二个地点好。

啊,滚粗,没开玩笑。

engines

你可以钦点专门的学问的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过度地范围,很恐怕Infiniti制让协调沦为窘境。审慎地想念这么些选项。即便大家滥用它,它会再后来的npm版本中被删去。

  • ##### os

你能够内定你的模块要运转在什么操作系统中:
"os" : [ "darwin", "linux" ]

您也足以用黑名单代替白名单,在名字后边加上“!”就可以了:
"os" : [ "!win32" ]

操作系统用process.platform来探测。
就算未有很好地理由,但它是还要帮助黑名单和白名单的。

  • ##### cpu

若是你的代码只好运营在一定的cpu框架结构下,你可以钦定三个:
"cpu" : [ "x64", "ia32" ]

就好像os选项,你也得以黑三个架构:
"cpu" : [ "!arm", "!mips" ]

cpu架构用process.arch探测。

  • ##### preferGlobal

若是包首纵然索要全局安装的通令行程序,就安装它为true
来提供叁个warning给只在一些安装的人。
它不会真正的防护用户在有的安装,但假设它并未有按预期工作它会支援防止产生误会。

  • ##### private

如若你设置 "private": true,npm就不会发布它。
那是叁个防范意外发表私有库的章程。假若您要明确给定的包是只公布在特定registry(如内部registry)的,用publishConfig hash的描述来重写registry的publish-time配置参数。

  • ##### publishConfig

那是三个在publish-time使用的计划会集。当你想设置tag或然registry的时候它那个有用,所以你能够规定二个加以的包未有打上“lastest”的tag恐怕被暗中认可发布到全局的公开registry。
别的配置都能够被重写,但当然或然独有“tag”和“registry”与公布的来意有关。
参见npm-config(7)有能够被重写的列表。

  • ##### DEFAULT VALUES

npm会依照包的剧情设置有个别默许值。
"scripts": {"start": "node server.js"}

若果包的根目录有server.js文件,npm会暗许将start命令设置为node server.js。

"scripts":{"preinstall": "node-waf clean || true; 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是可选的。#号和空格起头的行会被忽略。

SEE ALSO
semver(7)
npm-init(1)
npm-version(1)
npm-config(1)
npm-config(7)
npm-help(1)
npm-faq(7)
npm-install(1)
npm-publish(1)
npm-rm(1)

bugs

您项指标付出难点的url和(或)邮件地址。那对境遇标题标土冒很有赞助。

大约少长度那样:

复制代码 代码如下:

{ "url" : ""
, "email" : "project@hostname.com"
}

您能够钦命三个大概钦命四个。倘若你只想提供三个url,那就绝不对象了,字符串就行。

若果提供了url,它会被npm bugs命令使用。

license

您必定要钦赐叁个证件本,令人明白使用的职分和范围的。

最简便的诀倘使,假设你用一个像BSD也许MIT那样通用的许可证,就只要求内定二个牌照的名字,像那样:

复制代码 代码如下:

{ "license" : "BSD" }

一旦您又更头昏眼花的准予条件,可能想要提须要更加多地细节,能够那样:

复制代码 代码如下:

"licenses" : [
  { "type" : "MyLicense"
  , "url" : ""
  }
]

在根目录中提供二个证照文件也非常好的。

people fields: author, contributors

author是一人。contributors是一批人的数组。person是多个有name字段,可选的有url、email字段的对象,像这么:

复制代码 代码如下:

{ "name" : "Barney Rubble"
, "email" : "b@rubble.com"
, "url" : ""
}

抑或能够把富有的事物都置于四个字符串里,npm会给你分析:

复制代码 代码如下:

"Barney Rubble <b@rubble.com> ()

email和url在两种情势中都是可选的。

也足以在你的npm用户音信中设置三个五星级的maintainers字段。

files

files是贰个蕴涵项目中的文件的数组。倘职务名了二个文书夹,那也会含有文件夹中的文件。(除非被其余标准忽略了)

你也能够提供三个.npmignore文件,让就算被含有在files字段中得文件被留下。其实就疑似.gitignore同样。

main

main字段是叁个模块ID,它是三个指向您程序的重要项目。就是说,要是你包的名字叫foo,然后用户设置它,然后require("foo"),然后您的main模块的exports对象会被再次回到。

那应当是多少个周旋于根目录的模块ID。

对于好多模块,它是极度有含义的,其余的都没啥。

bin

广大包都有一个或多少个可奉行的文书希望被停放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程序使用。

假使只提供一个单一的公文,那么它开端化后就是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" : ""
  }
"repository" :
  { "type" : "svn"
  , "url" : ""
  }

U瑞鹰L应该是当着的(即就是只读的)能平素被未通过修改的版本调控造进程序管理的url。不应当是贰个html的连串页面。因为它是给计算机看的。

scripts

“scripts”是贰个由脚本命令组成的hash对象,他们在包区别的生命周期中被实践。key是生命周期事件,value是要运维的命令。

参见 npm-scripts(7)

config

“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 U翼虎L。

请不要将测量试验或过渡性的依赖放在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'
9.* 所有
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.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" : ""
  , "til" : "~1.2"
  , "elf" : "~1.2.3"
  , "two" : "2.x"
  , "thr" : "3.3.x"
  }
}

依赖URL

能够钦点贰个tarball UCRUISERL,这么些tarball将要包被开始化的时候下载并开首化。

依赖Git URL

Git urls 能够是下边三种样式:

复制代码 代码如下:

git://github.com/user/project.git#commit-ish
git ssh://user@hostname:project.git#commit-ish
git ssh://user@hostname/project.git#commit-ish
git
git

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恐怕会生出下边包车型客车注重性关系

复制代码 代码如下:

├�� 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同样。只是它运转错误。

拍卖贫乏重视也是您的顺序的责任。举例像这么:

复制代码 代码如下:

2020欧洲杯冠军竞猜官方网站,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()
}

optionalDependencies会覆盖dependencies中同名的项,所以平日比只放在一个地点好。

engines

您能够钦赐工作的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

您能够钦点你的模块要运维在哪些操作系统中:

复制代码 代码如下:

"os" : [ "darwin", "linux" ]

你也能够用黑名单替代白名单,在名字前面加上“!”就足以了:

复制代码 代码如下:

"os" : [ "!win32" ]

操作系统用process.platform来探测。

纵然如此未有很好地理由,但它是同不日常候协助黑名单和白名单的。

cpu

若是你的代码只好运维在特定的cpu框架结构下,你能够钦点叁个:

复制代码 代码如下:

"cpu" : [ "x64", "ia32" ]

就如os选项,你也足以黑二个框架结构:

复制代码 代码如下:

"cpu" : [ "!arm", "!mips" ]

cpu架构用process.arch探测。

preferGlobal

万一包首假如索要全局安装的一声令下行程序,就安装它为true来提供一个warning给只在局地安装的人。

它不会真正的严防用户在某个安装,但要是它从不按预期职业它会赞助幸免发生误会。

private

假若您设置"private": true,npm就不会揭橥它。

那是三个防备意外公布私有库的方法。假诺你要分明给定的包是只颁发在一定registry(如内部registry)的,用publishConfighash的汇报来重写registry的publish-time配置参数。

publishConfig

那是多少个在publish-time使用的安插集结。当你想设置tag恐怕registry的时候它非常有用,所以您能够规定叁个加以的包未有打上“lastest”的tag可能被暗许发表到全局的公然registry。

别的配置都得以被重写,但当然可能只有“tag”和“registry”与发表的意向有关。

参见npm-config(7)有能够被重写的列表。

你恐怕感兴趣的小说:

  • NodeJS、NPM安装配备步骤(windows版本) 以及情况变量详解
  • NodeJs安装npm包直接退步的缓和措施
  • Windows系统下nodejs、npm、express的下载和设置教程详解
  • Nodejs中 npm常用命令详解
  • nodejs npm包管理的配备方式及常用命令介绍
  • nodejs npm install全局安装和地面安装的区分
  • 关于Mac下安装nodejs、npm和cnpm的教程

编辑:2020欧洲杯冠军竞猜官方网站 本文来源:json中文文档2020欧洲杯冠军竞猜官方网站

关键词: 欧洲杯竞猜