리뷰나라 - Page 45014 of 45107

[javascript] Bower와 npm의 차이점은 무엇입니까?

JAVASCRIPT / 글쓴이 어드민

사이의 근본적인 차이 무엇 bower과 npm? 평범하고 단순한 것을 원하십시오. 내 동료 사용의 몇 가지 본 적이 bower과 npm자신의 프로젝트에서 상호 교환을.

답변

모든 패키지 관리자는 많은 단점이 있습니다. 당신은 당신이 살 수있는 것을 선택해야합니다.

역사

npm 은 node.js 모듈 관리를 시작했지만 ( node_modules기본적으로 패키지가 들어가는 이유 ) Browserify 또는 webpack 과 결합하면 프론트 엔드에서도 작동합니다 .

Bower 는 프론트 엔드만을 위해 만들어졌으며이를 염두에두고 최적화되었습니다.

저장소의 크기

npm은 범용 JavaScript ( country-data국가 정보 또는 sorts프런트 엔드 또는 백 엔드에서 사용할 수있는 정렬 기능 등)를 포함하여 bower보다 훨씬 큽니다 .

바우어는 훨씬 적은 양의 패키지를 가지고 있습니다.

스타일 처리

Bower는 스타일 등을 포함합니다.

npm은 JavaScript에 중점을두고 있습니다. 스타일은 개별적으로 다운로드하거나 같은 것을 요구하는 npm-sass나 sass-npm.

의존성 처리

가장 큰 차이점은 npm이 중첩 된 종속성을 수행하지만 (기본적으로 고정되어 있음) Bower는 평평한 종속성 트리를 필요로한다는 것입니다 (사용자에 대한 종속성 해결 부담을 가짐) .

중첩 된 종속성 트리는 종속성에 고유 한 종속성 등이있을 수 있음을 의미합니다. 이를 통해 두 모듈이 서로 다른 버전의 동일한 종속성을 요구하고 여전히 작동합니다. npm v3 이후로 종속성 트리는 기본적으로 기본적으로 공간을 절약하고 필요한 경우에만 중첩됩니다 (예 : 두 개의 종속성에 자체 버전의 Underscore가 필요한 경우).

일부 프로젝트는 프론트 엔드 패키지에 Bower를 사용하고 Yeoman, Grunt, Gulp, JSHint, CoffeeScript 등과 같은 개발자 도구에는 npm을 사용한다는 것입니다.

자원

중첩 된 종속성 -node_modules가 작동하는 방식에 대한 통찰력

답변

이 답변은 Sindre Sorhus의 답변에 추가 된 것입니다. npm과 Bower의 주요 차이점은 재귀 종속성을 처리하는 방식입니다. 단일 프로젝트에서 함께 사용할 수 있습니다.

온 NPM 자주 묻는 질문 : (2015 9월 6일에서 archive.org 링크)

중첩 종속성없이 종속성 충돌을 피하는 것이 훨씬 어렵습니다. 이는 npm 작동 방식의 기본이며 매우 성공적인 접근 방식으로 입증되었습니다.

에 바우어의 홈페이지 :

Bower는 프론트 엔드에 최적화되어 있습니다. Bower는 플랫 종속성 트리를 사용하여 각 패키지마다 하나의 버전 만 필요하므로 페이지로드를 최소로 줄입니다.

요컨대, npm은 안정성을 목표로합니다. Bower는 최소한의 리소스로드를 목표로합니다. 의존성 구조를 작성하면 다음과 같이 표시됩니다.

npm :

project root
[node_modules] // default directory for dependencies
 -> dependency A
 -> dependency B
    [node_modules]
    -> dependency A

 -> dependency C
    [node_modules]
    -> dependency B
      [node_modules]
       -> dependency A
    -> dependency D

보시다시피 일부 종속성을 재귀 적으로 설치합니다. 종속성 A에는 세 개의 설치된 인스턴스가 있습니다!

나무 그늘:

project root
[bower_components] // default directory for dependencies
 -> dependency A
 -> dependency B // needs A
 -> dependency C // needs B and D
 -> dependency D

여기에서 모든 고유 한 종속성은 동일한 수준에 있습니다.

그렇다면 왜 npm을 사용합니까?

종속성 B는 종속성 C와 다른 버전의 종속성 A가 필요할 수 있습니다. npm 은이 종속성의 두 버전을 모두 설치하므로 어쨌든 작동하지만 Bower는 중복을 좋아하지 않기 때문에 충돌을 일으킬 것입니다 (웹 페이지에 동일한 리소스를로드하기 때문에 매우 비효율적이며 비용이 많이 들며 심각한 오류가 발생할 수 있습니다). 설치할 버전을 수동으로 선택해야합니다. 이렇게하면 종속성 중 하나가 중단 될 수 있지만 어쨌든 수정해야합니다.

따라서 일반적인 사용법은 웹 페이지에 게시하려는 패키지 (예 : 런타임 , 중복을 피하는 경우)에 대해 Bower 이고 테스트, 빌드, 최적화, 확인 등과 같은 다른 항목 (예 : 개발 시간)에 npm을 사용합니다. 중복이 덜 걱정되는 곳).

npm 3 업데이트 :

npm 3은 여전히 Bower와 다르게 작동합니다. 종속성을 전 세계적으로 설치하지만 첫 번째 버전에서만 발생합니다. 다른 버전은 트리에 설치됩니다 (부모 모듈, node_modules).

[node_modules]
- 뎁 A v1.0
- 뎁 B v1.0
  - ~~뎁 A v1.0~~ (루트 버전 사용)
- 뎁 C v1.0
  - dep v2.0 (이 버전은 루트 버전과 다르므로 중첩 된 설치 임)

자세한 내용 은 npm 3 의 문서를 읽는 것이 좋습니다.

답변

TL; DR : 일상적인 사용에서 가장 큰 차이점은 중첩 된 종속성이 아니라 모듈과 전역의 차이점입니다.

이전 포스터는 기본적인 차이점을 잘 다루었다고 생각합니다. (npm의 중첩 된 종속성 사용은 실제로 가장 중요한 차이점이라고 생각하지 않지만 크고 복잡한 응용 프로그램을 관리하는 데 실제로 도움이됩니다.)

그러나 Bower와 npm의 가장 근본적인 차이점 중 하나를 명시 적으로 설명한 사람은 아무도 없습니다. 위의 답변을 읽으면 ‘pms’라는 단어가 npm의 맥락에서 자주 사용됩니다. 그러나 그것은 심지어 구문 차이 일 수도있는 것처럼 우연히 언급됩니다.

그러나 모듈 대 전역 (또는 모듈 대 ‘스크립트’) 의 이러한 구분은 Bower와 npm의 가장 중요한 차이점 일 수 있습니다.모듈에 모든 것을 넣는 npm 접근 방식을 사용하려면 브라우저의 Javascript 작성 방식을 거의 확실히 개선해야합니다.

Bower 접근법 : `<script>`태그 와 같은 글로벌 리소스

기본적으로 Bower는 일반 스크립트 파일을로드하는 것입니다. 해당 스크립트 파일이 무엇이든 Bower가로드합니다. 기본적으로 어떤 정자는 그냥 평범한 된 모든 스크립트를 포함 같다고 수단 <script>에 ‘이야 <head>당신의 HTML의.

따라서 동일한 기본 접근 방식을 사용하지만 몇 가지 자동화 편의를 얻을 수 있습니다.

예전에는 프로젝트 저장소에 JS 종속성을 포함 시키거나 (개발하는 동안) CDN을 통해 JS 종속성을 가져와야했습니다. 이제 리포지토리에서 추가 다운로드 무게를 건너 뛸 수 있으며, 누군가는 bower install로컬에서 필요한 것을 신속 하고 즉시 얻을 수 있습니다.
Bower 종속성이에 자체 종속성을 지정하면 해당 종속성 bower.json도 다운로드됩니다.

그러나 그 이상으로 Bower는 javascript 작성 방법을 변경하지 않습니다 . Bower가로드 한 파일에 들어가는 내용은 전혀 변경할 필요가 없습니다. 특히 이것은 Bower가로드 한 스크립트에서 제공되는 리소스 가 브라우저 실행 컨텍스트의 어느 곳에서나 사용할 수있는 전역 변수 로 정의 될 수 있음을 의미합니다.

npm 접근 방식 : 공통 JS 모듈, 명시 적 종속성 주입

노드 랜드의 모든 코드 (및 npm을 통해로드 된 모든 코드)는 모듈 (구체적으로 CommonJS 모듈 형식 의 구현 또는 현재 ES6 모듈)로 구성됩니다. 따라서 NPM을 사용하여 브라우저 측 종속성을 처리하는 경우 (Browserify 또는 동일한 작업을 수행하는 다른 작업을 통해) Node와 같은 방식으로 코드를 구성합니다.

내가 왜 똑똑한 사람들이 ‘왜 모듈입니까?’라는 문제를 다루었지만 캡슐 요약은 다음과 같습니다.

모듈 내부의 모든 것은 사실상 네임 스페이스 이므로 더 이상 전역 변수가 아니며 의도하지 않고 실수로 참조 할 수 없습니다.
모듈을 사용하려면 모듈 내부의 모든 것을 특정 컨텍스트 (일반적으로 다른 모듈)에 의도적으로 주입해야합니다.
즉, 응용 프로그램의 여러 부분에서 동일한 외부 종속성 (lodash,하자)의 여러 버전을 가질 수 있으며 충돌 / 충돌하지 않습니다. (자신의 코드가 한 버전의 종속성을 사용하려고하지만 외부 종속성 중 하나가 충돌하는 다른 버전을 지정하기 때문에 놀라 울 정도로 자주 발생합니다. 또는 각각 다른 버전을 원하는 두 개의 외부 종속성이 있습니다.)
모든 종속성은 특정 모듈에 수동으로 주입되기 때문에 추론하기가 매우 쉽습니다. 당신은 사실을 알고 있습니다. “이 작업을 할 때 고려해야 할 유일한 코드는 의도적으로 여기에 주입하기로 선택한 것 입니다. “
주입 된 모듈의 내용도 사용자가 할당 한 변수 뒤에 캡슐화 되고 모든 코드가 제한된 범위 내에서 실행되므로 놀라움과 충돌이 매우 불가능합니다. 의존성 중 하나에서 무언가가 실수로 전역 변수를 재정의하지 않고 실수로 재정의하거나 그렇게 할 가능성은 훨씬 적습니다. (이 수 일이 있지만, 일반적으로 같은과, 그것을 할 수있는 길 밖으로 갈 필요 window.variable. 즉, 여전히 할당되어 발생하는 경향이 한 사고 this.variable즉 실현하지, this실제로 window현재 컨텍스트에 있습니다.)
개별 모듈을 테스트하려는 경우 모듈 내부에서 실행되는 코드에 정확히 어떤 다른 요소 (종속성)가 영향을 미치는지 쉽게 알 수 있습니다. 또한 모든 것을 명시 적으로 주입하기 때문에 이러한 종속성을 쉽게 조롱 할 수 있습니다.

프론트 엔드 코드를위한 모듈의 사용은 다음과 같이 요약됩니다.보다 좁은 컨텍스트에서 작업하고 추론하고 테스트하기가 더 쉬워지고, 무슨 일이 일어나고 있는지 확실하게 알 수 있습니다.

CommonJS / Node 모듈 구문을 사용하는 방법을 배우는 데 약 30 초가 걸립니다. 모듈이 될 주어진 JS 파일 내에서 먼저 다음과 같이 사용하려는 외부 종속성을 선언하십시오.

var React = require('react');

파일 / 모듈 내에서 평소와 같이 무엇이든하고 외부 사용자에게 노출시키고 자하는 객체 나 함수를 생성합니다. myModule 있습니다.

파일 끝에서 다음과 같이 세상과 공유하려는 모든 것을 내 보냅니다.

module.exports = myModule;

그런 다음 브라우저에서 CommonJS 기반 워크 플로우를 사용하려면 Browserify와 같은 도구를 사용하여 모든 개별 모듈 파일을 가져 와서 런타임에 컨텐츠를 캡슐화하고 필요에 따라 서로 삽입하십시오.

그리고 ES6 모듈 (Babel 또는 이와 유사한 것으로 ES5로 변환 될 가능성이 높음)이 널리 수용되고 있으며 브라우저 또는 노드 4.0에서 모두 작동하므로 좋은 개요를 언급해야합니다. 를 합니다.

이 데크 에서 모듈로 작업하기위한 패턴에 대해 자세히 알아보십시오 .

편집 (2017 년 2 월) : Facebook의 Yarn 은 요즘 npm을위한 매우 중요한 잠재적 교체 / 보충입니다. npm이 제공하는 것을 기반으로하는 빠르고 결정적인 오프라인 패키지 관리입니다. JS 프로젝트를 살펴볼 가치가 있습니다. 특히 프로젝트를 쉽게 교체 할 수 있기 때문입니다.

EDIT (2019 년 5 월) “Bower는 더 이상 사용되지 않습니다 . 스토리 끝.” (h / t : @DanDascalescu, 아래에 정리 요약이 나와 있습니다.)

그리고 Yarn 이 여전히 활성화되어 있지만 Yarn의 주요 기능 중 일부를 채택하면 많은 모멘텀이 npm으로 돌아갔습니다.

답변

2017 년 10 월 업데이트

Bower는 마침내 더 이상 사용되지 않습니다. . 이야기의 끝.

이전 답변

Spotify의 JavaScript 개발자 인 Mattias Petter Johansson의 의견 :

거의 모든 경우에 Bower보다 Browserify 및 npm을 사용하는 것이 더 적합합니다. Bower보다 프론트 엔드 앱을위한 더 나은 패키징 솔루션입니다. Spotify에서는 npm을 사용하여 전체 웹 모듈 (html, css, js)을 패키징하고 매우 잘 작동합니다.

Bower는 자체적으로 웹 패키지 관리자로 브랜드화합니다. 이것이 사실이라면 정말 좋을 것입니다. 프론트 엔드 개발자로서 제 인생을 더 좋게 만든 패키지 관리자는 정말 좋을 것입니다. 문제는 Bower가 목적에 맞는 특수 공구를 제공하지 않는다는 것입니다. 그것은 npm이 알지 못하는 툴링을 제공하지 않으며 특히 프론트 엔드 개발자에게 특히 유용한 툴은 없습니다.프론트 엔드 개발자가 npm 이상 Bower를 사용하면 아무런 이점이 없습니다.

우리는 bower 사용을 중단하고 npm 주위에 강화해야합니다. 고맙게도, 그 일 이 일어나고 있습니다 :

browserify 또는 webpack을 사용하면 모든 모듈을 큰 축소 파일로 연결하는 것이 매우 쉬워 져 성능, 특히 모바일 장치에 적합합니다. 같은 효과를 얻으려면 훨씬 더 많은 노력이 필요합니다.

npm은 또한 여러 버전의 모듈을 동시에 사용할 수있는 기능을 제공합니다. 많은 응용 프로그램 개발을 수행하지 않은 경우 처음에는 나쁜 일이 될 수 있지만 일단 의존성 문제 를 겪고 나면 한 모듈의 여러 버전을 가질 수있는 능력이 꽤 있다는 것을 알게 될 것입니다. 훌륭한 기능. NPM이 매우 편리한 포함 참고 중복 제거 도구를 자동으로 당신이 실제로있는 경우에만 모듈의 두 가지 버전을 사용할 수 있는지 확인합니다 것을 이 두 모듈이 모두있는 경우 -에 있습니다 , 그들은 것 하나 개의 모듈의 동일한 버전을 사용하십시오. 그러나 그들이 할 수 없다면 매우 유용합니다.

(참고 웹팩 와 롤업 널리 8월 2016 년 기준으로 더 나은 Browserify 이상으로 간주된다)

답변

Bower는 단일 버전의 모듈을 유지 관리하며 올바른 / 최적의 모듈을 선택하도록 도와줍니다.

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

모듈 시스템이 있고 로컬에서 작업하기 때문에 NPM이 노드 모듈에 더 좋습니다. Bower는 현재 글로벌 범위 만 있고 작업중인 버전에 대해 매우 선택 적이기 때문에 브라우저에 적합합니다.

답변

우리 팀은 Bower를 떠나 다음과 같은 이유로 npm으로 마이그레이션했습니다.

프로그래밍 방식의 사용법이 힘들었습니다.
바우어의 인터페이스는 계속 바뀌었다
url 속기와 같은 일부 기능은 완전히 손상되었습니다.
같은 프로젝트에서 Bower와 npm을 모두 사용하는 것은 고통 스럽습니다.
bower.json 버전 필드를 git 태그와 동기화하는 것은 고통 스럽습니다.
소스 제어! = 패키지 관리
CommonJS 지원은 간단하지 않습니다

자세한 내용은 “팀에서 bower 대신 npm을 사용하는 이유”를 참조하십시오 .

답변

이 유용한 설명은 http://ng-learn.org/2013/11/Bower-vs-npm/ 에서 발견되었습니다.

한편으로 npm은 node.js 환경에서 사용되는 모듈 또는 Karma, lint, minifiers 등과 같은 node.js를 사용하여 개발 된 개발 도구를 설치하기 위해 만들어졌습니다. npm은 프로젝트에서 로컬로 (기본적으로 node_modules) 모듈을 설치하거나 전역 적으로 여러 프로젝트에서 사용할 수 있습니다. 대규모 프로젝트에서 종속성을 지정하는 방법은 종속성 목록이 포함 된 package.json이라는 파일을 작성하는 것입니다. 이 목록은 npm install을 실행할 때 npm에 의해 인식되며이를 다운로드하여 설치합니다.

한편, bower는 프론트 엔드 종속성을 관리하기 위해 작성되었습니다. jQuery, AngularJS, 밑줄 등과 같은 라이브러리. npm과 유사하게 bower.json이라는 종속성 목록을 지정할 수있는 파일이 있습니다. 이 경우 프론트 엔드 종속성은 bower install을 실행하여 설치되며 기본적으로 bower_components라는 폴더에 설치됩니다.

보시다시피, 비슷한 작업을 수행하지만 매우 다른 라이브러리 세트를 대상으로합니다.

답변

역사