[자바스크립트 패키지 관리자] npm(npx), yarn, pnpm, bun 차이 (with. nodejs)
0. js package manager의 시작, npm
nodejs : js를 브라이주 밖에서도 쓰게 해주는 런타임 환경. (http 서버가 내장되어 있어 보통 서버로 사용.)
node.js에서 자주 쓰이는 코드를 패키지로 만듦. > 이런 패키지들을 모아놓은 것 > npm.
1. npm이란
npm은 패키지 중앙 저장소인 npm 레지스터리에서 다양한 패키지를 모아서 관리. (npm 유료 결제 시, 비공개 npm을 사용하거나, 사내에서만 쓸 내부 npm 구축도 할 수 있음)
참고 : https://heropy.blog/2019/01/31/node-js-npm-module-publish/
내 NPM 패키지(모듈) 배포하기
개발을 위해 npm install xxx로 설치하는 모듈이 많아지면서 자주 사용하는 나의 코드들도 같은 방법으로 제공하고 싶었죠.하지만 ‘코드 복붙’이 더 쉬우니 차일피일 ...
heropy.blog
- npm 은 node.js의 모든 패키지와 모듈을 관리하며 CLI 클라이언트 npm으로 구성된다.
- node.js를 설치하면 시스템에 설치된다.
- Node 프로젝트의 필수 패키지 및 모듈은 npm을 사용하여 설치된다.
- 패키지에는 모듈에 필요한 모든 파일이 포함되어 있다.
- 모듈은 프로젝트 요구사항에 따라 Node 프로젝트에 포함될 수 있는 Javascript 라이브러리이다.
로컬에 npm 으로 패키지를 설치하려면
{
"name": "Your app",
"versiuon": "1.0.0",
"scripts": {
"your-package": "your-package-name"
}
}
작성한 패키지를 실행하려면
npm run your-package-name
package.json과 의존성 관리
Node.js 프로젝트에서는 많은 패키지를 사용하게 되고 패키지의 버전도 빈번하게 업데이트되므로 프로젝트가 의존하고 있는 패키지를 일괄 관리할 필요가 있다.
npm은 package.json 파일을 통해서 프로젝트 정보와 패키지의 의존성(dependency)을 관리한다.
이미 작성된 package.json이 있다면 팀 내에 배포하여 동일한 개발 환경을 빠르게 구축할 수 있는 장점이 있다.
Tip
package.json은 Java의 maven에서 pom.xml과 비슷한 역할을 한다.
package.json을 생성하려면 프로젝트 루트에서 npm init 명령어를 실행한다.
일단 기본 설정값으로 생성된 package.json 파일을 수정하는 방법이 더 편리할 수 있으므로 npm init 명령어에 --yes 또는 -y 옵션을 추가한다. 그러면 기본 설정값으로 package.json 파일을 생성한다.
// $ npm init -y
// Wrote to /Users/leeungmo/Desktop/emoji/package.json:
{
"name": "emoji",
"version": "1.0.0",
"description": "",
"main": "index.js",
"dependencies": {
"node-emoji": "^1.10.0"
},
"devDependencies": {},
"scripts": {
"test": "echo \"Error: no test specified\" && exit 1"
},
"keywords": [],
"author": "",
"license": "ISC"
}
Key | Value |
name | 프로젝트 이름으로, 가장 중요합니다. 중앙 저장소에 배포할 때 version과 함께 필수 항목입니다. url로 사용되고, 설치할 때 디렉토리 이름이 되기 때문에 url이나 디렉터리에서 쓸 수 없는 이름을 사용하면 안 됩니다. 또한, 이름에 node나 js가 들어가면 안 됩니다. name은 214자보다 짧아야 하며, 점(.)이나 밑줄(_)로 시작할 수 없습니다. 대문자를 포함해서는 안 되며, require() 함수의 인수로 사용되며 짧고 알기 쉬운 것으로 짓는 것이 좋습니다. |
version | 프로젝트 버전을 정의합니다. 3단계 버전을 사용하며, - 로 태그 이름을 적을 수 있습니다. |
description | 프로젝트 설명으로, 문자열로 기술합니다. npm search로 검색된 리스트에 표시되기 때문에 사람들이 패키지를 찾아내고 이해하는 데 도움이 됩니다. |
keywords | 프로젝트를 검색할 때 참조되는 키워드입니다. description과 마찬가지로 npm search로 검색된 리스트에 표시됩니다. |
homepage | 프로젝트 홈페이지 주소입니다. url 항목과는 다르며, url을 설정하면 예상치 못한 움직임을 하게 되므로 주의합니다. |
author | 프로젝트 작성자 정보로, 한 사람만을 지정합니다. JSON 형식으로 name, email, url 옵션을 포함합니다. |
contributors | 프로젝트에 참여한 공헌자 정보로, 여러 사람을 배열로 지정할 수 있습니다. |
repository | 프로젝트의 소스 코드를 저장한 저장소의 정보입니다. 소스 코드에 참여하고자 하는 사람들에게 도움이 될 수 있습니다. 프로젝트의 홈페이지 url을 명시해서는 안 됩니다. |
scripts | 프로젝트에서 자주 실행해야 하는 명령어를 scripts로 작성해두면 npm 명령어로 실행 가능합니다. |
config | 소스 코드에서 config 필드에 있는 값을 환경 변수처럼 사용할 수 있습니다. |
private | 이 값을 true로 작성하면 중앙 저장소로 저장하지 않습니다. |
dependencies | 서비스를 배포할때 쓰이는 모듈을 관리를 위한 부분입니다. 이 프로젝트가 어떤 확장 모듈을 요구하는지 정리할 수 있습니다. 일반적으로 package.json에서 가장 많은 정보가 입력되는 곳입니다. 애플리케이션을 설치할 때 이 내용을 참조하여 필요한 확장 모듈을 자동으로 설치합니다. 따라서 개발한 애플리케이션이 특정한 확장 모듈을 사용한다면 여기에 꼭 명시를 해주어야 합니다. 또한, npm install 명령은 여기에 포함된 모든 확장 모듈들을 설치하게 되어 있습니다. |
devDependencies | 개발할 때만 사용하는 확장 모듈을 관리합니다. |
engine | 실행 가능한 노드 버전의 범위를 결정합니다. |
package.json에서 가장 중요한 항목은 name과 version이다. 이것은 패키지의 고유성을 판단하므로 생략할 수 없다.
그리고 dependencies 항목에는 해당 프로젝트가 의존하는 패키지들의 이름과 버전을 명시한다. 여기서 의존하는 패키지란 해당 프로젝트에서 참조하는 모듈을 의미한다.
프로젝트를 진행할 때는 이미 만들어진 여러 패키지를 참조해서 사용하는데, package.json 파일의 dependencies 항목에 해당 패키지의 이름과 버전을 명시함으로써 의존성을 설정한다.
devDependencies에는 개발 시에만 사용하는 개발용 의존 패키지를 명시한다.
예를 들어 TypeScript와 같은 트랜스파일러는 개발 단계에서만 필요하고 배포할 필요는 없으므로 devDependencies에 포함시킨다.
node_modules는 용량을 많이 차지하기 때문에 어디 서버에 배포할때는 지워둔다. (왜냐하면 용량이 많아서 언제 복사하나..)
필요한 파일만 서버에 이동시키고, 그리고 서버 내에서 패키지들을 재설치해서 하는 형식이다.
npm install 명령어를 사용하면 package.json에 명시된 모든 의존 패키지를 한번에 설치할 수 있다.
npm install
다만 인터넷을 폐쇄망으로 이용하는 기업은, 하는수없이 node_modules를 들고 가야한다.
package.json에서 설치한 모듈의 dependencies들을 정확하게 하나하나 명시를 해놓은 것이 package-lock.json 이다.
버젼 문제가 생기는 것 빼고는 잘 안건들인다.
출처: https://inpa.tistory.com/entry/NODE-📚-노드-npmnode-package-manager [Inpa Dev 👨💻:티스토리]
1-2. npm과 npx의 차이
NPX (Node Package eXecute)
Package eXecute = 실행
- npm 5.2.0 버전 이상부터 npm을 설치하면 자동으로 npx 가 설치된다.
- 즉, 새로운 패키지 관리 모듈이 아닌, npm의 5.2.0버전부터 새로 추가된 도구이다. 따라서 npm과 비교대상이 아니라, npm을 좀 더 편하게 사용하기 위해 npm 제공해주는 하나의 도구이다.
- 패키지를 설치하지 않고도 npm 레지스트리에서 원하는 패키지를 실행(Excute) 할 수 있다.
- 실행 즉, npm package runner 로써 npx는 일회용 패키지 로써 사용된다.
글로벌 모듈을 설치하지 않기 위한 몸부림
npm 을 통해서 모듈을 설치할 때, 한 가지 옵션을 주게 되면 매 프로젝트마다 모듈을 설치해 줄 필요가 없고 그저 내 컴퓨터 안에 글로벌한 공간에 모듈을 설치해 프로젝트마다 같은 모듈을 공유해서 사용할 수 있습니다.
바로 -g 옵션인데요, 사용 방법도 꽤 간단합니다.
npm install 모듈이름 -g
-g를 붙여주기만 하면 글로벌 모듈을 설치할 수 있습니다.
개발자 입장에서는 귀찮게 여러 번 설치할 필요도 없고 한 번 설치면 끝나는데 왜 좋은 방법이 아닐까 라고 생각하시는 분들이 있을지도 모르겠습니다. 그 이유에는 대표적으로 3가지가 있습니다.
1. 모듈이 업데이트 되었는지 안되었는지 확인이 불가능
모든 프로젝트마다 모듈을 재설치 하는것이 아닌, 한 번 설치한 모듈을 그대로 사용하기 때문에 프로그래머가 의식해서 글로벌 모듈을 최신 버전으로 재 설치하지 않으면 확인 자체가 불가능 합니다.
2. 업데이트를 진행했을 때 변동사항이 생겨 다른 프로젝트에도 영향
프로젝트를 3개를 운영하는데, 같은 모듈의 각각 다른 버전이 필요한 상황이 있을 수 있습니다. 이럴 때 글로벌 모듈의 버전은 당연히 한 개이기 때문에 문제가 발생하게 됩니다.
3. create-react-app 같은 보일러플레이트에는 치명적 (자주 최신 버전 업데이트 필요)
리액트 프로젝트 생성 도구인 create-react-app 같은 모듈의 경우, 변경사항이 꽤나 잦은 모듈입니다. 그렇기 때문에 매 설치 전마다 npm으로 재 설치를 하지 않는 경우에는 이전 버전을 사용할 여지가 꽤 있습니다. 이런 프로젝트 생성 모듈은 매 업데이트마다 새로운 기능과 다양한 버그들이 고쳐집니다. 그리고 이런 보일러플레이트 같은 경우에는, 항상 최신 버전을 유지해 주는 것이 좋은데, 매번 설치하는 것이 꽤나 귀찮은 일입니다.
npx
npm 5.2버전부터, npx가 기본 패키지로 제공 npx도 모듈의 일종.
이 모듈은 npm을 통해 모듈을 로컬에 설치했어야만 실행시킬 수 있었던 기존 문제점의 해결책이 되었습니다.
모듈을 로컬에 저장하지 않고, 매번 최신 버전의 파일만을 임시로 불러와 실행 시킨 후에, 다시 그 파일은 없어지는 방식으로 모듈이 돌아가고 있습니다.
create-react-app같은 보일러 플레이트 모듈에 효과적 입니다. npx를 통해 create-react-app을 설치할 경우에는 매번 최신 버전만을 가져와서 설치해 주기 때문에 지금 어떤 버전을 사용하고 있는 지 신경쓸 필요가 없어집니다. 어짜피 최신 버전만을 사용할 테니까요.
https://youngmin.hashnode.dev/npm-npx
npm(node package manager) & npx(node package execute)
npm(node package manager) & npx(node package execute)에 대해서 이해해보겠습니다.
youngmin.hashnode.dev
2. yarn
yarn은 npm의 부족한 부분들을 개선하기 위해 Facebook에서 개발되었다. Yarn은 npm이 사용하는 동일한 npm 구조에 의존한다. 따라서 패키지의 레지스트리에 대한 것은 바뀌지 않았고, 설치 절차가 바뀌었다고 생각하면 된다.
npm vs Yarn
그렇다면, 이 두 패키지 매니저의 차이점들로는 어떤 것들이 있을까?
Speed (Performance)
npm은 필수 단계를 순차적으로 수행하는 경향이 있어서 다음 패키지로 넘어가기 전에 각 패키지를 완전히 설치해야 한다고 한다. 하지만 Yarn은 동시에 여러 패키지들을 설치할 수 있기 때문에 속도 면에서 크게 향상된다는 것이다. 그런데 이 속도의 문제도 npm 5.0 아래의 버전으로 놓고 봤을 때의 문제이다. npm 5.0 버전은 그 아래 버전들보다 5배는 더 빠르다고 npm 개발자들이 언급하였다고 한다. 그리고 그 이후 npm V6.10.1과 yarn V1.17.3으로 install 속도 실험을 하였는데, yarn이 승리하였지만 그 차이는 아주 근소한 차이라고 한다. 이제는 거의 차이가 없어졌다고 볼 수 있는 문제인 것 같다.
Security
npm은 의존 관계를 가지는 다른 패키지들이 즉시 포함되도록 한다. 이런 부분이 더 편리하긴 한데 보안 문제에 있어 여러 취약점들을 불러올 수 있다고 한다. 이게 커지면 나중에는 더 큰 문제로 발전할 수도 있다는 것. 반면에 Yarn은 yarn.lock이나 package.json 파일에 있는 것들만 설치를 한다. 이런 방식은 모든 디바이스에 같은 패키지들을 설치하는 것을 보장하기 때문에 디바이스마다 다른 버전을 설치해서 발생할 수 있는 버그들을 많이 줄였다는 것이다. 이 보안성 문제가 npm과 yarn을 비교할 때 아주 중요한 측면이라고 할 수 있고, 이 부분은 계속 강화되고 있다고 하니 보안성을 따질 때는 yarn이 더 좋다고 말할 수 있다.
패키지 잠금 파일
npm은 package-lock.json, yarn은 yarn.lock 파일을 패키지 잠금 파일로 사용한다. 잠금 파일도 자세히 살펴보면 차이점이 있겠지만, 이 부분은 크게 자세히 다루지는 않겠다.
이 외에도 다양한 차이점들이 있다. 명령어에도 조금씩 차이가 있는데, 패키지를 추가하고 싶을 때 npm은 npm install <package>, yarn은 yarn add <package> 명령어를 사용한다. 패키지 제거에 있어서도 npm에서는 npm uninstall/rm <pacakge>를 사용하지만, yarn은 yarn remove <package> 명령을 통해 수행한다.
npm과 Yarn, 무엇을 선택할까?
Yarn에도 단점이 있다. 디스크 용량을 좀 더 많이 잡아먹는 편이라고 한다. Yarn이 npm의 개선된 버전의 개념으로 나왔고, 속도나 보안성 측면에서 개선되었다고 할 수 있다. 하지만 npm도 개선된 버전이 계속 나오면서 속도는 yarn과 별반 차이가 없다고 볼 수 있다. npm도 yarn보다 더 오래되었기도 하고 효율성 측면에서 많은 장점들이 있으니 yarn이 출시되었다고 해서 배제할 수 있다고는 절대 볼 수 없을 것 같다.
결론은 !!! 두 패키지 모두 다른 방면에서 장점을 가지고 있으니 개발자 입맛대로 고르면 될 것 같다.
https://seogeurim.tistory.com/12
npm? yarn? 그 차이가 뭐길래...
본 글은 2020년에 작성된 글입니다. node 개발 환경에서는 패키지 매니저로 npm 또는 yarn을 쓰곤 한다. 나는 그냥 npm이 편해서 npm을 써왔었는데, 한 프로젝트를 진행하다가 팀원들이 다 yarn을 쓰자고
seogeurim.tistory.com
패키지 관리자로 yarn 또는 npm중 하나를 일괄적으로 사용하다가
가끔씩 실수로 혼용하는 경우가 있다.
npm과 yarn은 패키지 관리 방식이 다르기 때문에 충돌이 날 수 있으므로 가급적이면 혼용하지 않는게 좋다.
yarn은 설치한 패키지와 종속되는 패키지를 공통적으로 사용할 때 일렬로 나열한 뒤 설치 패키지로 링크하는 방식으로. 패키지 중복이 제거되어 적은 용량으로 빠른 실행을 꾀할 수 있으나 네이티브 및 yarn을 고려하지 않은 버전 관리로 인한 드문 케이스로 패키지 충돌이 있을 수 있다.
npm은 각 설치한 패키지별로 서브패키지를 이루는 형식으로, 각 설치한 패키지의 독립성이 보장되지만 패키지 중복으로 인한 크기가 전체적으로 커진다.
lock 파일은 둘 다 있어도 상관은 없지만, npm install 이던 yarn add 면 한 번 시작하면 끝까지 사용했던 패키지 관리자로 진행하는 게 패키지 충돌 오류를 막는 좋은 방법이다.
https://norwayy.tistory.com/390
yarn과 npm을 혼용하면 안되는 이유
패키지 관리자로 yarn 또는 npm중 하나를 일괄적으로 사용하다가 가끔씩 실수로 혼용하는 경우가 있다. npm과 yarn은 패키지 관리 방식이 다르기 때문에 충돌이 날 수 있으므로 가급적이면 혼용하지
norwayy.tistory.com
yarn 장점
- 다운로드한 패키지를 캐싱하므로 재다운로드가 필요 X (오프라인 가능)
<디렉토리 경로>
$ yarn cache dir $HOME/Library/Caches/Yarn/v1
- 운영을 병렬화하여 리소스 활용 극대화
- 체크썸을 통해 코드 실행 전 설치된 패키지의 무결성을 확인
- 한 시스템에 작동하는 설치가 다른 시스템에서 동일한 방식으로 작동하는 것을 보장
yarn 단점
- yarn.lock파일의 버전 관리로 인해 기존 모듈이 최산화로 업데이트 될 수 있는데, 이 경우 하위 호환을 보장하지 않는 모듈의 경우는 에러 발생할 가능성이 존재
npm, yarn 차이점
✏️ 속도
패키지 설치 프로세스를 처리하는 방법에서 차이
- npm: 패키지를 한 번에 하나씩 순차적으로 설치
- yarn: 여러 패키지를 동시(병렬화)에 가져오고 설치하도록 최적화
패키지 설치 속도 측면에서 yarn이 npm보다 빠르다.
✏️보안
보안 측면에서의 차이
- npm: 자동으로 패키지에 포함된 다른 패키지 코드를 실행. 이로 인해 보안 시스템에 몇 가지 취약성이 발생하며 나중에 심각한 문제가 발생.
- yarn: yarn.lock 또는 package.json파일에 있는 파일만을 설치.
yarn은 보안 측면에서 yarnrhnpm보다 더 안전.
But, 최근 npm의 업데이트에서 npm의 보안 업데이트도 크게 향상되었습니다.
✏️ 버전관리
초기 프로젝트 구성후 버전관리가 진행되지 않은 상태에서 새로운 프로젝트 환경 구성을 구성해 줄 때, 패키지들이 일괄 최신버전으로 유지되면서, 현재 작업중인 프로젝트의 패키지들과 버전이 맞지않는 상황이 발생.
이때 업데이트 상황의 차이
- npm: npm update 진행시 종속된 패키지의 업데이트로 Deprecated 된 함수가 생기고, 그로 인해 특정 함수가 동작하지 않는 '버전 불일치'로 인한 오류가 발생할 가능성이 크다
- yarn: 프로젝트 구성시 yarn install을 진행한 시점으로 버전정보가 yarn.lock에 저장. 따라서 업데이트 및 새로운 환경을 구축할 때도 동일한 버전정보를 가진 패키지 구성이 되게 한다.
즉, npm은 업데이트 시 버전이 업데이트되어 불일치. yarn은 버전이 저장되어 업데이트되어도 동일한 버전 유지
✏️ 명령어
💡 잠깐) --save & --dev
(npm을 예로 든 경우)
npm install 모듈명 --save 을 입력하면, 설치하는 모듈을 package.json에 등록할 수 있다.(npm@5 부터는 –save는 기본옵션이다.)
그래서, npm@5 부터는 –save 옵션을 사용하지 않더라도, 모든 install 명령은 package.json의 dependencies에 설치되어 관리된다.
그리고, npm install 모듈명 --save --dev을 입력하면, 설치하는 모듈을 package.json에 등록할 수 있을 뿐만 아니라, –dev 때문에, package.json 파일에서 devDepencies에 등록된다. devDepencies에서 관리하는 모듈들은 개발용 모듈들이고, depencies에서 관리하는 모듈들은 배포용 모듈들이다.package.json에 명시된 모든 의존 패키지를 한번에 설치하기 위해서는, npm install 명령어를 사용하면 된다.
3. pnpm
pnpm
장점
pnpm은 2017년에 Zoltan Kochan이라는 개발자가 내놓은 패키지 매니저로 "performant npm"의 약자이기도 하다.
즉, 효율적인 npm이라는 의미인데 말 그대로 효율성이라는 장점이자 특징을 가진 패키지 매니저다.
pnpm의 경우에는 프로젝트별로 node_modules에 매번 패키지를 설치했던 것과는 달리 global 저장소에 패키지를 한 번만 저장함으로써 저장 공간을 절약할 수 있다는 아주 큰 장점을 가지고 있다.
즉, pnpm을 사용한다면 똑같은 라이브러리를 중복해서 설치할 필요가 없다는 의미다.
다만, 주의할 점은 특정 패키지를 한 번만 설치하기 때문에 프로젝트별로 연결을 해놓으면 호환 문제가 발생할 수 있다. 따라서 프로젝트끼리 호한 문제가 발생하지 않도록 버전 관리를 반드시 해줄 필요가 있다.
패키지 매니저 비교 - npm, yarn, pnpm
패키지 매니저 알아보기 - 각각의 특징과 간단한 사용 방법
velog.io
- 다른 javaScript 패키지 매니저에 비해 최대 2배 이상 빠르다. (dependency마다 설치가 병렬적으로 수행되기 때문)
- 프로젝트별로 node_modules에 매번 패키지를 설치했던 것과는 달리 global 저장소에 패키지를 한 번만 저장함으로써 저장 공간을 효율적으로 절약할 수 있다. (중복 패키지를 공유하여 효율적으로 디스크 공간을 관리하고 빠르게 패키지를 설치)
- npm을 사용했던 개발자들이 쉽게 적응 할 수 있다.
- 모노레포 지원
- npm 9.4v 부터 Isolated node_modules 모듈 지원
단점
- 주의할 점으로 특정 패키지를 한 번만 설치하기 때문에 프로젝트별로 연결을 해놓으면 호환 문제가 발생할 수 있다. 그렇기에 프로젝트끼리 호환 문제가 발생하지 않도록 버전 관리를 반드시 해야 한다.
[패키지 매니저] npm, yarn, pnpm, yarn-berry
다양한 자바스크립트 패키지 매니저에 대해 알아보고 비교해보자!
velog.io
4. bun
https://ykss.netlify.app/translation/bun_vs_node_js_everything_you_need_to_know/
(번역) Bun vs Node.js : 당신이 알아야 할 모든 것들
원문: Bun vs Node.js: Everything you need to know 9월 8일, 자바스크립트 커뮤니티에 새로운 소식이 들려왔습니다. Jarred Sumner가 만든 Bun v1.0이 출시되었기 때문입니다. 하지만 많은 사람들이 궁금해하는 것
ykss.netlify.app
현재 MacOS와 Linux에 최적화되어 있으며, Windows 지원도 진행 중
https://helloinyong.tistory.com/353
Bun 1.0 릴리즈 후, 서비스 개발에 문제 없을지 리서치 해본 결과
최근에 1.0 Release가 되었다는 소식에 다시 한번 리서치를 해보았다. 작년쯤에도 한번 리서치를 해보면서 그땐 pacakge Manager, RunTime까지만 제공하는 걸로 알고 있었는데, 그 당시에는 발견할 수 없
helloinyong.tistory.com
추가 참고
https://dev.to/vsnikhilvs/package-manager-fight-npm-vs-pnpm-vs-npx-vs-yarn-vs-bun-569
Package Manager Fight: npm vs pnpm vs npx vs yarn vs bun
In the ever-evolving landscape of JavaScript development, package managers are a crucial part of...
dev.to