Node.js 또는 클라이언트 측 JavaScript 프로젝트에서 작업 한 경우 package.json이라는 파일을 보았고 그 내용을 둘러 보았을 가능성이 큽니다. 거기에 당신이 아마 잘 알고 있는 많은 것들이 있지만, 당신은 그것이 무엇을 의미하는지 또는 처음에 어떻게 거기에 들어 갔는지 완전히 확신하지 못하는 것들을 겪을 수도 있습니다.

이 기사에서는 이 파일에 포함 된 각 항목의 의미, 여기에 넣을 수 있는 종류 및 프로젝트를 개발하는 동안 생산성을 높이는 데 도움이 되는 방법에 대해 자세히 설명합니다.

먼저 해야 할 일 :

package.json 파일은 무엇입니까? 

역사적으로 Node는 npm이라는 도구를 사용하여 패키지 및 종속성을 관리했습니다. 일반적으로 노드를 따라 설치되는 이 도구에는 두 가지 주요 작업이 있습니다.

• npm의 공용 레지스트리에 프로젝트 공개 (다른 사용자가 프로젝트의 종속성으로 다운로드 할 수 있음)
• 자신의 프로젝트의 종속성을 관리하십시오.

이를 수행 할 수 있도록 npm 클라이언트는 package.json이라는 파일을 작성하고 사용합니다. 이 파일에는 다음과 같은 프로젝트에 대한 정보가 포함됩니다.

• Name. (이름.)
• Version.(버전)
• Dependencies.(의존성)
• Repository. (저장소)
• Author(s). (저자)
• License. (라이센스)
• And more.

또한 이 파일을 사용하여 레코드를 보관할 뿐만 아니라 복사본을 얻는 모든 사람에게 프로젝트의 무결성을 보장 할 수 있습니다. 

즉, 어느 시점에서든 모든 사용자가 동일한 호환 가능한 동일한 종속성 집합에 액세스 할 수 있습니다. 어떤 식으로든 package.json 파일을 프로젝트의 선언문으로 생각할 수 있습니다. 

여기서 명심해야 할 것은 package.json 파일에 나열된 종속성이 원본과 유사하고 호환되어야 하지만 이후 상당한 시간이 지나도 프로젝트가 문제 없이 실행될 수 있다는 보장은 없습니다. 

원래 선언 _ (호환되는 것으로 간주되지만 일부 기능이 작동하지 않을 수 있는 다른 버전의 패키지에 변경 사항이 도입 된 경우 일 수 있음) 이를 위해 잠금 파일을 사용하는 것이 좋습니다.

다음 시나리오를 고려하여 예를 살펴 보겠습니다.

두 명의 개발자가 자신의 컴퓨터에 독립적인 사본을 사용하여 동일한 프로젝트를 진행하고 있습니다. 개발자 # 1은 새로운 기능을 완료하려면 프로젝트 내에서 새로운 라이브러리를 사용해야 한다고 결정합니다.

종속성 관리가 없으면 다음 두 가지 중 하나를 수행해야 합니다.

• 라이브러리를 프로젝트의 디렉토리에 수동으로 다운로드하고 프로젝트가 저장된 위치에 포함되어야 하는 사본을 보관하십시오. 따라서 새로운 개발자가 사본을 받을 때마다 전송해야 하는 데이터의 양이 증가 할 수 있습니다.
• 사본을 보관하지 않고 라이브러리 사본을 다운로드하되 프로젝트에 참여하는 모든 사람 (현재 및 미래)에게 사본을 받아야 하며 동일한 버전을 사용하고 있는지 확인하도록 합니다. (새로운 친구를 사귈 수 있는 좋은 방법이지만 시간 관리 측면에서는 그다지 좋지 않습니다).

npm과 같은 종속성 관리 도구를 사용하면 이러한 단계가 더 이상 필요하지 않습니다. 패키지 사본이 공개되지 않은 한 현재와 영원히 프로젝트 사본을 얻는 사람은 실제 사본을 전송할 필요 없이 각각의 종속성을 설치할 수 있습니다. 결과적으로 저장소에 저장되고 공유되는 실제 프로젝트는 훨씬 가볍고 중복 데이터는 전송되지 않습니다.

package.json 파일에 포함 된 많은 정보가 npm 레지스트리에 프로젝트를 게시하는 데 고유 한 것으로 보이지만 npm을 사용하여 아직 게시 되지 않는 다른 종류의 프로젝트를 관리 할 수 ​​있습니다. 웹 및 / 또는 모바일 앱, 게임 및 기타와 같은

의존성 관리에 대한 마지막 메모로, 얼마 전 Facebook의 아주 좋은 친구들 (참고 : 그들은 우리가 친구라는 것을 실제로 알지 못합니다 ... 그러나 :()는 yarn이라는 비슷한 도구를 시작했습니다.이 도구는 모든 의도와 이 기사의 목적은 위에서 언급 한 것과 동일한 두 가지 작업을 수행 할 수 있으며 명시 적으로 언급되지 않는 한 package.json 파일의 사용법은 동일합니다.

package.json 파일을 만드는 방법 

하나의 규칙, 그들 모두를 울리는 것 (?) 

package.json 파일을 작성하기 전에 알아야 할 규칙이 있습니다. 파일은 유효한 JSON 형식이어야 하며 JSON 스타일 스펙을 준수해야 합니다.

이를 염두에 두고 파일을 작성하는 두 가지 방법이 있습니다. 수동 또는 npm / yarn cli 사용 :

package.json 수동 생성 

어떤 이유로 npm / yarn cli 사용 옵션을 사용할 수 없고 실제로 파일을 수동으로 작성해야 하는 경우 다음을 포함하는 프로젝트의 루트에 새 파일 (패키지 .json)을 추가해야 합니다.

• name
• version

다음 섹션에 나열된 다른 모든 필드는 선택 사항이지만 권장됩니다.

npm / yarn cli를 사용하여 package.json 작성 

권장되는 방법입니다. package.json 파일 만들기는 프로젝트의 루트 디렉토리에서 사용 중인 패키지 관리자에 따라 다음 명령을 실행하여 수행 할 수 있습니다.

npm init

또는

yarn init

npm 또는 yarn의 사용 여부에 따라 파일을 작성하기 전에 특정 정보를 제공해야 합니다.

npm을 사용하여 package.json 만들기

yarn을 사용하여 package.json 만들기

완료되면 새로운 package.json 파일이 프로젝트의 루트 디렉토리에 생성됩니다.

빠른 팁 : 기본값으로 package.json 파일을 빠르게 작성해야 하는 경우 다음을 실행할 수 있습니다.

npm init -y

또는

yarn init -y

package.json 파일의 섹션 

package.json 파일을 수동으로 또는 cli를 사용하여 생성 한 후에는 이 기사의 초기 이미지와 같이 키와 값이 다른 큰 객체를 찾을 수 있습니다. 또한 시간이 지남에 따라 새로운 종속성 / 구성이 포함되면 여기에 새로운 키와 값도 포함됩니다. 다음은 우리가 어떤 시점에서 보게 될 가장 일반적인 것들의 목록입니다 :

참고 :이 목록에는 npm에서 공식적으로 선언하고 지원하는 속성 만 포함됩니다. package.json 파일에서 읽을 키를 지원하는 여러 외부 라이브러리가 있습니다 (예 : Jest 및“jest”속성)

name 

이것은 파일에 포함되어야 하는 두 가지 필수 필드 중 하나입니다 (버전과 함께). 현재 프로젝트의 이름을 나타내는 문자열이며 프로젝트가 레지스트리에 게시 된 경우 고유 식별자로도 작동합니다.

Rules: 

• 이름은 소문자 여야 하며 마침표 나 밑줄로 시작할 수 없습니다.
• 이름의 최대 길이는 214 자이며 URL에 안전해야 합니다 (URL 안전 문자에 대한 자세한 내용은 2.3 절 참조).

명심해야 할 몇 가지 사항 :

• 프로젝트가 npm 레지스트리에 공개되는 경우 이름은 고유하고 사용 가능해야 합니다 (같은 이름을 사용하기 전에 공개 된 다른 프로젝트는 없음).
• 패키지가 React 라이브러리에 react- {something}을 사용하는 것과 같이 특정 기술에 속하는 경우 관련 이름을 사용하는 것이 좋은 방법으로 간주되지만 이름에 node 또는 j를 사용하지 않는 것이 좋습니다.

version 

이름과 함께 다른 필수 필드입니다. 프로젝트의 현재 버전을 나타내는 문자열입니다. Node.js 및 JavaScript 프로젝트는 일반적으로 시맨틱 버전 관리 (또는 셈버)에 정의 된 규칙을 준수하며 이는 버전의 다음 구조를 정의합니다.

MAJOR.MINOR.PATCH

semver에 대한 추가 정보.

서술 

프로젝트에 대한 간단한 설명이 포함 된 문자열입니다. 패키지가 게시 된 경우 이 텍스트는 검색 결과와도 관련이 있습니다.

키워드 

설명과 동일하지만 텍스트 대신 패키지를 검색하는 데 사용할 수 있는 관련 용어를 포함하는 문자열 배열입니다.

홈페이지 

프로젝트 웹 사이트에 유효한 URL이 포함 된 문자열입니다.

버그 

사용자가 프로젝트에서 발견 된 문제를 보고 할 수 있는 유효한 URL을 가진 문자열입니다. 일반적으로 이슈 리포지토리 URL이 사용됩니다.

license 

 프로젝트가 릴리스되는 라이센스 유형을 지정하는 문자열입니다. 개인, 상업, 공개 또는 개인 일 수 있습니다.

사용 가능한 라이센스에 대한 추가 정보

저자 

문자열 또는 프로젝트 작성자에 대한 정보가 있는 오브젝트 일 수 있습니다.

객체인 경우 다음 형식이어야 합니다.

• name.
• email.
• URL.

그리고 그것이 문자열이라면 :

"Name <email> (URL)"

contributors 

author와 비슷하게 프로젝트의 기고자 정보가 있는 객체 배열 (또는 문자열 배열)입니다.

파일들 

레지스트리에 게시 된 경우 프로젝트에 포함될 파일의 ​​문자열 또는 패턴 (예 : * .js) 배열입니다. 이 섹션을 정의하지 않으면 모든 파일 (.gitignore와 같은 파일에서 명시 적으로 제외되지 않은)이 포함됩니다.

이것에 대해 명심해야 할 것들 : 

• 기본적으로 .gitignore 안에 나열된 모든 파일은 게시에서 제외됩니다.
• 파일 섹션을 추가하는 대신 .npmignore 파일을 게시에서 제외 할 파일 목록과 함께 프로젝트의 루트에 포함 시킬 수 있습니다 (.gitignore의 작업과 유사).
• 명시 적 제외와 상관없이 일부 파일은 항상 포함됩니다. 이러한 파일 중에는 package.json, README, CHANGES / CHANGELOG / HISTORY, LICENSE / LICENCE, NOTICE 및 앱의 진입 점으로 정의 된 파일 (다음 섹션에서 이에 대한 자세한 내용)이 있습니다.
• 명시 적 포함과 상관없이 일부 파일은 항상 무시됩니다. 이러한 파일 목록은 여기에서 찾을 수 있습니다.

main 

프로젝트의 진입 점을 정의하는 문자열입니다. 프로젝트가 패키지 / 라이브러리 인 경우 누군가가 필요할 때마다 가져올 파일입니다. 

프로젝트를 super-awesome-library라고 하고 사용자가 프로젝트를 설치 한 다음 앱 내부에 설치하는 경우 :

const superAwesomeLibrary = require("super-awesome-library");

superAwesomeLibrary 변수는 메인 파일이 내보내는 모든 내용을 가지므로 package.json 파일에 다음과 같은 선언이 있는 경우 :

{
  "main": "lib/foo.js"
}

superAwesomeLibrary 변수는 lib / foo.js로 내 보낸 내용을 포함합니다.

이 섹션을 생략하면 프로젝트의 루트 디렉토리에 있는 index.js 파일의 내용이 사용됩니다.

bin 

설치되고 PATH에서 명령으로 사용할 수 있는 스크립트를 정의하는 문자열 (하나만 있는 경우) 또는 객체 (여러 경우 인 경우) 패키지가 설치되면 / usr / local / bin에서 프로젝트 내의 해당 파일에 대한 심볼릭 링크가 만들어지고 명령 줄 프로그램으로 사용할 수 있습니다.

예를 들어, 프로젝트 내에 cli.js라는 파일이 있고 사용자가 터미널에서 직접 파일을 호출 할 수 있도록 하려고 합니다. 이를 달성하는 방법은 다음과 같이 package.json 안에 bin으로 단일 문자열을 포함 시키는 것입니다.

{
  "name": "super-awesome-library",
  "bin": "cli.js"
}

이제 cli.js의 내용은 터미널에 프로젝트 이름으로 넣은 모든 것을 실행하여 사용할 수 있습니다.

super-awesome-library

사용자가 친숙한 이름을 사용하는 동안 실제로는 "장면에서"이와 같은 일이 발생합니다.

node cli.js

그런 다음 해당 파일에 있는 모든 것이 실행됩니다.

그 대신 실행 가능한 스크립트로 바꾸려는 여러 파일이 있는 경우 객체 형식을 대신 사용할 수 있습니다. 그러면 키를 나중에 사용할 수 있는 명령으로 사용하여 모든 키-값 쌍에 대한 심볼릭 링크가 추가됩니다.

{
  "bin": {
    "script-1": "super-h4x0r-script1.js",
    "script-2": "on-your-left.js"
  }
}

해당 객체와 함께“script-1”과“script-2”가 모두 PATH에 포함되며, 각각 bin 객체 내부의 쌍인 각각의 .js 파일을 가리 킵니다.

이것은 nodemon 또는 react-native와 같은 많은 알려진 패키지에 포함 된 것이므로 파일 경로에 관계없이 node를 실행하지 않고도 터미널 명령으로 직접 사용할 수 있습니다. 

man 

이 프로젝트에 대해 man 명령이 실행될 때 사용 가능 / 표시 될 하나 이상의 파일을 정의하는 문자열 또는 문자열 배열.

디렉토리 

프로젝트 구조 및 특정 섹션에 대한 모든 폴더가 있는 위치를 정의하는 객체입니다. 가장 일반적인 것은 bin, doc, example, lib, man, test입니다.

{
  "bin": "./bin",
  "doc": "./doc",
  "lib": "./lib"
}

저장소 

이 프로젝트가 저장되고 기여를 위해 찾을 수 있는 위치를 정의하는 객체 객체의 형식은 다음과 같습니다.

{
  "type": string,
  "url": string
}

여기서 type은 리포지토리 유형 (예 : svn 또는 git)을 나타내고 URL은 찾을 수 있는 유효한 URL입니다.

예:

{
  "type": "git",
  "url": "https://github.com/my-user/super-awesome-project"
}

scripts 

프로젝트의 npm / yarn cli와 함께 사용할 수 있는 명령을 정의하는 객체입니다. 일부 스크립트는 사전 정의되어 예약되어 있으며 시작, 설치, 사전 설치, 사전 테스트, 테스트 및 사후 테스트와 같이 스크립트를 정의하지 않고 사용할 수 있습니다. (전체 목록은 여기에서 찾을 수 있습니다).

같은 방식으로 자체 스크립트를 정의하고 사용자 지정 이름과 지침을 사용할 수 있습니다. 매번 전체 명령 및 / 또는 매개 변수를 기억할 필요 없이 바로 가기 및 / 또는 결합 된 작업을 만드는 데 매우 유용합니다.

예를 들어, 새 버전을 만들기 전에 JS 파일을 최소화하기 위해 작업을 실행해야 하는 앱이 있다고 가정하고 tasks / minify.js에있는 스크립트를 사용하여 이를 사용하는 플래그 또는 매개 변수를 전달합니다. 내부적으로. 일반적으로 이 작업을 수행 할 때마다 node tasks / minify.js --someflag --maybeanother를 실행합니다 (플래그 이름도 기억해야 함). 그러나 대신 npm 스크립트에 추가하면 다음과 같은 작업을 수행 할 수 있습니다.

"scripts": {
  "minify": "node tasks/minify.js --someflag --maybeanother"
}

그런 다음 다음을 실행하십시오.

npm run minify

이것은 동일한 결과를 달성합니다. 이것에 대한 멋진 점은 매번 실행 해야 하는 정확한 명령을 기억할 필요가 있을 뿐만 아니라 npm 스크립트를 순차적으로 결합하고 실행할 수 있기 때문에 복잡한 작업을 만들고 일부를 사용하면 자동으로 트리거 할 수도 있습니다 사전 후크 (사전 테스트 또는 사전 게시)

예를 들어, 앱 테스트를 실행하기 직전에 동일한 축소 작업을 실행하고 코드를 실행하여 코드를 실행한다고 가정 해 보겠습니다. 이를 위해 다음과 같이 추가 할 수 있습니다 (앱 코드가 src 폴더에 있는 것처럼 보냄).

"scripts": {
  "pretest": "node tasks/minify.js --someflag --maybeanother && eslint src"
}

또는 테스트 스크립트의 일부로 직접 포함 시킬 수도 있습니다 (이 예제에서는 jest를 사용하지만 mocha / ava / tape / etc 또는 선택한 도구로 대체 할 수 있음).

"scripts": {
  "test": "node tasks/minify.js --someflag --maybeanother && eslint src && jest"
}

이것에 대한 마지막 참고로,이 스크립트는 npm에 의해 사전 정의 된 / 예약되지 않은 (이 섹션의 시작 부분에 나열되어 있지 않은 경우) npm run 'script'로 실행되어야 합니다. 그러나 원사를 사용하는 경우 미리 정의 된 스크립트인지 여부에 관계없이 실행 부분을 완전히 생략하고 원사 '스크립트'를 수행 할 수 있습니다.

config 

나중에 코드 내에서 액세스 할 수 있는 환경 변수로 사용하도록 값을 설정할 수 있는 객체입니다.

구성 값을 설정하기 위해 package.json 파일 내에서 이를 수행 할 수 있습니다.

{
  "name": "my-app",
  "config": {
    "port": 8000
  }
}

그런 다음 process.env.npm_package_config_ {value}를 사용하여 코드 내에서 값을 참조 할 수 있습니다.

const express = require('express');
const app = express();
const port = process.env.npm_package_config_port;

app.get('/', (req, res) => res.send('Hello!'));

app.listen(port, () => console.log(`App listening on port ${port}!`));

이 구성 값은 다음을 실행하여 언제든지 package.json 파일 외부에서 변경할 수 있습니다.

npm config set {name of the project}:{config key} {config value} 

이전 예제의 경우 다음과 같이 할 수 있습니다.

npm config set my-app:port 3000

dependencies

프로젝트 기록 중에 설치 및 저장된 각 종속성의 이름과 버전을 저장하는 객체입니다. 누군가 이 프로젝트의 새로운 사본을 받고 npm 설치를 실행할 때마다 이러한 모든 종속성이 설치됩니다 (최신 호환 버전). 다음 두 범주 뿐만 아니라 이러한 종속성은 다음 형식으로 정의됩니다.

"name-of-the-dependency": "(^|~|version)|url"

몇 가지 예 :

"dependencies": {
  "backbone": "1.0.0",
  "lodash": "^4.6.1",
  "mocha": "~3.5.3",
  "super-mega-library": "https://example.com/super-mega-library-4.0.0.tar.gz"
}

이러한 종속성에는 버전이 설치 및 저장되거나 현재 버전의 패키지를 얻을 수있는 유효한 URL이 있을 수 있습니다 (이 URL은 동일한 컴퓨터 내의 로컬 경로 일 수도 있음).

버전 시작 부분의 ^ 및 ~ 기호는 무엇입니까? 

설치된 모든 종속성에는 허용되는 호환 가능한 버전의 범위를 정의하는 문자가 있을 수 있습니다. 이 두 가지가 가장 일반적이지만 여기에서 전체 목록을 찾을 수 있습니다.

즉, 다음 문자는 다음에 npm을 설치할 때이 종속성을 처리하는 방법에 대한 지침을 추가합니다.

• 버전에 캐럿 (^)이 있는 경우 : 사소한 변경 (버전의 두 번째 숫자) 인 경우 다른 버전을 설치할 수 있습니다. 다른 부 버전이 없으면 동일한 버전이 설치됩니다.
• 버전에 물결표 (~)가있는 경우 : 패치 변경 (버전의 마지막 번호) 인 한 다른 버전을 설치할 수 있습니다. 다른 패치를 찾지 못하면 동일한 버전이 설치됩니다.
• 버전에 숫자 만 있고 문자가 없는 경우 : 정의 된 것과 정확히 동일한 버전을 설치해야 합니다.

예를 들어 위에서 지정한 종속성으로 npm install을 실행하면 새 버전을 사용할 수 있습니다.

• 백본과 슈퍼 메가 라이브러리는 동일한 버전 (각각 1.0.0과 4.0.0)을 사용합니다.
• lodash는 동일한 버전 또는 4.6.1과 4.9.9 사이의 버전을 설치할 수 있지만 5.x.x 이상과 같은 것은 없습니다.
• mocha는 동일한 버전 또는 3.5.3과 3.5.9 사이의 버전을 설치할 수 있지만 그보다 높은 버전은 없습니다.

devDependencies 

위에 나열된 종속성과 동일한 형식이지만 이 섹션에는 프로젝트에서 사용하지만 프로덕션 환경에 필요하지 않은 모든 종속성 (테스트 도구, 로컬 개발 서버, 최적화 도구 등)이 포함됩니다. 이 프로젝트의 사본을 가져오고 프로덕션을 NODE_ENV 변수로 설정 한 컴퓨터는 이 섹션에 나열된 종속성을 설치하지 않습니다.

peerDependencies 

이것은 동일한 형식을 사용하지만 이러한 종속성은 반드시 설치되는 것은 아니지만 이 앱 / 패키지가 올바르게 작동하는 데 필요한 호환성을 정의합니다. 예를 들어 React 16 버전과 호환되는 라이브러리를 개발하는 경우 다음과 같이해야 합니다.

"peerDependencies": {
  "react": "16.0.0"
}

이전 버전의 npm (1 및 2)은 이러한 peerDependencies를 자동으로 설치하는 데 사용되었지만 더 이상 그렇지 않습니다. 버전 3부터 이 프로젝트를 설치할 때 호환 가능한 버전을 찾지 못하면 경고가 발생합니다.

engines 

이 프로젝트가 지원하는 최소 버전의 노드 및 npm을 정의 할 수 있는 객체입니다. 다음 형식으로 정의됩니다.

"engines": {
  "node": ">= 6.0.0",
  "npm": ">= 3.0.0"
}

프로젝트가 설치되면 호환성을 확인하는 검사가 실행됩니다. 이를 충족하지 않으면 설치 프로세스가 중지됩니다.

종속성의 경우와 마찬가지로 범위 (예 : **> = **, ** ^ **, ** ~ ** 등)를 사용하여 호환 가능한 버전을 정의 할 수 있습니다.

더 많은 정보 

이것들이 package.json 파일 내에서 찾아서 사용하는 가장 일반적인 것들이지만, 흥미롭거나 확인하기에 유용한 추가 파일이 여전히 있습니다. 추가 참조를 위해 새로운 버전이 출시 될 때마다 지속적으로 업데이트 되므로 정기적으로 npm 공식 문서를 검토하는 것이 좋습니다.

유용한 링크:

NPM의 공식 package.json 문서.

npm- 스크립트 문서

npm-config 문서