nodejs npm package.json 중국어 document_node.js
- WBOY원래의
- 2016-05-16 16:37:221604검색
소개
이 문서에는 package.json에 필요한 모든 구성이 있습니다. js 객체가 아닌 실제 json이어야 합니다.
이 문서에 설명된 동작의 대부분은 npm-config(7)의 영향을 받습니다.
기본값
npm은 패키지 콘텐츠에 따라 일부 기본값을 설정합니다.
패키지의 루트 디렉터리에 server.js 파일이 있는 경우 npm은 기본적으로 시작 명령을 node server.js로 설정합니다.
"scripts":{"preinstall": "node-waf clean || true; node-waf 구성 빌드"}
패키지의 루트 디렉터리에 wscript 파일이 있는 경우 npm은 기본적으로 node-waf를 사용하여 사전 설치 명령을 컴파일합니다.
"scripts":{"preinstall": "node-gyp 재구축"}
패키지의 루트 디렉터리에 바인딩.gyp 파일이 있는 경우 npm은 기본적으로 node-gyp를 사용하여 사전 설치 명령을 컴파일합니다.
"참여자": [...]
패키지의 루트 디렉터리에 AUTHORS 파일이 있는 경우 npm은 기본적으로 Name
이름
package.json에서 가장 중요한 필드는 이름 및 버전 필드입니다. 이는 모두 필수이며 해당 항목 없이는 설치할 수 없습니다. 이름과 버전으로 구성된 식별자는 고유한 것으로 간주됩니다. 패키지를 변경하면 버전도 변경되어야 합니다.
name은 이 물건의 이름입니다. 참고:
1. 이름에 node나 js를 넣지 마세요. package.json을 작성했기 때문에 js로 간주되지만 "engine" 필드를 사용하여 엔진을 지정할 수 있습니다(아래 참조).
2. 이 이름은 URL, 명령줄 매개변수 또는 폴더 이름의 일부로 사용됩니다. URL 안전이 아닌 문자는 허용되지 않습니다.
3. 이 이름은 매개변수로 require()에 전달될 수 있으므로 짧지만 의미가 명확해야 합니다.
4. 이름이 마음에 들기 전에 npm 레지스트리를 확인하여 해당 이름이 이미 사용 중인지 확인할 수 있습니다. http://registry.npmjs.org/
버전
package.json에서 가장 중요한 필드는 이름 및 버전 필드입니다. 이는 모두 필수이며 해당 항목 없이는 설치할 수 없습니다. 이름과 버전으로 구성된 식별자는 고유한 것으로 간주됩니다. 패키지를 변경하면 버전도 변경되어야 합니다.
버전은 npm 종속 항목에 포함된 node-semver로 구문 분석할 수 있어야 합니다. (직접 사용하고 싶다면 npm install semver를 실행하면 됩니다)
사용 가능한 "숫자" 또는 "범위"는 semver(7)를 참조하세요.
설명
소개, 문자열을 넣어주세요. 패자는 npm 검색으로 검색하는 것이 편리합니다.
키워드
키워드, 배열, 문자열. 패자들이 npm 검색으로 검색하는 것도 편리합니다.
홈페이지
프로젝트 공식 홈페이지 URL입니다.
참고: 이는 "url"과 동일하지 않습니다. "url" 필드를 입력하면 레지스트리는 귀하가 다른 곳에 게시한 주소로 이동하는 것으로 간주하여 길을 잃으라고 지시합니다.
그래, 엿먹어, 농담이 아냐.
버그
프로젝트 제출 문제의 URL 및/또는 이메일 주소입니다. 이는 문제가 있는 디아오시들에게 도움이 됩니다.
다음과 같습니다.
{ "url": "http://github.com/owner/project/issues"
, "이메일" : "project@hostname.com"
}
1개 또는 2개를 지정할 수 있습니다. URL만 제공하려는 경우에는 개체가 필요하지 않고 문자열만 제공하면 됩니다.
URL이 제공되면 npm bugs 명령에서 사용됩니다.
라이센스
사용권리와 제한사항을 사람들이 알 수 있도록 라이선스를 명시해야 합니다.
가장 간단한 방법은 BSD나 MIT와 같은 일반 라이센스를 사용하는 경우 다음과 같이 라이센스 이름만 지정하면 됩니다.
{ "라이센스" : "BSD" }
라이센스 조건이 더 복잡하거나 더 자세한 정보를 제공하려는 경우 다음을 수행할 수 있습니다.
"라이센스": [
{ "유형": "내 라이센스"
, "url": "http://github.com/owner/project/path/to/license"
}
]
루트 디렉터리에 라이센스 파일을 제공하는 것도 좋은 생각입니다.
인물 필드: 작성자, 참여자
작가는 사람입니다. 기여자는 일련의 사람들입니다. Person은 다음과 같이 이름 필드, 선택적 URL 및 이메일 필드가 있는 객체입니다.
{ "name" : "바니 러블"
, "이메일" : "b@rubble.com"
, "url": "http://barnyrubble.tumblr.com/"
}
또는 모든 것을 문자열에 넣으면 npm이 이를 구문 분석할 수 있습니다.
"Barney Rubble
이메일과 URL은 두 형식 모두 선택 사항입니다.
npm 사용자 정보에서 최상위 관리자 필드를 설정할 수도 있습니다.
파일
files는 프로젝트의 파일을 포함하는 배열입니다. 폴더 이름이 지정되면 해당 폴더의 파일도 포함됩니다. (다른 조건에서 무시되지 않는 한)
파일 필드에 포함되어 있어도 파일이 유지되도록 .npmignore 파일을 제공할 수도 있습니다. 실제로는 .gitignore와 같습니다.
메인
기본 필드는 프로그램의 기본 프로젝트에 대한 포인터인 모듈 ID입니다. 즉, 패키지 이름이 foo이고 사용자가 이를 설치한 다음 require("foo")하면 기본 모듈의 내보내기 개체가 반환됩니다.
루트 디렉터리에 상대적인 모듈 ID여야 합니다.
대부분의 모듈에서는 완벽하게 이해되며 다른 것은 없습니다.
빈
많은 패키지에는 PATH에 배치하려는 실행 파일이 하나 이상 있습니다. npm을 사용하면 엄마가 더 이상 걱정할 필요가 없습니다(실제로 npm을 실행 가능하게 만드는 것이 바로 이 기능입니다).
이 기능을 사용하려면 package.json의 bin 필드에 명령 이름에서 파일 위치까지의 매핑을 제공하세요. 초기화 중에 npm은 이를 prefix/bin(전역 초기화) 또는 ./node_modules/.bin/(로컬 초기화)에 연결합니다.
예를 들어 npm에는 다음이 포함됩니다.
{ "bin" : { "npm" : "./cli.js" } }
따라서 npm을 초기화하면 /usr/local/bin/npm에 cli.js 스크립트에 대한 심볼릭 링크가 생성됩니다.
패키지 이름과 동일한 이름의 실행 파일이 하나만 있는 경우. 그런 다음 다음과 같은 문자열을 사용할 수 있습니다.
{ "이름": "내 프로그램"
, "버전": "1.2.5"
, "bin": "./path/to/program" }
결과는 다음과 같습니다.
{ "이름": "내 프로그램"
, "버전": "1.2.5"
, "bin" : { "내 프로그램" : "./path/to/program" } }
남자
man 프로그램에서 사용할 단일 파일 또는 파일 배열을 지정합니다.
단일 파일만 제공되는 경우 실제 파일 이름에 관계없이 초기화 후 man
{ "이름" : "foo"
, "버전": "1.2.3"
, "description" : "fooing foo를 위한 패키지 foo fooer"
, "main" : "foo.js"
, "남자": "./man/doc.1"
}
이런 방식으로 man foo는 ./man/doc.1 파일을 사용할 수 있습니다.
파일 이름이 패키지 이름으로 시작하지 않으면 다음 접두어가 붙습니다.
{ "이름" : "foo"
, "버전": "1.2.3"
, "description" : "fooing foo를 위한 패키지 foo fooer"
, "main" : "foo.js"
, "man" : [ "./man/foo.1", "./man/bar.1" ]
}
man foo 및 man foo-bar에 대한 파일이 생성됩니다.
man 파일은 숫자로 끝나야 하며 선택적으로 .gz 접미사로 압축되어야 합니다. 숫자는 파일이 설치된 매뉴얼 섹션을 나타냅니다.
{ "이름" : "foo"
, "버전": "1.2.3"
, "description" : "fooing foo를 위한 패키지 foo fooer"
, "main" : "foo.js"
, "man" : [ "./man/foo.1", "./man/foo.2" ]
}
은 man foo와 man 2 foo에 대해 생성됩니다.
디렉토리
CommonJS 패키지 사양에서는 디렉터리 해시를 사용하여 패키지 구조를 나타낼 수 있는 여러 가지 방법을 설명합니다. npm의 package.json을 보면 doc, lib 및 man이라는 레이블이 붙은 디렉터리가 있음을 알 수 있습니다.
이 정보는 향후에도 사용될 수 있습니다.
directories.lib
패자에게 라이브러리 폴더가 어디에 있는지 알려주세요. 현재 lib 폴더를 사용하는데 있어서 특별한 것은 없지만 중요한 메타 정보입니다.
디렉토리.bin
"bin" 디렉터리를 지정하면 해당 폴더의 모든 파일이 "bin" 필드로 사용됩니다.
"bin" 필드를 지정한 경우 아무 효과가 없습니다.
directories.man
맨 페이지로 가득 찬 폴더입니다. "man" 필드를 조심스럽게 만듭니다.
에 의해 "man" 배열을 생성하기 위한 맨 페이지로 가득 찬 폴더입니다.
폴더를 산책합니다.
directories.doc
여기에 마크다운 파일을 넣으세요. 결국 이것들은 아마도 언젠가는 멋지게 보여질 것입니다.
여기에 마크다운 파일을 넣으면 멋지게 표시될 것입니다.
어쩌면 언젠가는.
디렉터리.예
여기에 예시 스크립트를 넣으세요. 언젠가는 영리한 방식으로 나타날 수도 있습니다.
저장소
코드를 저장할 위치를 지정하세요. 이는 기여를 원하는 사람들에게 도움이 됩니다. git 저장소가 github에 있으면 npm docs 명령으로 찾을 수 있습니다.
다음을 수행하세요.
"저장소":
{ "유형": "git"
, "url": "http://github.com/isaacs/npm.git"
}
"저장소":
{ "유형": "svn"
, "url": "http://v8.googlecode.com/svn/trunk/"
}
URL은 수정되지 않은 버전 제어 프로그램에서 직접 처리할 수 있는 공개(읽기 전용) URL이어야 합니다. HTML 프로젝트 페이지가 아니어야 합니다. 왜냐하면 컴퓨터가 볼 수 있기 때문입니다.
스크립트
"스크립트"는 패키지의 다양한 수명 주기 동안 실행되는 스크립트 명령으로 구성된 해시 개체입니다. 키는 수명주기 이벤트이고 값은 실행할 명령입니다.
npm-scripts(7) 보기
구성
"config" 해시는 패키지 스크립트에 사용되는 버전 간 매개변수를 구성하는 데 사용될 수 있습니다. 예에서 패키지에 다음 구성이 있는 경우:
{ "이름" : "foo"
, "config" : { "포트" : "8080" } }
그런 다음 npm_package_config_port 환경 변수를 참조하는 "start" 명령이 있으며 사용자는 npm config set foo:port 8001을 통해 이를 재정의할 수 있습니다.
npm-config(7) 및 npm-scripts(7)를 참조하세요.
종속성
종속성은 패키지 이름 집합의 버전 범위를 지정하는 해시입니다. 버전 범위는 하나 이상의 공백으로 구분된 문자열입니다. 종속성은 tarball이나 git URL을 사용할 수도 있습니다.
종속성 해시에 테스트 또는 전환 종속성을 넣지 마세요. 아래의 devDependency를 참조하세요.
자세한 내용은 semver(7)을 참조하세요.
1.version은 버전과 완전히 일치해야 합니다
2.>버전은 버전보다 커야 합니다
3.>=version 위와 동일
4.<버전 위와 동일
5.<=version 위와 동일
6.~버전은 거의 같습니다. 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 URL' 참조
15. 예를 들어 다음은 합법적입니다.
{ "종속성":
{ "foo": "1.0.0 - 2.9999.9999"
, "바": ">=1.0.2 <2.1.2"
, "baz": ">1.0.2 <=2.3.4"
, "부" : "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"
, "2" : "2.x"
, "thr" : "3.3.x"
}
}
종속성 URL
패키지가 초기화될 때 다운로드되어 초기화될 tarball URL을 지정할 수 있습니다.
Git URL에 따라 다름
Git URL은 다음과 같은 형식일 수 있습니다.
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 http://user@hostname/project/blah.git#commit-ish
자식 https://user@hostname/project/blah.git#commit-ish
commit-ish는 git으로 체크아웃할 수 있는 태그, sha 또는 분기입니다. 기본값은 마스터입니다.
GitHub URL
버전 1.1.65 이후에는 "user/foo-project"를 사용하여 다음과 같은 GitHub URL을 참조할 수 있습니다.
{
"이름": "foo",
"버전": "0.0.0",
"종속성": {
"express": "visionmedia/express"
}
}
dev종속성
누군가 자신의 프로그램에서 모듈을 다운로드하여 사용하려는 경우, 사용하는 외부 테스트 또는 문서 프레임워크를 다운로드하여 구축하기를 원하지 않거나 필요하지 않을 수 있습니다.
이 경우에는 devDependency 해시에 이러한 종속 프로젝트를 나열하는 것이 좋습니다.
이것들은 루트 디렉터리에서 npm link나 npm install이 실행될 때 초기화되며, 다른 npm 구성 매개변수처럼 관리할 수 있습니다. 자세한 내용은 npm-config(7)를 참조하세요.
CoffeeScript 또는 기타 언어를 Javascript로 컴파일하는 등 플랫폼에 국한되지 않는 빌드 단계의 경우 사전 게시 스크립트를 사용하여 구현하고 devDependency에 배치합니다.
예:
{ "이름": "에토피아-와자",
"description": "즐거운 과일향이 나는 다양한 커피",
"버전": "1.2.3",
"devDependency": {
"coffee-script": "~1.6.3"
},
"스크립트": {
"prepublish": "coffee -o lib/ -c src/waza.coffee"
},
"메인": "lib/waza.js"
}
사전 게시 스크립트는 게시 전에 실행되므로 사용자가 사용하기 전에 직접 컴파일하도록 요구할 필요가 없습니다. 그리고 개발 모드(예: 로컬에서 npm install 실행)에서 이 스크립트는 더 나은 테스트를 위해 실행됩니다.
peerDependency
호스트에서 require가 필요하지 않은 경우와 같은 일부 시나리오에서는 호스트 도구나 라이브러리를 사용하여 패키지의 호환성 키를 표시하려고 합니다. 이는 일반적으로 플러그인을 참조하는 데 사용됩니다. 특히, 모듈은 호스트 문서에서 예상하고 지정한 특정 인터페이스를 노출할 수 있습니다.
예:
{
"name": "티라떼",
"버전": "1.3.5"
"peerDependency": {
"차": "2.x"
}
}
이렇게 하면 패키지가 2.x 버전의 tea로만 초기화될 수 있습니다. npm install tea-latte는 다음과 같은 종속성을 생성할 수 있습니다.
├�� tea-latte@1.3.5
└�� tea@2.2.0
종속성이 충돌하는 다른 플러그인을 초기화하려고 하면 오류가 발생합니다. 따라서 플러그인의 요구 사항을 특정 버전에 고정하지 않고 가능한 한 약하게 제한해야 합니다.
이 호스트가 semver 사양을 준수한다고 가정하면 이 패키지의 주요 버전을 변경하는 것만으로도 플러그인이 손상됩니다. 따라서 패키지에서 1.x 버전을 모두 사용한 경우 "^1.0" 또는 "1.x"를 사용하여 이를 나타냅니다. 기능 소개 1.5.2를 사용하는 경우 ">= 1.5.2 < 2"를 사용하세요.
bundledDependency
출시 시 포함될 패키지 이름 세트입니다.
'bundleDependency'(d가 누락됨)로 철자를 쓸 수도 있습니다.
선택적 종속성
종속성을 사용할 수 있지만 설치에 실패하더라도 npm이 계속 초기화되도록 하려면 이를 optionDependency 해시에 넣을 수 있습니다. 이는 종속성 해시와 마찬가지로 패키지 이름을 버전 또는 URL로 매핑한 것입니다. 그냥 잘못 실행됩니다.
종속성 부족을 처리하는 것도 프로그램의 책임입니다. 예를 들면 다음과 같습니다.
시도해보세요 {
var foo = require('foo')
var fooVersion = require('foo/package.json').version
} 잡기 (어) {
foo = null
}
if ( notGoodFooVersion(fooVersion) ) {
foo = null
}
// .. 그런 다음 나중에 프로그램에서 ..
if (foo) {
foo.doFooThings()
}
optionDependency는 종속성에서 동일한 이름을 가진 항목을 재정의하므로 일반적으로 한 곳에 두는 것보다 낫습니다.
엔진
작업 노드의 버전을 지정할 수 있습니다:
{ "엔진" : { "노드" : ">=0.10.3 <0.12" } }
그리고 종속성과 마찬가지로 버전을 지정하지 않거나 "*"를 버전으로 지정하면 모든 버전의 노드가 작동합니다.
"engines" 필드를 지정하면 npm은 해당 필드에 노드가 있어야 합니다. "engines"가 생략되면 npm은 노드에서 작동한다고 가정합니다.
또한 "엔진" 필드를 사용하여 다음과 같이 프로그램을 더 효과적으로 초기화할 수 있는 npm 버전을 지정할 수 있습니다.
{ "엔진" : { "npm" : "~1.0.20" } }
사용자가 엔진 엄격 플래그를 설정하지 않는 한 이 필드는 권장 값일 뿐이라는 점을 기억하세요.
엔진엄격
지정한 버전 이외의 node 또는 npm에서 모듈이 실행되지 않는다고 확신하는 경우 package.json 파일에서 "engineStrict": true를 설정할 수 있습니다. 이는 사용자의 엔진 엄격한 설정을 무시합니다.
아주 확실하지 않다면 이렇게 하지 마세요. 엔진 해시가 지나치게 제한적이면 쉽게 문제가 발생할 수 있습니다. 이 선택을 신중하게 고려하십시오. 사람들이 이를 남용할 경우 향후 npm 버전에서 제거될 예정입니다.
os
모듈을 실행할 운영 체제를 지정할 수 있습니다.
"os": [ "다윈", "리눅스" ]
화이트리스트 대신 블랙리스트를 사용할 수도 있습니다. 이름 앞에 "!"를 추가하세요.
"os": [ "!win32" ]
운영 체제는 process.platform을 사용하여 감지합니다.
별다른 이유는 없지만 블랙리스트와 화이트리스트를 모두 지원합니다.
CPU
코드가 특정 CPU 아키텍처에서만 실행될 수 있는 경우 다음 중 하나를 지정할 수 있습니다.
"cpu": [ "x64", "ia32" ]
os 옵션과 마찬가지로 아키텍처를 해킹할 수도 있습니다.
"cpu": [ "!arm", "!mips" ]
CPU 아키텍처는 process.arch를 사용하여 감지됩니다.
글로벌 선호
패키지가 주로 전역적으로 설치해야 하는 명령줄 프로그램인 경우 이를 true로 설정하여 로컬로만 설치하는 사람들에게 경고를 제공합니다.
실제로 사용자가 로컬로 설치하는 것을 막지는 못하지만 예상대로 작동하지 않을 경우 오해를 방지하는 데 도움이 됩니다.
비공개
"private": true로 설정하면 npm은 이를 게시하지 않습니다.
개인 라이브러리가 실수로 공개되는 것을 방지하기 위한 방법입니다. 지정된 패키지가 특정 레지스트리(예: 내부 레지스트리)에만 게시되도록 하려면 레지스트리의 게시 시간 구성 매개변수를 게시 구성 해시 설명으로 재정의하세요.
구성 게시
게시 시 사용되는 구성 컬렉션입니다. 이는 태그나 레지스트리를 설정하려는 경우 유용하므로 지정된 패키지에 "최신" 태그가 지정되지 않았는지 또는 기본적으로 전역 공용 레지스트리에 게시되었는지 확인할 수 있습니다.
모든 구성은 재정의될 수 있지만 게시 목적으로는 "태그"와 "레지스트리"만 관련될 수 있습니다.
재정의할 수 있는 항목 목록은 npm-config(7)를 참조하세요.