package.json 파일에 대한 심층 분석

저자：Eve Cole 업데이트 시간：2022-09-22 09:05:30

로컬에 설치된 npm 패키지를 관리하는 가장 좋은 방법은 package.json 파일을 만드는 것입니다. 이 기사는 package.json 파일을 안내할 것입니다. 도움이 되기를 바랍니다.

package.json 이해

각 프로젝트(npm 또는 다른 nodejs 프로젝트에서 다운로드한 패키지)의 루트 디렉터리 아래에는 일반적으로 프로젝트에 필요한 다양한 모듈과 프로젝트 구성 정보( 이름, 버전, 라이센스, 프로젝트 시작 방법, 스크립트 실행 방법 등과 같은 메타데이터). npm install 명령은 이 구성 파일을 기반으로 필요한 모듈을 자동으로 다운로드합니다.

package.json 파일은 JSON 개체이며, 개체의 각 멤버는 현재 프로젝트의 설정입니다. 예를 들어 name 은 프로젝트 이름이고, version 버전입니다("major version.minor version.minor version" 형식을 따릅니다). 또한 개발, 테스트 및 온라인 버전을 포함하여 프로젝트 수명 주기에서 다양한 역할을 수행합니다.

package.json은

프로젝트가 의존하는 패키지를 설명하는 설명 파일로 작동합니다.
빌드가 다른 개발자와 더 잘 통신할 수 있도록
"의미적 버전 관리 규칙"(나중에 설명)을 사용하여 프로젝트의 종속 패키지 버전을 나타낼 수 있습니다.
쉽게 재사용할 수 있도록 공유

package.json 생성 방법

1. 명령줄 도구 클라이언트 CLI

npm init를

사용하면

명령을 시작한 디렉터리에 package.json 이 생성되는 명령줄 설문지가 시작됩니다.

숙달 과정에 대한 프런트 엔드(vue) 항목: 학습 입력

2. 기본값 생성 기본값

package.json 을 얻으려면 --yes 또는 -y 플래그와 함께 npm init 실행하십시오.

npm init -y

이 방법에서는 package.json 사용합니다. 현재 디렉터리에서 추출된 정보는 질문에 답변하는 단계를 건너뛰고 package.json 을 생성합니다.

프로젝트 루트 디렉터리에 직접 새 package.json 파일을 수동으로 생성한 후 관련 내용을 입력합니다. 자세한 내용은 아래 package.json의 참고 사항을 참조하세요.

package.json 파일의 공통 필드에 대한 자세한 설명

1. 이름은

필수 필드로, 현재 모듈패키지의 이름입니다. 길이는 214자 이하여야 합니다(점). ) 또는 "_"(밑줄)이며 대문자를 포함할 수 없습니다.

이 이름은 require()에 매개변수로 전달될 수 있으므로 짧지만 의미가 있어야 합니다.

2. 버전은

필수 항목으로, 현재 패키지의 버전 번호이며, 처음 생성 시 기본값은 1.0.0 입니다.

버전은 npm이 의존하는 node-semver 모듈로 확인할 수 있어야 합니다. 현재 프로젝트의 버전 반복 진행 상황을 정의합니다. ("메이저 버전. 마이너 버전. 마이너 버전" 형식을 따르세요.)

어쩌면 많은 친구들이 이제 버전 번호에 관심을 두지 않거나 신경 쓰지 않고 제품의 버전 번호나 git을 사용하는 것을 선호할 수도 있습니다. 해시코드 방식.

3. 설명

선택 필드는 문자열이어야 합니다. 현재 패키지의 설명 정보는 문자열입니다. npm 검색을 사용할 때 사람들이 패키지를 찾는 데 도움이 됩니다.

package.json에 description 정보가 없으면 npm은 프로젝트의 README.md 첫 번째 줄을 설명 정보로 사용합니다. 이 설명 정보는 다른 사람들이 귀하의 프로젝트를 검색하는 데 도움이 되므로 description 정보를 잘 작성하는 것이 좋습니다.

4. 주요

선택 필드는 프로젝트 로딩을 위한 항목 파일을 지정합니다.

이 필드의 기본값은 모듈 루트 디렉터리 아래의 index.js 입니다.

5. 스크립트

선택 필드는 scripts 명령으로 구성된 해시 개체입니다. 패키지의 다양한 수명 주기에서 실행됩니다. 키는 수명주기 이벤트이고 값은 실행할 명령입니다. 스크립트 명령을 실행하기 위한 npm 명령줄 약어를 지정합니다. 예를 들어 start는 npm run start를 실행할 때 실행할 명령을 지정합니다. 스크립트를 실행하려는 명령을 사용자 정의할 수 있습니다.

참고 : http://www.ruanyifeng.com/blog/2016/10/npm_scripts.html

스크립트 구성 실행 스크립트

1) echo xxx 명령을 실행하여
1. node_modules/.bin 아래의 파일을 실행하는

이유는 무엇입니까?

npm run을 실행하면 새 Shell이 자동으로 생성되고 지정된 스크립트 명령이 이 Shell에서 실행됩니다. 따라서 명령을 Shell(일반적으로 Bash)에서 실행할 수 있는 한 npm 스크립트로 작성할 수 있습니다. 또한 현재 디렉터리의 node_modules/.bin을 현재 시스템의 경로에 복사합니다(임시 복사본일 뿐입니다. 실행이 완료된 후 PATH 변수는 원래 상태로 복원됩니다). 따라서 node_modules의 모든 스크립트는 /.bin 현재 디렉터리의 하위 디렉터리, 모두 경로 추가 없이 스크립트 이름을 사용하여 직접 호출할 수 있습니다.

예를 들어

node.js 서비스를 실행하기 위해 node를 사용하는 경우 node + 文件node server.js 사용할 수 있습니다. 또한 webpack을 사용하여 webpack-dev-server 프런트엔드 파일을 패키징할 수도 있습니다. webpack-dev-server를 설치해야 합니다.

"스크립트": {   
    "build": "webpack --mode=개발",
    "dev": "webpack-dev-server --mode=development --contentBase=./dist",
    "서버":"노드 app.js"
  }

명령줄 도구에 npm run server 입력하면 실행을 돕기 위해 node app.js가 호출됩니다.

약식:

npm start는 npm run start입니다.
npm stop은 npm run stop의 약어 npm test는 npm run test의 약어 npm restart는 npm run stop && npm run restart && npm run start의 약어

일반적으로 사용되는 스크립트 ----- 온라인 컬렉션 전송

// 디렉터리 삭제 "clean": "rimraf dist/*",

// 로컬에서 HTTP 서비스 "serve"를 구축합니다: "http-server -p 9090 dist/",

//브라우저 열기 "open:dev": "opener http://localhost:9090",

//실시간으로 "livereload" 새로 고침: "live-reload --port 9091 dist/",

// HTML 파일 빌드 "build:html": "jade index.jade > dist/index.html",

// CSS 파일이 변경되는 한 빌드 "watch:css": "watch 'npm run build:css' 자산/스타일/"을 다시 실행합니다.

// HTML 파일이 변경되는 한 빌드를 다시 실행합니다. "watch:html": "watch 'npm run build:html' 자산/html",

//Amazon S3에 배포
"deploy:prod": "s3-cli sync ./dist/ s3://example-com/prod-site/",

//파비콘 구축
"build:favicon": "노드 스크립트/favicon.js",

"start": "cross-env NODE_ENV=production node server/index.js",

6. 종속성 및 devDependency는

선택 사항 필드입니다. dependencies 필드는 프로젝트가 의존하는 모듈을 지정하고 devDependencies 프로젝트 개발에 필요한 모듈을 지정합니다.

값은 객체를 가리킵니다. 이 객체의 각 멤버는 모듈 이름과 해당 버전 요구 사항으로 구성되어 종속 모듈과 해당 버전 범위를 나타냅니다.

기본적으로 생성되는 package.json은 없으며 npm install 모듈을 설치할 때 생성됩니다.

npm 설치 익스프레스
npm 설치 익스프레스 --저장
npm install express --save-dev

위 코드는 express 모듈을 별도로 설치한다는 의미이며,

뒤에 매개변수가 없으면 dependencies 속성에 설치한다는 의미입니다.
devDependencies --save-dev
dependencies 속성 --save 모듈을 쓰는 것을 의미합니다.

7. BundledDependency

옵션 필드, 패키지를 게시할 때 동시에 패키지된 기타 종속성.

프로젝트 또는 모듈이 동시에 다른 모듈에 종속되지만 종속되는 버전이 다른 경우,

peerDependities

옵션 필드, 호환성 종속성.

예를 들어 프로젝트는 모듈 A와 모듈 B의 버전 1.0에 종속되고, 모듈 A 자체는 모듈 B의 버전 2.0에 종속됩니다.

{
  "name": "약속대로 차이",
  "peerDependency": {
    "차이": "1.x"
  }
}

위 코드에서는 chai-as-promised 모듈을 설치할 때 기본 프로그램인 chai 함께 설치해야 하며, chai 버전은 1.x 여야 한다고 명시하고 있습니다. 프로젝트에서 지정한 종속성이 chai 버전 2.0인 경우 오류가 보고됩니다.

9. Bin

선택적 필드 bin 필드는 각 내부 명령에 해당하는 실행 파일의 위치를 지정하는 데 사용됩니다.

프로젝트 루트 디렉터리에 /bin/www 파일을 생성합니다.

/usr/bin/env 노드

package.json에

"bin"을

구성합니다

  "lee-cli":"./bin/www"
}

npm link 패키지의 bin 속성 값 경로를 전역 링크에 추가하고 단축 연결을 생성한 후

명령줄에서 lee-cli 실행하여 bin/www 파일을 실행합니다. 프로세스는 다음과 같습니다.

위의 예에서 www는 node_modules/.bin/www 심볼릭 링크를 생성합니다. node_modules/.bin/ 디렉터리는 런타임 시 시스템의 PATH 변수에 추가되므로 npm 실행 시 경로 없이 명령을 통해 직접 이러한 스크립트를 호출할 수 있습니다.

10. config

config 필드는 환경 변수에 값을 출력하는 데 사용됩니다

.
  "이름": "패키지",
  "구성": { "포트": "8080" },
  "스크립트": { "시작": "node server.js" }
}

이를 변경하려면

npm config set package:port 80을

사용할 수 있습니다.

11. 엔진

옵션 필드는 특정 버전의 Node 또는 브라우저와 같이 모듈이 실행되는 플랫폼 버전을 지정할 수도 있습니다. 해당 npm 버전.

"엔진": { 
"노드": 
">=0.10.3 <0.12"
}

12.

package.json에 설명된 코드에 적용할 수 있는 라이선스의 정의를 나타내는 라이선스 옵션 필드입니다. 프로토콜마다 제한 사항이 다릅니다. 사용자에게 모듈을 사용하는 데 필요한 권한과 모듈 사용에 대한 제한 사항을 알려주세요.

라이센스를 선택하려면 choosealicense.com/을 참조하십시오.

예: MIT: 최대 권한, 다운로드 후 다른 사람이 코드를 변경할 수 있음, 기본 설치 값.

13. 작성자

선택 항목, 프로젝트 개발자.

14. 비공개

선택 필드, 부울 값, 비공개 여부. true로 설정하면 npm이 게시를 거부합니다.

이는 비공개 패키지가 외부인에게 공개되는 것을 방지하기 위한 방법입니다. 특정 레지스트리(예: 내부 레지스트리)에만 게시되도록 패키지를 래핑하려는 경우 아래의 게시 구성 사전 설명을 사용하여 게시 시 레지스트리 구성 매개 변수를 재정의할 수 있습니다.

15. 키워드

선택 필드인 프로젝트 키워드는 문자열 배열입니다. npm 검색을 사용할 때 사람들이 패키지를 찾는 데 도움이 됩니다.

16. os

선택적 필드는 모듈이 실행될 수 있는 운영 체제를 지정합니다.

17. style

style은 브라우저에서 사용될 때 스타일 파일의 위치를 지정합니다.

18.

저장소 패키지 코드가 저장되는 장소 유형은 git 또는 svn이 될 수 있으며 git은 Github에 있을 수 있습니다.

19. 홈페이지

선택 필드에는 http://와 같은 프로토콜 접두어가 있는 URL이 없습니다.

버전 문제:

버전: "1.0.0"

1.0.0:

첫 번째 숫자 변경은 이전 코드와의 비호환성, 대규모 업데이트, 새 버전 출시를 의미합니다.
두 번째 숫자는 일부 기능이 추가되었으며
세 번째 버전
과의 호환성을 의미합니다.
숫자는
일부 기능이 추가되었음을 의미하며 이전 버전과의 호환성
비트는 작은 패치, 버그 수정을 의미합니다.

프로젝트를 게시할 때 npm + git을 사용하여

npm version patch (패치 패치)를 사용합니다. ; git tag 사용하여 실행하면 자동으로 git에 저장됩니다
. 버전 번호의 두 번째 숫자를 변경하려면 npm version minor 사용하세요.
버전 번호의 첫 번째 숫자를 변경하려면 npm version major 사용하세요. ;

npm 버전 [<newversion> | premajor 패치 |

major: 주요 버전 번호 min: 부 버전 번호 patch: 패치 번호 premajor: 예비 주요 버전 prepatch: 예비 부 버전 prerelease: 시험판 버전

ps: 참고, 오류가 보고되면: Git 작업 디렉터리가 깨끗하지 않다는 의미입니다. 지금 정리하려면 git status 필요합니다.

자식 추가 .
git commit -m "package.json 자세한 설명"

npm versin monir -m"增加版本号"

git push -u Origin master

규칙을 공식화하는 방법은 무엇입니까?

사용자로서 우리는 package.json 파일에 이 패키지에 대해 허용할 수 있는 업데이트 수를 표시할 수 있습니다(현재 버전 1.2.4를 사용한다고 가정).

패치 버전에 대한 업데이트만 허용하려는 경우(즉, 마지막 숫자 변경), 다음과 같이 쓸 수 있습니다:
```
1.2
 1.2.x
 ~1.2.4
```
마이너 버전 업데이트(두 번째 위치의 변경)를 수락하는 경우
```
다음
```
과 같이 작성할 수 있습니다.
```
1.x
^1.2.4
```
주요 버전 업데이트를 허용할 수 있는 경우(부 버전 및 패치 버전 변경을 자연스럽게 허용) 다음과 같이 작성할 수 있습니다.
```
*x
```
요약: 세 가지 유형의 버전 변경이 있으며, 종속 패키지의 업데이트 유형이 허용됩니다. ? 버전 번호를 앞자리까지 정확하게 기재하세요.

버전 주기 및 단계:

α-Alpha 첫 번째 단계는 일반적으로 내부 테스트용으로만 제공됩니다.
β-Beta 두 번째 단계는 소프트웨어의 불완전성을 대부분 제거했지만 여전히 결함과 허점이 있을 수 있으며 일반적으로 특정 테스트에 제공됩니다.

γ-RC

는

현재
세 번째 단계이며, 시장에 출시되기 전에 일부 부분에서만 추가 최적화가 필요합니다

2.1.0-beta.1 은 일반적으로 이런 사용자가 사용합니다. 이런 종류는 내부 및 테스터가 사용할 수 없습니다.

종속성 패키지 버전 문제

의	예
~	1.2.3
주	버전 + 부 버전 + 패치 버전 1.2.3 <= 버전 < 1.3.0; ~1.2 주 버전 + 부 버전 <= 1.3
;	주 버전; 1.0.0 <= 버전 < 2.0.0

과 일치

기호	인스턴스	버전 범위	설명
	1.0.0	1.0.0	은 버전 1.0.0으로 잠겨 있으며 이 버전이어야 합니다.
^는 최신 대형 버전 종속성 패키지	^1.2.3, ^0.2.3	>=1.2.3 <2.0.0, >=0.2.3 <0.3.0	합니다. 1.xx의 최신 버전을 설치한다는 의미입니다. 1.2 .3, 1.3.0 포함). 그러나 2.xx는 설치되지 않습니다. 즉, 설치 중에 주요 버전 번호가 변경되지 않습니다. 주 버전 번호가 0인 경우 캐럿은 물결표와 동일하게 동작합니다. 이는 아직 개발 단계이기 때문에 사소한 버전 번호 변경이라도 프로그램 비호환성을 유발할 수 있습니다. (메인 버전)
~ 최신 마이너 버전 종속 패키지와 일치합니다	~1.2.3	>=1.2.3 <1.3.0은	최신 버전 1.2.x(1.2.3 이상)를 설치하지만 1.3.x는 설치하지 않음을 의미합니다. 즉, 주 버전 번호와 부 버전 번호는 설치 중에 변경되지 않습니다.
>=	>=2.1.0	>=2.1.0	2.1.0 이상
<=	<=2.0.0	<=2.0.0	2.0.0 이하
마지막			최신 버전을 설치하세요
*		>=0.0.0	모든 버전
-	1.2.3 - 2.3.4	>=1.2.3 <=2.3.4

Dependencies 설치 와 dependencies 설치를 구별합니까 ?

devDependencies 개발에 필요한 모듈이므로 개발 효율성을 높이기 위해 개발 프로세스 중에 필요에 따라 모듈을 설치할 수 있습니다(예: 잘 알려진 타사 라이브러리, webpack , rollUp , less , babel 등). 프로덕션 환경에 설치할 필요가 없습니다.

devDependencies 에 설치하는 것이 권장되는 라이브러리:

단위 테스트 지원(mocha, chai),
구문 호환성(babel),
구문 변환(jsx에서 js로, coffeescript에서 js로, typescript에서 js로)
프로그램 구성 및 최적화( webpack, gulp, grunt, uglifyJS),
CSS 프로세서(postCSS, SCSS, Stylus)
,

종속성 패키지(지정, 업데이트, 로컬, 사용, 제거)

1. 로컬 종속성 패키지 설치

npm install

jquery 현재 디렉터리 node_modules 디렉터리에 생성한 다음 이 디렉터리에 지정한 패키지를 다운로드합니다.

2. 설치 버전을 지정하려면 패키지 이름 뒤에 @版本号하면 됩니다.

패키지 이름이 package @ 로 시작하면 해당 패키지는 범위가 지정된 패키지 입니다.

npm 설치 [email protected]
npm install jquery@">=1.1.0 <2.2.0"
npm install jquery@latest가

업데이트되면 종속성의 버전 번호도 변경됩니다.

3. 종속 패키지

npm update jquery를

업데이트합니다

. 4. 패키지

let jquery = require('jquery')

<script src="/node_modules/jquery/dist/jquery.js">//다음 사항에 주의해야 합니다. 경로</script>

6 , 종속 패키지 제거

npm uninstall jquery

의미 체계 버전 관리(의미 체계 버전 관리 규칙)

https://docs.npmjs.com/about-semantic-versioning
https://github.com/npm/node-semver

패키지 .json

위의 내용에 따른 참고 사항 npm init 사용하면 여러 항목을 입력하라는 메시지 name 표시됩니다. package.json 중 일부는 선택 사항이고 일부는 필수 필드입니다. version 없으면 install 실행할 수 없습니다.

이름: 모두 소문자, 공백 없음, 순서대로 하이픈과 밑줄 사용
버전: 버전 번호, 위에서 언급한 의미적 버전 관리 규칙을 따르세요. xxx

기타 참고 사항:

중국어 주석을 추가하면 컴파일 오류가 발생합니다.