hmk run dev

package.json 구조 본문

Front-End

package.json 구조

hmk run dev 2022. 4. 15. 18:05

npm init으로 생성하거나 직접 작성해 생성 가능!

{
	"name" : "test",
	"description" : "javascript's test programming.",
	"keywords" : ["util", "f", "server", "client", "browser"],
	"author" : "Goorm",
	"contributors" : [],
	"dependencies" : [],
	"repository" : {"type": "git", "url" : "git://gitbub.com/documentcloud/test.git" },
	"main" : "test.js",
	"version" : "1.1.6"
}

name

- 프로젝트 이름 중앙 저장소에 배포 시 version과 함께 필수항목

- url, 설치할 때 디렉터리 이름이 되기 때문에 url이나 디렉터리에 쓸 수 없는 이름을 사용하면 안 된다.

- 이름에 node나 js가 들어가면 안 됨

- 214자 아래여야 하며.이나 _ 로 시작할 수 없다.

- 대문자를 포함하면 안 되고 짧고 가독성 좋은 것으로 짓는 것이 좋음

version 

- 프로젝트 버전을 의미. 3단계 버번을 사용하며 - 로 태그 이름을 적을 수 있음

description

- 프로젝트 설명으로, 문자열을 기술

keywords

- 프로젝트를 검색할 때 참조되는 키워드

- description과 같이 npm search로 검색된 리스트에 표시된다.

author

- 프로젝트 작성자 정보로, 한 사람을 지정하며 JSON 형식으로 name, email, url 옵션을 포함

다.

 

contributors

- 프로젝트 참여자 여러 사람을 배열로 지정할 수 있음

repository

- 프로젝트의 소스 코드를 저장한 저장소 정보

 

scripts

- 프로젝트에서 자주 실행해야 하는 명령어를 지정

config

- 소스 코드에서 config 필드에 있는 값을 환경 변수처럼 사용할 수 있다.

repository

- 프로젝트의 소스 코드를 저장한 저장소 정보

"name": "foo",
"config": {
    "port": "8080"
}

 

private

-  이 값을 true로 작성하면 중앙 저장소로 저장하지 안

dependencies

- 프로젝트의 의존성 관리, 어떤 확장 모듈을 요구하는지 정리할 수 있음

- 애플리케이션을 설치할 때 이 내용을 참조하면 필요한 확장 모듈을 자동으로 설치

- npm install 명령어로 여기 포함된 모든 확장 모듈을 설치

 

dependencies속성에선 Semantic Versioning을 살펴볼 필요가 있다!

"dependencies" : {
	"react-redux" : "^16.12.0"
}

react-redux 의존성을 보면 버전이 명시되어있다

 

Major Version - 16 / 기존 api 변경 및 삭제되거나 하위 버전이 호환이 되지 않는 버전 

Minor Version - 12 / 신규 기능이 추가되거나 하위 호환이 되는 버전

Patch Version - 0 / 버그 수정이 되었고 하위 호환이 되는 버전

 

참고

https://otrodevym.tistory.com/entry/%EB%B2%84%EC%A0%84%EA%B4%80%EB%A6%AC-Semantic-Versioning%EC%8B%9C%EB%A7%A8%ED%8B%B1-%EB%B2%84%EC%A0%84%EA%B4%80%EB%A6%AC%EC%99%80-Version-Ranges

 

[버전관리] Semantic Versioning(시맨틱 버전관리)와 Version Ranges

소프트웨어 생태계에서 버전에 대한 관리를 어떻게 할 것인지에 대한 방법론으로 시맨틱 버전 관리를 들 수 있습니다. 관련 정보는 아래 사이트에서 확인할 수 있으며 본 포스팅은 요약본입니

otrodevym.tistory.com

 

 


devDependencies

- 개발할 때만 의존하는 확장 모듈을 관리

 

engine

- 실행 가능한 노드 버전의 범위 결정

 


package-lock.json

 

이 외에도 package-lock.json에 대해 살펴보면 좋다!

 

package.json에서 버전 정보를 저장할 때 version range를 사용합니다.

 

내가 사용할 패키지의 버전은 1.4.7이다 대신 1.4.7 이상의 패키지를 사용할 거다 처럼 말한다.

 

실제로 협업을 위해 같은 package.json을 사용해 각자의 컴퓨터에 같은 패키지들을 설치해 같은 개발환경을 세팅하는 경우가 많습니다.

 


- npm의 버전이 다른 경우, npm의 알고리즘이 조금씩 다르기 때문에 서로 다른 node_modules 트리가 생성될 수 있습니다.

 

- 콕찝어서 버전명을 명시하지 않고version range를 사용하기 때문에, 새로운 버전의 패키지가 배포된 이후 설치를 진행할 경우 최신 버전으로 설치될 수 있습니다.

 

- 내가 사용하고 있는 패키지가 의존하고 있는 패키지가 새로운 버전으로 배포되었을 경우, 다른 node_modules 트리가 생성될 수 있습니다.

 

위의 문제는 npm --version 명령어로 npm의 버전을 체크한 뒤 일치시키고 작업하면 예방할 수 있는 문제입니다.

 

하지만 npm version을 확인하지 않고 다른 버전으로 작업했을 경우엔 어떻게 해야 할까요??

이 문제를 해결하기 위해 package-lock.json이 등장했습니다!

 

package-lock.json은 node_modules 구조나 package.json이 수정되고 생성될 때 당시 의존성에 대한 정확하고 구체적인 정보를 품고 자동으로 됩니다. > npm install

 

package-lock.json이 존재하면 npm install의 동작 방식이 조금 달라지는데

 

package.json을 사용하여 node_modules를 생성하지 않고 package-lock.json을 사용하여 node_modules를 생성합니다.

 

정리하자면 node_modules 트리를 생성해 같은 의존성을 설치할 수 있도록 도와주는 친구다라고 할 수 있습니다..!

 

 

 

'Front-End' 카테고리의 다른 글

wasm과 webworker를 도입해보다...!  (0) 2023.04.16
webpack과 vite  (0) 2022.06.15
webpack 이전의 세계  (0) 2022.06.15
clientX, offsetX, pageX, screenX 차이점  (0) 2022.04.15
webpack 개념과 적용방법  (0) 2022.04.05
Comments