JavaScript 코드로 작업하는 경우 모든 프로젝트에서 package.json 파일을 보게 됩니다.
npm install 또는 yarn을 실행할 때마다 해당 패키지 관리자는 해당 파일을 살펴보고 필요한 종속성을 가져옵니다.
그러나 이러한 파일은 귀중한 정보와 강력한 기능으로 가득 차 있습니다.
이 예제를 참조 점으로 사용하겠습니다.
{
"name": "example-package",
"description": "A package that does a thing",
"version": "1.0.0",
"author": "laurieontech",
"repository": {
"type": "git",
"url": "https://github.com/some-project-here"
},
"dependencies": {
"react": "16.8.6"
},
"devDependencies": {
"prettier": "^1.18.2"
},
"keywords": ["react"],
"license": "MIT",
"main": "index.js",
"scripts": {
"test": "jest"
},
"bin": "./bin/executable.js"
}https://dev.to/laurieontech/the-anatomy-of-package-json-pi4
Metadata
package.json의 처음 몇 개 항목은 설명적입니다. 프로젝트에 대한 컨텍스트를 제공하기 위해 설명, 저장소 및 작성자 (또는 여러 사람이 있는 경우 기고자)가 있습니다. npm에 패키지를 게시하는 경우 해당 정보는 패키지 페이지에서 사용할 수 있습니다. 이름과 버전이 조금 더 있습니다.
name은 케밥 케이스 패키지 이름입니다. 이것은 npm에서 찾을 수 있는 이름입니다. 이것은 패키지를 설치하는 데 사용할 이름입니다. 패키지를 사용하는 데 익숙하다면 "react": "와 같은 구문에 익숙할 것입니다. 16.8.6 인치. 이것은 이름과 버전 번호입니다.
대부분의 JavaScript 프로젝트는 패키지 버전을 직관적으로 증가시키는 방법으로 semver를 따릅니다. 패키지가 npm에 게시 될 때마다 버전이 증가해야 합니다. 첫 번째, 마지막 또는 중간 숫자 증가 여부는 변경의 중요성과 다른 모든 사람에게 미치는 영향에 따라 달라집니다.
의존성
종속성은 프로젝트가 의존하는 런타임 패키지 목록입니다. npm install 등을 실행할 때 설치됩니다.
"react": "16.8.6"에 대해 다시 이야기 해 봅시다. 각 종속성은 패키지의 이름과 버전을 사용하여 키-값 쌍으로 나열됩니다. 그러나 버전 앞에 추가 할 수 있는 추가 문자가 있습니다.
추가로 지원되는 문자도 있으므로 범위를 지정할 수 있습니다. 이들 모두는 semver 패키지를 사용하여 구문 분석됩니다. 이것은 약간 혼란스러우므로 명확히 하겠습니다. Semver는 패키지 버전 관리를 위한 일련의 지침입니다. npm은 이를 따르고 해당 지침을 패키지 관리자의 기반으로 사용하므로 그에 따라 사용하는 의미 체계 버전 관리 패키지의 이름을 지정했습니다.
devDependencies
devDependencies는 약간 다릅니다. 이는 패키지에서 작업하는 개발자에게 필요한 종속성입니다. 테스트 라이브러리. 그러나 최종 사용자는 필요하지 않으므로 별도로 포함됩니다. example-package 내에서 npm install을 실행할 때 포함되지만 다른 프로젝트 내에 example-package를 npm 설치할 때는 포함되지 않습니다.
peerDependencies
이것은 또 다른 유형의 종속성입니다. 패키지 작성자는 다른 종속성도 사용 중인 패키지를 사용할 때 충돌을 방지하기 위해 주로 있습니다. 예 : 패키지가 호환되지 않을 수 있는 로컬 버전이 아닌 프로젝트의 Babel 버전을 사용하고 있는지 확인합니다.
키워드
키워드는 npm 검색 기능을 위한 도우미입니다.
license
여기에 "나는 변호사가 아닙니다"라는 필수 코멘트입니다. 라이센스는 전문가가 있는 주제이며 나는 그들 중 하나가 아닙니다. 나열된 라이선스는 프로젝트 사용이 허용되는 조건입니다. 다양한 라이선스에 대해 자세히 읽을 수 있습니다.
주요 진입 점
누군가 패키지를 가져올 때 참조되는 파일입니다. "main": "index.js"가 주어지면 const example = require ( "example-package")는 index.js에서 예제 내보내기를 가져옵니다.
scripts
이것은 우리가 파일의 핵심에 들어가는 곳입니다. 스크립트 섹션에는 더 많은 키-값 쌍이 포함되어 있습니다. 키는 명령의 이름이고 값은 호출 할 때 실행되는 명령 줄 명령입니다.
간단한 예부터 시작하겠습니다.
{
"test": "npm run jest"
}이것은 무엇보다 별칭에 가깝습니다. 이를 통해 명령 줄에서 npm 테스트를 실행할 수 있으며 실제로 npm run jest를 실행할 수 있습니다.
좀 더 복잡한 것은 어떻습니까?
{
"lint": "eslint --cache --ext .js,.jsx,.ts,.tsx ."
}이것은 특정 플래그를 사용하여 전체 프로젝트 디렉토리에 대해 eslint를 실행합니다.
이 스크립트를 직접 실행하는 것을 방해하는 것은 없습니다. 올바른 구성으로 더 짧은 명령을 제공하는 것이 더 나은 경험입니다.
그러나 다른 프로젝트에 패키지로 게시 및 설치할 수 있도록 프로젝트를 빌드하기 위한 일부 스크립트가 있습니다. 지정된 시간에 스크립트를 실행하는 특수 키가 있지만 여기서는 자세히 설명하지 않겠습니다.
대신 프로젝트를 번들로 묶고 설치 준비를 하는 몇 가지 유형의 스크립트를 살펴 보겠습니다.
Babel 예
{
"build": "babel src --out-dir . --ignore \"**/__tests__\""
}이 첫 번째 스크립트는 바벨을 사용하고 있습니다. 프로젝트의 루트에 있는 구성 파일을 사용하면 src 디렉토리의 모든 파일을 가져와 루트 디렉토리로 컴파일합니다. 또한 src / __ tests__의 파일을 무시하는 플래그를 포함합니다.
마이크로 번들 예
{
"build": "microbundle -i src/example.js"
}이 스크립트는 microbundle을 사용하여 프로젝트를 번들링 합니다. 이 경우 빌드를 위한 진입 점으로 src / example.js를 지정합니다.
스크립트 실행
스크립트를 실행할 수 있습니다. 위에서 npm 테스트는 npm jest를 실행한다고 언급했습니다. 그러나 이는 test가 npm run test의 별칭이기 때문입니다. 이 중 몇 가지가 있습니다.
지정하는 다른 사용자 지정 스크립트의 경우 사용자는 npm run <script>를 실행해야 합니다.
bin
한 가지 더 재미있는 것! npm 명령 외에도 이제 npx 명령이 있습니다. npx를 사용하면 패키지를 먼저 설치하지 않고도 명령을 실행할 수 있습니다. ?
패키지 작성자는 package.json 파일의 bin 섹션을 사용하여 이를 활성화합니다. 키-값 쌍으로 작성하거나 아래 구문을 사용하여 작성할 수 있습니다.
{
"bin": "./bin/executable.js"
}이 경우 ./bin 및 확장자가 제거되고 사용자가 npx 실행 파일을 실행할 수 있습니다. 이를 구현하는 패키지를 작성하기로 결정한 경우 상대 파일 경로는 프로젝트의 번들 버전을 기반으로 합니다. 이것은 게시 된 패키지에서 직접 실행되기 때문에 의미가 있습니다.
등록된 댓글이 없습니다.
