bower 와 npm 의 근본적인 차이점은 무엇입니까? 단순하고 단순한 것을 원합니다. 동료 중 일부가 프로젝트에서 bower 와 npm
반응형
질문자 :Games Brainiac
모든 패키지 관리자에는 많은 단점이 있습니다. 당신은 당신이 살 수있는 것을 선택해야합니다.
역사
npm 은 node.js 모듈 관리를 시작했지만(패키지 node_modules 에 들어가는 이유입니다) Browserify 또는 webpack 과 결합하면 프런트 엔드에서도 작동합니다.
Bower 는 프론트 엔드 전용으로 만들어졌으며 이를 염두에 두고 최적화되어 있습니다.
리포지토리의 크기
NPM은 범용 자바 스크립트를 포함하여 정자보다 훨씬, 훨씬 더 큰 것이다 (같은 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
이 답변은 Sindre Sorhus의 답변에 추가되었습니다. npm과 Bower의 주요 차이점은 재귀 종속성을 처리하는 방식입니다. 단일 프로젝트에서 함께 사용할 수 있습니다.
npm FAQ : (2015년 9월 6일부터 archive.org 링크)
종속성을 중첩하지 않고 종속성 충돌을 피하는 것이 훨씬 더 어렵습니다. 이것은 npm이 작동하는 방식의 기본이며 매우 성공적인 접근 방식으로 입증되었습니다.
Bower 홈페이지:
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는 복제를 좋아하지 않기 때문에 충돌 을 줄 것입니다(웹 페이지에서 동일한 리소스를 로드하는 것은 매우 비효율적이고 비용이 많이 들며 심각한 오류가 발생할 수 있음). 설치할 버전을 수동으로 선택해야 합니다. 이것은 종속성 중 하나가 중단되는 효과를 가질 수 있지만 어쨌든 수정해야 하는 것입니다.
따라서 일반적인 사용법은 웹 페이지에 게시하려는 패키지(예: 런타임 , 중복을 피하는 패키지)에 사용하고 npm을 테스트, 빌드, 최적화, 확인 등과 같은 다른 작업에 사용합니다(예: 개발 시간 , 중복이 덜 우려되는 경우).
npm 3 업데이트:
npm 3은 여전히 Bower와 다르게 작동합니다. 종속성을 전역적으로 설치하지만 처음 만나는 버전에만 적용됩니다. 다른 버전은 트리(부모 모듈, node_modules)에 설치됩니다.
- [노드_모듈]
- 뎁 A v1.0
- 뎁 B v1.0
뎁 A v1.0(루트 버전 사용)
- 데프 C v1.0
- dep A v2.0(이 버전은 루트 버전과 다르므로 중첩 설치가 됩니다)
자세한 내용은 npm 3 문서를 읽는 것이 좋습니다.
Justus Romijn
TL;DR: 일상적인 사용의 가장 큰 차이점은 중첩된 종속성이 아니라 모듈과 전역의 차이입니다.
나는 이전 포스터가 기본적인 구분의 일부를 잘 다루었다고 생각합니다. (npm의 중첩 종속성 사용은 실제로 크고 복잡한 응용 프로그램을 관리하는 데 매우 유용하지만 이것이 가장 중요한 차이점은 아니라고 생각합니다.)
그러나 아무도 Bower와 npm 사이의 가장 근본적인 차이점 중 하나를 명시적으로 설명하지 않았다는 사실에 놀랐습니다. 위의 답변을 읽으면 npm과 관련하여 자주 사용되는 '모듈'이라는 단어를 볼 수 있습니다. 그러나 그것은 마치 단지 구문의 차이인 것처럼 아무렇지도 않게 언급됩니다.
그러나 모듈 대 전역 (또는 모듈 대 '스크립트')의 이러한 구분은 아마도 Bower와 npm의 가장 중요한 차이점일 것입니다. 모든 것을 모듈에 넣는 npm 접근 방식을 사용하려면 브라우저용 Javascript 작성 방식을 변경해야 합니다.
<script> 태그와 같은 글로벌 리소스
루트에서 Bower는 평범한 스크립트 파일을 로드하는 것입니다. 이러한 스크립트 파일에 무엇이 포함되어 있든 Bower는 이를 로드합니다. 이는 기본적으로 Bower가 HTML의 <head> <script> 의 모든 스크립트를 포함하는 것과 같다는 것을 의미합니다.
따라서 기존과 동일한 기본 접근 방식을 사용하지만 몇 가지 멋진 자동화 편의를 얻을 수 있습니다.
- (개발하는 동안) 프로젝트 리포지토리에 JS 종속성을 포함하거나 CDN을 통해 가져와야 했습니다. 이제 리포지토리에서 추가 다운로드 무게를 건너뛸 수 있으며 누군가가 빠른
bower install하고 로컬에서 필요한 것을 즉시 얻을 수 있습니다. -
bower.json자체 종속성을 지정하면 해당 종속성도 다운로드됩니다.
그러나 그 이상으로 Bower는 javascript를 작성하는 방법을 변경하지 않습니다 . Bower에 의해 로드된 파일 내부에 들어가는 내용은 전혀 변경할 필요가 없습니다. 특히, 이것은 Bower에 의해 로드된 스크립트에서 제공되는 리소스가 (항상 그런 것은 아니지만 일반적으로) 여전히 전역 변수 로 정의되어 브라우저 실행 컨텍스트의 어느 곳에서나 사용할 수 있음을 의미합니다.
npm 접근 방식: 공통 JS 모듈, 명시적 종속성 주입
노드 랜드의 모든 코드(따라서 npm을 통해 로드되는 모든 코드)는 모듈로 구성됩니다(특히, CommonJS 모듈 형식 의 구현 또는 현재 ES6 모듈로). 따라서 NPM을 사용하여 브라우저 측 종속성을 처리하는 경우(Browserify 또는 동일한 작업을 수행하는 다른 것을 통해) Node.js와 동일한 방식으로 코드를 구성하게 됩니다.
나보다 똑똑한 사람들은 '왜 모듈을 사용하는가?'라는 질문을 다루었지만 다음은 캡슐 요약입니다.
- 모듈 내부의 모든 항목은 효과적으로 네임스페이스 가 지정되어 더 이상 전역 변수가 아니며 의도하지 않고 실수로 참조할 수 없습니다.
- 모듈 내부의 모든 것을 사용하려면 특정 컨텍스트(일반적으로 다른 모듈)에 의도적으로 주입해야 합니다.
- 즉, 애플리케이션의 다양한 부분에 동일한 외부 종속성(lodash, 가령)의 여러 버전이 있을 수 있으며 충돌/충돌하지 않습니다. (자신의 코드가 한 버전의 종속성을 사용하기를 원하지만 외부 종속성 중 하나가 충돌하는 다른 버전을 지정하기 때문에 이는 놀랍게도 자주 발생합니다. 또는 각각 다른 버전을 원하는 두 개의 외부 종속성이 있습니다.)
- 모든 종속성은 특정 모듈에 수동으로 주입되기 때문에 추론하기가 매우 쉽습니다. 당신은 사실을 알고 있습니다: "이 작업을 할 때 고려해야 할 유일한 코드는 내가 의도적으로 여기에 삽입하기로 선택한 것 입니다." .
- 주입된 모듈의 내용도 할당한 변수 뒤에 캡슐화 되고 모든 코드가 제한된 범위 내에서 실행되기 때문에 놀라움과 충돌이 거의 발생하지 않습니다. 의존성 중 하나의 무언가가 당신이 깨닫지 못한 채 실수로 전역 변수를 재정의하거나 그렇게 할 가능성은 훨씬 적습니다. ( 일어날 수
window.variable과 같은 방법으로 수행해야 합니다. 여전히 발생하는 경향이 있는 한 가지 사고는this.variablethis현재의 실제window이라는 것을 깨닫지 못하고 문맥.) - 개별 모듈을 테스트하려는 경우 매우 쉽게 알 수 있습니다. 모듈 내부에서 실행되는 코드에 영향을 미치는 다른 항목(종속성)이 정확히 무엇입니까? 그리고 모든 것을 명시적으로 주입하기 때문에 이러한 종속성을 쉽게 조롱할 수 있습니다.
나에게 프론트 엔드 코드에 모듈을 사용하는 것은 추론하고 테스트하기 쉬운 훨씬 더 좁은 컨텍스트에서 작업하고 진행 상황에 대해 더 큰 확신을 갖는 것으로 요약됩니다.
CommonJS/Node 모듈 구문을 사용하는 방법을 배우는 데 약 30초 밖에 걸리지 않습니다. 모듈이 될 주어진 JS 파일 내에서 먼저 다음과 같이 사용하려는 외부 종속성을 선언합니다.
var React = require('react');
파일/모듈 내부에서 평소 하던 대로 하고 외부 사용자에게 노출하려는 일부 개체 또는 함수를 생성하여 아마도 myModule 이라고 부릅니다.
파일 끝에서 다음과 같이 전 세계와 공유하고 싶은 모든 것을 내보냅니다.
module.exports = myModule;
그런 다음 브라우저에서 CommonJS 기반 워크플로를 사용하려면 Browserify와 같은 도구를 사용하여 모든 개별 모듈 파일을 가져와 런타임에 콘텐츠를 캡슐화하고 필요에 따라 서로 삽입합니다.
그리고 ES6 모듈(Babel 또는 이와 유사한 것을 사용하여 ES5로 변환할 가능성이 높음)이 널리 수용되고 있고 브라우저나 Node 4.0에서 모두 작동하기 때문에 이에 대한 좋은 개요도 언급해야 합니다.
이 데크 에서 모듈 작업을 위한 패턴에 대해 자세히 알아보세요.
편집(2017년 2월): Facebook의 Yarn 은 요즘 npm의 매우 중요한 잠재적 대체/보충입니다. npm이 제공하는 것을 기반으로 하는 빠르고 결정적이며 오프라인 패키지 관리입니다. 모든 JS 프로젝트를 살펴볼 가치가 있습니다. 특히 인/아웃을 교체하기가 매우 쉽기 때문입니다.
편집(2019년 5월) "Bower는 마침내 더 이상 사용되지 않습니다 . 이야기 끝." (h/t: @DanDascalescu, 아래, 간결한 요약)
그리고 Yarn이 여전히 활성 상태인 동안 Yarn의 주요 기능 중 일부를 채택한 이후에는 많은 모멘텀이 npm으로 돌아갔습니다.
XML
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을 사용하면 모든 모듈을 매우 쉽게 축소된 큰 파일로 연결할 수 있으며, 이는 특히 모바일 장치의 경우 성능이 매우 뛰어납니다. Bower는 그렇지 않습니다. 동일한 효과를 얻으려면 훨씬 더 많은 노력이 필요합니다.
npm은 또한 여러 버전의 모듈을 동시에 사용할 수 있는 기능을 제공합니다. 응용 프로그램 개발을 많이 하지 않았다면 처음에는 좋지 않은 일이라고 생각할 수 있지만, 종속성 지옥 을 몇 번 경험해 보면 한 모듈의 여러 버전을 가질 수 있는 능력이 있다는 것이 정말 끔찍하다는 것을 깨닫게 될 것입니다. 훌륭한 기능. NPM이 매우 편리한 포함 참고 중복 제거 도구를 두 모듈 모두, 그들은 것 하나 개의 모듈의 동일한 버전을 사용할 수있는 경우 - 자동 사실에있는 경우에만 모듈의 두 가지 버전을 사용할 수 있는지 확인합니다 것을. 그러나 그들이 할 수 없다면 당신은 매우 편리합니다.
(참고 로 2016년 8월 현재 Webpack 과 롤업 은 Browserify보다 낫다는 평가가 널리 퍼져 있습니다.)
Dan Dascalescu
Bower는 단일 버전의 모듈을 유지 관리하며 귀하에게 올바른/최상의 모듈을 선택하는 데 도움이 될 뿐입니다.
NPM은 모듈 시스템이 있고 로컬에서 작업하기 때문에 노드 모듈에 더 좋습니다. Bower는 현재 전역 범위만 있고 작업하는 버전에 대해 매우 선택적이고 싶기 때문에 브라우저에 좋습니다.
Sagivf
우리 팀은 다음과 같은 이유로 Bower에서 npm으로 마이그레이션했습니다.
- 프로그래밍 방식의 사용은 고통스러웠습니다.
- Bower의 인터페이스가 계속 변경됨
- URL 약식과 같은 일부 기능은 완전히 손상되었습니다.
- 동일한 프로젝트에서 Bower와 npm을 모두 사용하는 것은 고통스럽습니다.
- git 태그와 동기화된 bower.json 버전 필드를 유지하는 것은 고통스럽습니다.
- 소스 제어 != 패키지 관리
- CommonJS 지원은 간단하지 않습니다.
자세한 내용은 "내 팀이 bower 대신 npm을 사용하는 이유"를 참조하세요.
Nick Heiner
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_components라는 폴더에 설치되는 bower install을 실행하여 설치됩니다.
보시다시피 비슷한 작업을 수행하지만 매우 다른 라이브러리 집합을 대상으로 합니다.
Henry Neo
node.js로 작업하는 많은 사람들에게 bower의 주요 이점은 자바스크립트가 아닌 종속성을 관리하는 것입니다. 자바스크립트로 컴파일되는 언어로 작업하는 경우 npm을 사용하여 일부 종속성을 관리할 수 있습니다. 그러나 모든 종속성이 node.js 모듈이 되는 것은 아닙니다. 자바 스크립트로 컴파일하는 것들 중 일부는 사용자가 소스 코드를 기대하고 있을 때 자바 스크립트로 컴파일된 파일을 전달하는 것을 부적절한 옵션으로 만드는 이상한 소스 언어 특정 맹글링을 가질 수 있습니다.
npm 패키지의 모든 것이 사용자 대면 자바스크립트일 필요는 없지만 npm 라이브러리 패키지의 경우 적어도 일부는 있어야 합니다.
jessopher
출처 : http:www.stackoverflow.com/questions/18641899/what-is-the-difference-between-bower-and-npm
반응형
'etc. > StackOverFlow' 카테고리의 다른 글
| 모바일 장치를 감지하는 가장 좋은 방법은 무엇입니까? (0) | 2021.12.28 |
|---|---|
| 하위 디렉토리를 별도의 Git 저장소로 분리(이동) (0) | 2021.12.28 |
| JavaScript에서 'new' 키워드는 무엇입니까? (0) | 2021.12.28 |
| 현재 Git 브랜치를 마스터 브랜치로 만들기 (0) | 2021.12.28 |
| 모든 Git 브랜치를 가져오는 방법 (0) | 2021.12.28 |