자바 스크립트 의존성 관리 : npm vs. bower vs. volo


160

당신은 어떻게 비교 npm하고 bower,volo ?

세 가지 모두 UI 프로젝트에 대한 JavaScript 종속성을 설치하는 데 사용할 수 있습니다. 이해 했어요npm 더 노드마다 다르다는 합니다.

그래서 언제 무엇을 사용해야합니까?

npm여전히 먼 의미하지만, bower하고 volo나는 사이에 선을 그릴 수 아니다 있지만, 정확히 같은 문제를 해결하는 것 같다 npm하고 bower-volo.



1
이 질문을 읽고 2015 년의 답변을 원한다면 업데이트 된 답변을 참조하십시오.
gustavohenke

답변:


104

npm과 bower의 차이점을 가장 잘 설명하는 설명은 다음과 같습니다. npm은 패키지라는 JavaScript 모듈을 관리하고 Bower는 구성 요소라고하는 프런트 엔드 구성 요소 (예 : css, html 및 JavaScript)를 관리합니다. npm은 bower 설치에도 사용됩니다. 다음은 npm 및 bower (volo를 다루지 않음) 대한 광범위한 기사입니다 .


88
이것은 좋은 설명이 아닙니다. Npm을 사용하여 프런트 엔드 구성 요소를 설치할 수 있습니다.
BT

비록 npm의 일부 "프론트 엔드"라이브러리는 그들의 정자 대응을 위해 포기되었다는 것을 알아 차 렸습니다. 예를 들어 1 년 동안 출판되지 않은 Ember 를 예로 들어 보겠습니다 .
briangonzalez

4
@Nate 이름은 단순히 시작된 위치입니다. NPM은 이제 매우 범용적인 패키지 관리 시스템입니다. 정기적으로 npm을 사용하여 프런트 엔드 모듈을 설치합니다. commonjs 모듈, amd 및 다른 것에는 NPM을 사용하는 데 차이가 없습니다. 자바 스크립트가 아닌 모듈에도 npm을 사용할 수 있습니다. 따라서 이는 단순히 npm과 bower의 차이가 아닙니다. 패키지 또는 구성 요소를 호출하든 모두 임의의 파일 모음이라는 점에서 동일합니다.
BT

2
bower가 html, css 및 javascript를 처리하기위한 정책이 없다는 것을 고려할 때 이것은 오도 된 답변입니다. npm은 npm의 거의 모든 것이 최소한 commonjs 및 때로는 다른 형식을 지원하도록 작성되었다는 것 외에는 정책이 없습니다. bower를 사용하는 것처럼 html과 css를 npm 패키지에 넣을 수 있습니다. npm에는 CSS 및 HTML이 포함 된 패키지를 포함하여 많은 프런트 엔드 전용 패키지가 있습니다.
서브 스택

3
browserify 를 사용하는 경우 npm은 완벽한 패키지 관리자입니다. 어떤 패키지 관리자를 사용하는지는 중요하지 않지만 개인적으로 프로젝트 당 하나만 고수합니다.
Eruant

72

나무 그늘

기능이 거의 없지만 프론트 엔드 개발자들 사이에서 여전히 인기가 있습니다. 모든 프론트 엔드 패키지가이를 사용하고 있습니다. bower를 npm으로 병합 하는 이니셔티브 도 있습니다 .

Bower는 클라이언트 측에 최적화되어 있으며 단순한 종속성 트리 만 지원합니다. 즉, 각 라이브러리는 한 번만 사용해야하며 (같은 라이브러리의 다른 버전을 클라이언트에 제공하는 데 비용이 많이 들기 때문에) 종속성 제약 조건은 사용자가 해결해야합니다. .

bower registry ( bower search <some keyword>) 에서 프론트 엔드와 관련된 것을 찾을 수 있습니다 . 제 생각에는 다른 패키지 관리자와 관련하여 bower의 가장 큰 장점입니다.

볼로

나는 아직도 5 년 이상 그것을 사용하지 않았다. 그것에 대해 모르지만, 내가 볼 수있는 것은 Grunt 사용자에게 매우 친숙한 빌드 도구가 포함되어 있습니다.

npm

예, npm은 Node Package Manager를 나타냅니다. 그러나 요즘에는 모든 것에 사용할 수 있습니다. 사람들은 더 이상 npm install물건을 먹지 않고 노드 환경 에서만 작동하기를 기대합니다 . 예를 들어 Twitter Bootstrap에 대한 많은 npm 패키지가 있습니다.

Npm은 중첩 종속성 트리를 사용하여 서버 측 사용에 최적화되어 있습니다. 각 종속성에는 고유 한 종속성 등이있을 수 있습니다. 각 종속성이 자체 버전의 Underscore를 사용할 수 있기 때문에 종속성 버전 충돌이 제거되었습니다. 그러나 다가오는 npm 버전 3은 종속성 트리를 평평하게합니다 .

npm @ 3을 사용하면 node_modules 디렉토리가 훨씬 더 평평 해집니다. 모든 종속성과 대부분의 하위 종속성 (및 (하위) + 종속성)은 최상위 수준에서 서로 옆에 있습니다. 충돌이있을 때만 더 깊은 수준에서 모듈이 설치됩니다. 이것은 Windows 사용자에게 훨씬 쉬워 질 것입니다.

npm 사용에 대한 몇 가지 장점 :

  • 다른 모든 패키지 관리자 (구성 요소, bower, volo, JSPM 등)에서 사용합니다.
  • 빌드 스크립트를 사용할 수 있습니다.
  • npm 기반 패키지를 검사하는 데 사용할 수있는 많은 도구

npm은 JavaScript의 패키지 관리자입니다.

npmjs.com 스크린 샷


2013 년 2 월 기준으로 제 의견은 다음과 같습니다. 더 이상 고려하지 마십시오.

npm

노드 프로젝트를 사용하는 경우 브라우저에 사용할 수있는 프로젝트가 거의 없습니다 ...

나무 그늘

Bower는 지금 팝 녀석입니다. 그들은 많은 프로젝트를 수행하고 있으며 프로젝트 관리자는 프로젝트를 최신 레지스트리로 유지하는 것을 좋아합니다 ...

그는 때때로 약간 버그가 있다는 것은 부끄러운 일입니다.

볼로

그 이후로 5 분 이상 volo를 시도하지는 않았지만 볼 수있는 것보다 bower보다 유연 해 보입니다.

volo의 단점은 프로젝트가 매우 오래되었다는 것입니다.


19
npm에는 브라우저에서만 작동하거나 노드와 브라우저 모두에서 작동하는 수천 개의 모듈이 있습니다. 그들 중 많은 사람들은 그들이 작동하는 브라우저를 정확하게 알려주는 ci 배지를 가지고 있습니다. bower 등의 모든 것은 아마도 npm에 있습니다.
서브 스택

이미 설치를 위해 npm에 의존하는 동안 ngBoilerplate과 같은 프로젝트가 bower를 사용하는 필요성을 이해하지 못합니다
lolski

5
"팝 가이"는 무엇입니까? "팝"은 abbrev입니다. "인기"?
Bryan Oakley

4
스크린 샷에서 npm은 핵 계획 매뉴얼을 의미합니다.)
Jim Jones

24

그들은 같은 문제를 해결하지만 다른 환경 / 세계에 대해 해결하는 것 같습니다. nodejs 및 volo의 NPM, 브라우저의 bower.

진실은 NPM을 사용하여 브라우저의 자바 스크립트 및 CSS를 관리 할 수 ​​있다는 것입니다. 당신이 그것을 방해하는 것은 없습니다. 그런 의미에서 NPM을 사용하는 것은 동일한 목적을 위해 두 개의 서로 다른 도구를 관리하는 것보다 자연스러운 느낌입니다.

bower는 적어도 더 인기있는 패키지에 대해 더 많은 패키지를 사용할 수있는 것으로 보입니다. 그러나 곧 jQuery를 NPM에서 직접 사용할 수도 있습니다. 다른 모든 라이브러리는 동일한 추세를 따릅니다.

제 생각에는,이 때문에 같은 도구 browserify가webmake 브라우저에서 해당 도움말을 사용 노드 모듈, 거기에 대한 진정한 필요 이상이없는 이물 또는 볼로은 그들이 특정 모듈은 기존 (당신을 위해 뭔가를 제공하지 않는 한, 그들의 레지스트리).

볼로정자 너무 좋다,하지만 당신은 이미 NPM을 사용하는 경우 내 관점에서, 그것은 그것에 충실하는 것이 더있을 수 있습니다.

것을주세요 참고 당신도 browserify 또는 webmake를 사용하지 않고 클라이언트 종속성을 관리하는 NPM을 사용할 수 있습니다 . 내가 작업하고있는 대부분의 프로젝트에서 npm 모듈을 설치 한 후 스크립트를 실행하여 클라이언트 앱이 사용하는 위치에 배포합니다. 때로는 grunt를 사용하여 해당 파일을 다른 js 파일과 연결하고 때로는 웹 응용 프로그램의 템플릿 파일에서 직접 참조합니다. 어쨌든 이것은 개인적인 취향입니다. 다른 사람들은 Bower 또는 Volo가 워크 플로에보다 자연스럽게 맞기 때문에 사용하기가 더 쉽다는 것을 알 수 있습니다.


1
동일한 문제에 대해 경쟁 솔루션을 갖는 것이 좋습니다. yeoman우리가 이미 가지고 있었을 때 프로젝트가 새로운 패키지 관리자를 선택하기로 선택한 이유 는 npm무엇입니까? (성숙하고 유명하며 기능이 풍부했습니다)이 생각은 여전히 ​​실제 포인트가 누락되었다고 생각합니다.
Yugal Jindle

1
실제로는 아니지만, 당신이 말했듯이 바퀴를 재발 명하는 것은 재밌습니다. 왜냐하면 당신이 할 수 있기 때문에 때로는 같은 문제를 해결하는 동안 개선이 이루어졌습니다. 실제로 개발자들이 패키지를 쉽게 찾을 수 있도록하는 것 외에 새로운 것을 선택하는 이유는 아닙니다. 모든 프론트 엔드 개발자에게 노드 경험이있는 것은 아니지만 Bower와 같은 프로젝트의 주된 이유라고 생각합니다. 노드가 아닌 사용자가 쉽게 사용할 수 있도록 노력하십시오.
roy riojas

그들은 npm프론트 엔드 단순성을 위해 번거 로움을 분리하고 싶었던 것 같습니다 . 따라서 프론트 엔드 개발이 필요합니다.
Yugal Jindle

15

Bower의 NPM에 대한 큰 장점은 종속성 관리가 단일 버전의 구성 요소를 사용한다는 것입니다 (NPM은 다른 복사 / 버전을 다른 모듈의 하위 종속성으로 사용함으로써 작동 함). 이것은 매우 좋은 것입니다 다른 버전의 구성 요소의 여러 복사본을 포함해야하므로 클라이언트 측 자바 스크립트가 부풀어 것을 방지하기 때문에 것입니다. 모듈의 여러 복사본을 포함시키는 것은 NPM의 종속성 관리 작동 방식의 핵심이므로 NPM은 전적으로 클라이언트 측 패키지 관리에 적합하지 않습니다.

위의 결과는 바우어 패키지 관리자와 소비자가 충돌을 피하기 위해 종속성 버전 번호를 유지하는 데 더 신경을 써야하지만 지불해야 할 가격입니다. 그리고 NPM 모듈이 주요 릴리스, 부 버전 및 패치 릴리스를 발행 할 때 종종 느슨해 지므로 NPM 종속성 관리도 장미 침대가 아닙니다.


3
패키지 관리자가 해당 파일을 넣은 폴더에서 직접 프론트 엔드 코드를 제공하는 경우에만 해당됩니다. 내 경우에는 less / js 파일을 처리하는 빌드 스크립트가 있거나 해당 파일에서 번들을 작성하기 위해 browserify가 있습니다. 그래서 그것은 실제로 큰 문제가 아닙니다. 배포되는 코드는 개발 중에 다른 하위 구성 요소에 복제본이 있어도 프로덕션에 도달하지 않더라도 항상 올바른 버전을 갖습니다.
roy riojas

부주의로 (종속성으로) 동일한 종속성의 서로 다른 두 가지 버전을 요구하는 경우에도? 나는이 경우에는있는 거 잘못된 생각
wheresrhys

나는 일반적으로 내가 통제하지 않는 모듈을 필요로하지 않으므로 항상 올바른 모듈이 될 것입니다 ... 부주의로 모듈이 shimed 모듈에서 주어진 모듈을 요구하면 빌드가 실패합니다. 내 경우에는 bower를 사용할 필요가 없다. 혜택도 추가되지 않았다
roy riojas

따라서 npm은 전체 종속성 트리를 제어 할 수있는 경우 클라이언트 측 코드에서 모듈이 중복되는 것을 피한다고 안전하게 말할 수 있습니다. 이것은 내가 작업하는 대부분의 경우에는 해당되지 않으며 클라이언트 측 모듈을 포함하기 위해 종속성 관리자를 사용하는 대부분의 프로젝트에는 해당되지 않습니다.
wheresrhys 2016 년

1
매시업을 작업하지 않는 한, 최소한 타사 코드의 경우 종속성 트리가 그렇게 복잡하지 않습니다. 대부분의 js 라이브러리는 단일 전역을 내보내므로 browserify-shim을 사용하면 전역 범위에서 사용할 수 있으므로 항상 제어하는 ​​버전을 사용할 수 있습니다. 내 요점은 이미 가지고있는 패키지 관리자 외에 다른 패키지 관리자가 없어도 동일한 결과를 얻을 수 있다는 것입니다. 결국 그것은 환경 설정 문제 일 수 있습니다. 항상 타협해야합니다.
roy riojas

5

나는 이것이 질문의 범위에 있지 않다는 것을 알고 있지만 또 다른 대안이 있습니다. Jam JS- http ://jamjs.org/ 흥미로운 점은 잼 기능이있다는 것입니다.

jam compile output.js

누군가 다른 패키지 관리자를 만들고 이름을 yapm으로 지정해야합니다. :)


5
당신의 소원이 부여됩니다 github.com/rlidwka/yapm를 : P
알렉스

1
글쎄, 브라우저 측 종속성 관리자를 생각하고 있었지만 둘 다에 대해이 작업을 생각합니다 .p 이것은 스타트 업을 할 수없는 이유입니다.
Bruce Lim

@BruceLim 그래, 우리가 좋은 생각을 할 때마다, 이미 그것을 얻은 다른 사람들이 항상 있습니다.
Evan Hu
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.