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 검색
homepage
프로젝트 홈 페이지 url
bugs
프로젝트 제출 문제 의 url 과(또는)메 일 주소 입 니 다.이 문제 에 부 딪 힌 반 항 윤 사 반지 는
{ "url" : "http://github.com/owner/project/issues" , "email" : "[email protected]" }
너 는 하 나 를 지정 하거나 두 개 를 지정 할 수 있다.url 만 제공 하고 싶다 면 대상 을 사용 하지 않 고 문자열 을 사용 하면 됩 니 다.url 을 제공 하면 npm bugs 명령 에 의 해 사 용 됩 니 다.
license
사용 의 권리 와 제한 을 알 릴 수 있 는 허가증 을 지정 해 야 한다.가장 쉬 운 방법 은 BSD 나 MIT 처럼 통용 되 는 허가증 을 사용한다 면 허가증 의 이름 만 지정 해 야 한 다 는 것 이다.이렇게:
{ "license" : "BSD" }
author
프로젝트 작성 자.name,email,url 필드 정 보 를 지정 할 수 있 습 니 다.문자열 로 표시 할 수도 있 습 니 다.
{“ author ”: { "name" : "Barney Rubble" , "email" : "[email protected]" , "url" : "http://barnyrubble.tumblr.com/" } }
contributors
프로젝트 관련 공헌 자.배열 입 니 다.대응 하 는 공헌 자 를 나열 합 니 다.단독 문자열 일 수도 있 고 name,email,url 등 속성 을 각각 지정 할 수도 있 습 니 다.
{"contributors ":[ { "name" : "Barney Rubble" , "email" : "[email protected]" , "url" : "http://barnyrubble.tumblr.com/" } ]}
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 의 빈 필드 에 파일 위치 로 명령 하 는 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:port 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" : "http://asdf.com/asdf.tar.gz"   , "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"   } }
이것 은 당신 의 패 키 지 를 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" ]
화이트 리스트 대신 블랙리스트 로 이름 앞 에'!'를 붙 일 수도 있다.하면 됩 니 다.
"os" : [ "!win32" ]
운영 체 제 는 process.platform 으로 탐지 합 니 다.좋 은 이 유 는 없 지만 블랙리스트 와 화이트 리스트 를 동시에 지원 한다.
cpu
코드 가 특정 cpu 구조 에서 만 실 행 될 수 있다 면 하 나 를 지정 할 수 있 습 니 다.
"cpu" : [ "x64", "ia32" ]
os 옵션 처럼 당신 도 구 조 를 검은색 으로 만 들 수 있 습 니 다.
"cpu" : [ "!arm", "!mips" ]
cpu 구조 용 process.arch 탐지.
preferGlobal
패키지 가 전역 적 으로 설치 되 어야 하 는 명령 행 프로그램 이 라면 true 로 설정 하여 국부 적 으로 만 설치 되 어 있 는 사람 에 게 warning 을 제공 합 니 다.그것 은 사용자 가 국부 적 으로 설치 하 는 것 을 진정 으로 방지 하 지 는 않 지만,만약 그것 이 예상 한 대로 작업 하지 않 았 다 면 오해 가 생기 는 것 을 방지 하 는 데 도움 이 될 것 이다.
{" preferGlobal ":true}
private
"private"를 설정 하면 npm 는 발표 하지 않 습 니 다.
이것 은 의외 의 사유 라 이브 러 리 발 표를 방지 하 는 방식 이다.주어진 가방 이 특정 registry(예 를 들 어 내부 registry)에 만 발 표 된 것 이 라 고 확인 하려 면 PublishConfighash 의 설명 으로 registry 의 Publish-time 설정 파 라미 터 를 다시 씁 니 다.
publishConfig
이것 은 Publish-time 에서 사용 하 는 설정 집합 입 니 다.tag 나 registry 를 설정 하고 싶 을 때 유용 합 니 다.따라서 주어진 가방 에'lastest'태그 가 붙 지 않 았 거나 전체 공개 registry 에 기본적으로 발표 되 었 는 지 확인 할 수 있 습 니 다.모든 설정 을 다시 쓸 수 있 지만,당연히'tag'와'registry'만 발표 의도 와 관련 이 있 을 수 있 습 니 다.
package.json 의 각 속성 에 대한 상세 한 설명 을 담 은 이 글 은 여기까지 소개 되 었 습 니 다.더 많은 관련 package.json 속성 내용 은 우리 의 이전 글 을 검색 하거나 아래 의 관련 글 을 계속 조회 하 시기 바 랍 니 다.앞으로 많은 응원 바 랍 니 다!