자바 스크립트 의존성 관리 : 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.