[TIL]package.json

영태·2022년 4월 1일

TIL package.json

[TIL]

목록 보기

10/21

package.json

배포된 node package 를 다른 사람들이 관리하고 설치하게 쉽게 하기 위한 문서

package.json은 이렇게 생겼다

npm Docs에 적혀있는 설명에 따르면
package.json은

자신의 프로젝트가 의존하는 패키지의 리스트
자신의 프로젝트의 버전을 명시
다른 환경에서도 빌드를 재생 가능하게 만들어, 다른 개발자가 쉽게 사용할 수 있도록 도와줌

다음과 같은 기능을 한다

오픈소스 패키지 생태계를 사용하기 위한 명세
프로젝트의 의존성 관리를 위한 명세
오픈소스 패키지 생태계로의 배포를 위한 명세

이렇게 정리할수 있다

NPM(Node Package Manager)

npm은 node.js를 위한 패키지 매니저이자,node.js를 위한 오픈소스 생태계다
npm 명령어를 통해 오픈소스 패키지를 다운받거나 배포할 수 있다

yarn

비슷한 패키지 매니저인 yarn이 있는데
facebook에서 만든 자바스크립트 패키지 매니저다
yarn이 좀더 빠르다고 하여 나는 보통 이 yarn을 사용하고 있다

npm이랑 거의 비슷하다
다른 점은 패키지를 추가설치할때 (npm)install 대신 (yarn)add를 쓴다는 거 정도?

다음과 같이 npm을 이용하여 설치해 사용할 수 있다
$ npm install -g yarn

npm보다는 yarn을 사용하는 편이라 앞으로도 블로깅할 때 yarn을 더 많이 언급할 거 같다

package.json 사용법

패키지를 사용하고자 하는 폴더로 이동 후 터미널에 $ yarn init 혹은 $npm init 명령어를 사용하면 package.json의 프로토타입을 만들 수 있다

다음과 같은 질문을 시작하는데 초기값을 설정해줄수도 있고 엔터를 갈겨서 기본형로만 만들수 있다

초기값 설정할 수 있는 항목들이 보인다 이를 fields라고 한다
하나하나 살펴보자

1. 'name'과 'version'

name
패키지의 이름을 가리킨다.
설정을 안해봐서 몰랐는데 이름에는 나름의 규칙이 있다고 한다.

기본 규칙

must be lowercase, 소문자로 작성되어야 한다.
must be one word, 한 단어로 작성되어야 한다.
may contain hyphens and underscore, -(하이픈)이나 _(언더스코어)를 포함할 수 있다.

version

semantic versioning guidelines를 따르며,위와 같은 형식을 취한다

버전과 네이밍에 대한 규칙은 회사나 단체에 따라 다를것이다
확실한 것은
name과 version 이 두가지 fields는 필수적이다
이 fields가 누락되면 패키지는 설치될 수 없다

2. 'main'

이 fields는 터미널 초기 설정값에선 찾아볼 수 없지만 우리는 이미 이를 설정할 수 있었다.

바로 entry point 다
main은 패키지의 진입점(entry point)이 되는 모듈의 ID이다.

예를 들어, 사용자가 foo라는 이름의 패키지를 설치하고, require("foo")를 통해 모듈을 import하면, "main"으로 지정한 모듈의 exports 객체가 반환된다.

이런거라고 보면 된다

패키지 root의 상대경로로 지정해야 한다. 지정하지 않은 경우, root 폴더의 index.js로 기본값이 설정된다.
우리가 예제 공부를 할 때, index.js라는 파일이름으로 중추파일을 만드는 경우가 많은데 바로 이 때문인듯 하다

3. 'scripts'

scripts에 자주 사용할 shell command를 alias(별칭)으로 적으면 그 commands 대신 편리하게 사용할 수 있다

이렇게 nodemon 같이 적기 귀찮은 긴 command를 대신해 줄 수 있는 고마운 존재다
터미널을 띄우고 $yarn dev 혹은 $npm dev를 적으면 $nodemon index.js와 같은 명령을 전송할 수 있다고 보면 된다.

4. 'keywords', 'author', 'license', 'description'

'keywords' : 키워드를 문자열 배열로 설명.
description과 마찬가지로 npm에서 검색되었을 때 리스트에 표시되어 사람들이 패키지를 찾아내고 이해할 수 있는데 도움을 준다.

'author' : 배포자 한 사람을 위한 field로, 다수의 사람을 표시하기 위해서는 'contributors' field로 작성해야 한다.

이 두가지는 사실상 배포자용 fields라고 할 수 있다

'license' : 배포한 패키지에 대해 패키지 사용자가 패키지를 사용하는데 어떤 권한과 제한 사항이 있는지 알기 위해 license를 명시해야 한다.

'description' : 문자열로 기술한 패키지에 대한 설명.
npm에서 검색되었을 때 리스트에 표시되어 사람들이 패키지를 찾아내고 이해할 수 있는데 도움을 준다.

이외에 'funding'같이 자잘한 설명이 있는 fields들이 있는데 우리가 사용할 때는 사실상 불필요한 것들이니 넘어가자

5.'dependencies'&'devDependencies'

사용자에게 있어서 이 두가지가 사실상 핵심 fields다.

'dependencies'&'devDependencies'는
프로젝트가 의존하고 있는 패키지를 일괄적으로 관리하기 위한 fields라고 할수 있다.
해당 프로젝트가 어떤 라이브러리를 가지고 있어야 제대로 구동될 수 있는지 명세되어 있다.

또, 해당 필드를 이용하면, 협업을 할 때와 같이 여러사람이 동시에 작업을 해야할 때 이 파일을 이용해 $yarn install을 하기만 하면
동일한 개발환경을 빠르게 구축할 수 있도록 하는 장점을 가지고 있다.

{
  "dependencies": {
    "hexo": "^5.0.0",
    "hexo-deployer-git": "^3.0.0",
    "hexo-generator-archive": "^1.0.0",
    "hexo-generator-category": "^1.0.0",
    "hexo-generator-feed": "^3.0.0"
    // ...
  }
}

{
  "devDependencies": {
    "@testing-library/jest-dom": "^5.11.4",
    "@testing-library/react": "^11.1.0",
    "@testing-library/user-event": "^12.1.10",
    "alex": "^8.2.0",
    "eslint": "^7.30.0",
    "lerna-changelog": "~0.8.2"
    // ...
  }
}

"dependencies": 프로덕션 환경에서 응용 프로그램에 필요한 패키지.
"devDependencies": 로컬 개발 및 테스트에만 필요한 패키지.

이외에도 많은 필드들이 존재한다
패키지 관련 홈페이지를 가리키는 fields도 있고 버그와 이슈를 알릴 수 있는 url과 email을 적는 fields도 있다.
감이 왔을텐데, package.json의 fields 중 패키지 사용자들이 굳이 신경쓰지 않아도 되는 부분들을 명시한 fields들이 꽤나 많다.
패키지를 직접 개발할 개발자가 아니라면 fields들을 모두 알아야 할 필요는 없다.

패키지를 이용해 웹이나 앱을 개발하는 사용자라면
위에서 말한 fields 중 'version'과 'dependencies'
그 중에서도 'dependencies'가 중요하며 이들의 버전정보를 틀리게 고치거나 누락시키지 않는 것이 중요할 것이다

그렇지만...

참조한 개발로그 중에서 '언젠가 패키지를 개발하는 개발자가 될지도 모른다'는 말을 봤다.
나는 사실 패키지를 개발한다는 것은 상상도 못했다. 이제 겨우 javascript로 옹알이를 하는 수준이기에...

저 말에서 개발로그 주인의 자신감과 야망이 느껴졌다.
나도 언젠가 패키지를 개발할 줄 아는 개발자가 될 수 있길...