Quản lý phụ thuộc JavaScript: npm so với bower so với volo [đã đóng]


160

Làm thế nào để bạn so sánh npm, bowervolo?

Tất cả ba có thể được sử dụng để cài đặt các phụ thuộc JavaScript cho một dự án UI. Tôi hiểu npmlà nút cụ thể hơn.

Vậy, khi nào nên dùng gì?

npmvẫn đứng ở xa, nhưng bowervolodường như được giải quyết một cách chính xác cùng một vấn đề, mặc dù tôi không thể để vẽ một ranh giới giữa npmbower-volo.



1
Nếu bạn đang đọc câu hỏi này và muốn có câu trả lời từ năm 2015, hãy xem câu trả lời được cập nhật của tôi.
gustavohenke

Câu trả lời:


104

Một mô tả mô tả đúng nhất sự khác biệt giữa npm và bower là: npm quản lý các mô-đun JavaScript được gọi là các gói và Bower quản lý các thành phần giao diện người dùng (ví dụ: css, html và JavaScript) được gọi là các thành phần. npm cũng được sử dụng để cài đặt bower. Đây là một bài viết mở rộng về npm và bower (không bao gồm volo) nó đi sâu vào nhiều chi tiết.


88
Đây không phải là một mô tả rất tốt. Npm chắc chắn có thể được sử dụng để cài đặt các thành phần front-end.
BT

Mặc dù tôi đã nhận thấy một số thư viện "frontend" trên npm trở nên bị bỏ rơi có lợi cho các đối tác của họ. Lấy ví dụ Ember , đã không được xuất bản trong một năm.
briangonzalez

4
@Nate Tên chỉ đơn giản là nơi nó bắt đầu. NPM bây giờ là một hệ thống quản lý gói mục đích rất chung. Tôi thường xuyên sử dụng npm để cài đặt các mô-đun front-end. Không có sự khác biệt trong việc sử dụng NPM cho các mô-đun commonjs, so với amd, so với bất kỳ thứ gì khác. Bạn cũng có thể sử dụng npm cho các mô-đun không javascript. Do đó, đó đơn giản không phải là sự khác biệt giữa npm và bower. Cho dù bạn gọi chúng là các gói hoặc thành phần, chúng đều giống nhau ở chỗ chúng đều là tập hợp các tệp tùy ý.
BT

2
Đây là một câu trả lời rất sai lầm khi xem xét bower không có chính sách để xử lý html, css và javascript. npm không có chính sách nào ngoại trừ hầu hết mọi thứ trên npm được viết để ít nhất hỗ trợ các định dạng chung và đôi khi các định dạng khác. Bạn có thể đặt html và css trong các gói npm giống như bạn có thể với bower. Có nhiều gói chỉ có frontend trên npm, bao gồm các gói bao gồm css và html.
trạm biến áp

3
Nếu bạn đang sử dụng browserify , npm là trình quản lý gói hoàn hảo. Tôi không nghĩ vấn đề bạn sử dụng trình quản lý gói nào, nhưng cá nhân tôi sẽ chỉ sử dụng một cho mỗi dự án.
Bỏ trốn

72

bower

Nó vẫn rất phổ biến trong số các nhà phát triển front-end, mặc dù nó có rất ít tính năng. Mỗi gói front-end đang sử dụng nó. Ngoài ra còn có một sáng kiến ​​để hợp nhất bower vào npm .

Bower được tối ưu hóa cho phía máy khách và chỉ hỗ trợ các cây phụ thuộc phẳng, tức là mỗi thư viện chỉ được sử dụng một lần (vì tốn kém để chuyển các phiên bản khác nhau của cùng một thư viện cho khách hàng) và người dùng phải giải quyết các ràng buộc phụ thuộc .

Bạn có thể mong đợi tìm thấy bất cứ thứ gì có liên quan đến giao diện người dùng trong sổ đăng ký Bower ( bower search <some keyword>) - theo tôi, đó là lợi thế lớn nhất của Bower so với các trình quản lý gói khác.

tập

Tôi vẫn chưa sử dụng nó hơn 5 phút trong nhiều năm. Không biết về nó, nhưng từ những gì tôi có thể thấy nó bao gồm một số công cụ xây dựng, rất quen thuộc với người dùng Grunt.

chiều

Có, npm là viết tắt của Node Gói Manager. Nhưng ngày nay bạn có thể sử dụng nó cho mọi thứ; mọi người không còn chỉ làm npm installmọi thứ và mong đợi chúng chỉ hoạt động trong môi trường Node. Ví dụ: có nhiều gói npm cho Twitter Bootstrap .

Npm được tối ưu hóa cho việc sử dụng phía máy chủ, với cây phụ thuộc lồng nhau. Mỗi phụ thuộc có thể có phụ thuộc riêng có thể có phụ thuộc riêng, v.v. Điều này đã loại bỏ xung đột phiên bản phụ thuộc vì mỗi phụ thuộc có thể sử dụng phiên bản riêng của họ, ví dụ như Underscore. Tuy nhiên, phiên bản npm 3 sắp tới sẽ san phẳng cây phụ thuộc :

Với npm @ 3, thư mục node_modules của bạn sẽ phẳng hơn rất nhiều. Tất cả các phụ thuộc của bạn và hầu hết các phụ thuộc của bạn (và (phụ) + phụ thuộc) sẽ ngồi cạnh nhau ở cấp cao nhất. Chỉ khi có xung đột, các mô-đun sẽ được cài đặt ở cấp độ sâu hơn. Điều này sẽ làm mọi thứ dễ dàng hơn nhiều cho người dùng Windows.

Một số ưu điểm tôi thấy khi sử dụng npm:

  • Nó được sử dụng bởi tất cả các trình quản lý gói khác (thành phần, bower, volo, JSPM, v.v.);
  • Cho phép sử dụng các tập lệnh xây dựng;
  • Rất nhiều công cụ có sẵn để xem xét các gói dựa trên npm

npm là trình quản lý gói cho JavaScript.

ảnh chụp màn hình npmjs.com


Tính đến tháng hai năm 2013, ý kiến ​​của tôi là như sau. Xin đừng đưa nó vào tài khoản nữa.

chiều

Tốt hơn là nên gắn bó với nó khi bạn tham gia dự án Node, có rất ít dự án có sẵn cho trình duyệt ...

bower

Bower là anh chàng nhạc pop ngay bây giờ. Họ có rất nhiều dự án dưới sự bảo trợ của họ, và những người duy trì dự án muốn giữ cho họ cập nhật trong sổ đăng ký ...

Thật xấu hổ vì đôi khi anh ấy có một chút lỗi.

tập

Tôi đã không thử volo trong hơn 5 phút kể từ đó, nhưng từ những gì tôi có thể thấy nó có vẻ linh hoạt hơn so với bower.

Một điểm tiêu cực cho volo là các dự án của họ rất lỗi thời.


19
Có hàng ngàn mô-đun trên npm chỉ hoạt động trong trình duyệt hoặc hoạt động ở cả nút và trong trình duyệt. Nhiều người trong số họ thậm chí còn có huy hiệu ci cho bạn biết chính xác trình duyệt nào họ làm việc. Hầu hết mọi thứ trên bower et đều có thể là vào npm.
trạm biến áp

Tôi không hiểu nhu cầu của dự án như ngBoilerplate để sử dụng Bower trong khi nó phụ thuộc vào npm để cài đặt
lolski

5
Một "anh chàng nhạc pop" là gì? Là "pop" một từ viết tắt. cho "phổ biến"?
Bryan Oakley

4
Trong ảnh chụp màn hình của bạn, npm là viết tắt của sổ tay kế hoạch hạt nhân;)
Jim Jones

24

Họ dường như đang giải quyết cùng một vấn đề nhưng đối với các môi trường / thế giới khác nhau. NPM cho nodejs và volo, bower cho trình duyệt.

Sự thật là bạn cũng có thể sử dụng NPM để quản lý javascript và css cho trình duyệt. Không có gì ngăn cản bạn làm điều đó. Theo nghĩa đó, việc sử dụng NPM mang lại cảm giác tự nhiên hơn cho tôi so với việc phải quản lý hai công cụ khác nhau cho cùng một mục đích.

Dường như Bower có nhiều gói hơn, ít nhất là cho những gói phổ biến hơn. Nhưng sắp tới jQuery cũng sẽ có sẵn trong NPM và có lẽ tất cả các thư viện khác cũng sẽ theo xu hướng tương tự.

Theo ý kiến của tôi, kể từ khi có các công cụ như browserifywebmake trên mạng, mà module giúp đỡ sử dụng nút trong trình duyệt, có không còn là một nhu cầu thực sự cho Chòi chơi hoặc Volo , trừ khi họ cung cấp một cái gì đó khác cho bạn (một module cụ thể đang tồn tại duy nhất ở đăng ký của họ).

Cả VoloBower đều tốt, nhưng theo quan điểm của tôi, nếu bạn đã sử dụng NPM, có lẽ tốt hơn là nên sử dụng nó.

Xin lưu ý rằng bạn có thể sử dụng NPM để quản lý các phụ thuộc máy khách của mình ngay cả khi không sử dụng browserify hoặc webmake . Trong hầu hết các dự án tôi đang thực hiện, sau khi các mô-đun npm được cài đặt, tôi chạy một kịch bản để triển khai chúng đến vị trí mà ứng dụng khách của tôi sử dụng chúng. Đôi khi tôi sử dụng grunt để ghép tệp đó với các tệp js khác và đôi khi tôi tham chiếu nó trực tiếp từ các tệp mẫu của ứng dụng web của mình. Trong mọi trường hợp, đây là một sở thích cá nhân. Những người khác có thể thấy Bower hoặc Volo dễ sử dụng hơn vì chúng phù hợp tự nhiên hơn trong quy trình làm việc của họ.


1
Thật tốt khi có các giải pháp cạnh tranh cho cùng một vấn đề. Có ai biết tại sao yeomandự án lại chọn một trình quản lý gói mới khi chúng ta đã có npmkhông? (Đó là sự trưởng thành, nổi tiếng và giàu tính năng) Suy nghĩ này khiến tôi cảm thấy mình vẫn còn thiếu điểm thực tế.
Joly Julum

1
Không thực sự, nhưng như bạn đã nói đôi khi thật buồn cười khi phát minh lại bánh xe, chỉ vì bạn có thể, và đôi khi bằng cách thực hiện nó, một số cải tiến được thực hiện trong khi cố gắng giải quyết vấn đề tương tự. Không thực sự lý do tại sao họ chọn tạo một cái mới, ngoài việc làm cho các nhà phát triển dễ dàng hơn trong việc tìm kiếm các gói. Không phải tất cả các nhà phát triển frontend đều có kinh nghiệm về nút, tôi đoán đó là lý do chính đằng sau các dự án như Bower. Cố gắng làm cho người dùng không phải nút dễ dàng hơn, tôi chỉ đoán ở đây.
royjas

Tôi đoán họ muốn tách biệt những rắc rối có npmlợi cho sự đơn giản của frontend. Do đó để phát triển frontend.
Joly Julum

15

Ưu điểm lớn của Bower so với NPM là quản lý phụ thuộc của nó thực thi bằng cách sử dụng một phiên bản duy nhất của một thành phần (trong khi NPM hoạt động bằng cách có các bản sao / phiên bản khác nhau làm phụ thuộc của các mô-đun khác nhau). Đây là một điều RẤT TỐT vì nó ngăn javascript phía máy khách của bạn trở nên cồng kềnh thông qua việc cần bao gồm nhiều bản sao của một thành phần ở các phiên bản khác nhau. Bao gồm nhiều bản sao của một mô-đun là trọng tâm trong cách quản lý phụ thuộc của NPM hoạt động và do đó NPM hoàn toàn không phù hợp với quản lý gói phía khách hàng.

Một hậu quả của những điều trên là các nhà bảo trì và người tiêu dùng gói bower phải thận trọng hơn trong việc duy trì số phiên bản phụ thuộc của họ để tránh xung đột, nhưng đó là một cái giá phải trả. Và tôi thấy các mô-đun NPM thường cẩu thả trong việc phát hành các bản phát hành chính, phụ và bản vá để quản lý phụ thuộc NPM cũng không chính xác là một bông hồng.


3
Điều này chỉ đúng nếu bạn đang phục vụ mã frontend của mình trực tiếp từ thư mục mà trình quản lý gói đưa các tệp đó vào. Trong trường hợp của tôi, tôi có tập lệnh xây dựng để xử lý các tệp less / js hoặc trình duyệt để tạo một gói từ các tệp đó. Vì vậy, đó không thực sự là một vấn đề lớn trong trường hợp của tôi. Mã được phân phối luôn có các phiên bản phù hợp, ngay cả khi các thành phần con khác có thể có các bản sao trong quá trình phát triển, chúng không bao giờ được đưa vào sản xuất.
royjas

ngay cả khi bạn vô tình yêu cầu (như phụ thuộc) hai phiên bản khác nhau của cùng một phụ thuộc? Tôi nghĩ trong trường hợp này bạn đã sai
từ

Tôi thường không yêu cầu các mô-đun mà tôi không kiểm soát, vì vậy chúng sẽ luôn là các mô-đun phù hợp ... nếu vô tình một mô-đun cố gắng yêu cầu một mô-đun nhất định trong số các mô-đun bị lung lay thì quá trình xây dựng sẽ thất bại. Không có điểm nào trong việc sử dụng Bower trong trường hợp của tôi, không có lợi ích nào được thêm vào
roy riojas

Vì vậy, npm chỉ có thể được nói một cách an toàn để tránh trùng lặp các mô-đun trong mã phía máy khách của bạn nếu bạn có quyền kiểm soát toàn bộ cây phụ thuộc của mình. Đây chắc chắn không phải là trường hợp với phần lớn những thứ tôi làm và có lẽ không phải cho hầu hết các dự án sử dụng trình quản lý phụ thuộc để bao gồm các mô-đun phía máy khách.
theo đó

1
Trừ khi bạn đang làm việc trên các ứng dụng hòa trộn, cây phụ thuộc của bạn sẽ không phức tạp như vậy, ít nhất là đối với mã của bên thứ ba. Hầu hết các thư viện js xuất một toàn cầu duy nhất, vì vậy sử dụng browserify-shim bạn có thể đảm bảo rằng bạn có thể sử dụng chúng từ phạm vi toàn cầu do đó luôn là phiên bản bạn kiểm soát. Quan điểm của tôi là bạn có thể đạt được điều tương tự mà không cần một người quản lý gói khác trên đầu trang mà bạn đã có. Cuối cùng, nó có thể là một vấn đề sở thích. Luôn luôn có sự thỏa hiệp được thực hiện.
royjas

5

Tôi biết điều này không nằm trong phạm vi của câu hỏi nhưng cũng có một cách khác. Jam JS - http://jamjs.org/ Một điều thú vị là nó có khả năng xử lý khó khăn:

jam compile output.js

Ai đó nên tạo một trình quản lý gói khác và đặt tên cho nó: yapm :)


5
Điều ước của bạn đã được thực hiện: github.com/rlidwka/yapm : P
alex

1
Tôi đã suy nghĩ cho người quản lý phụ thuộc phía trình duyệt nhưng tôi đoán công việc này cho cả hai: p Đây là lý do tại sao tôi không thể khởi nghiệp, tất cả các ý tưởng của tôi đã được nghĩ đến.
Bruce Lim

@BruceLim yeah, mỗi khi chúng tôi nghĩ rằng chúng tôi có một ý tưởng hay, luôn có một số người khác đã có nó.
Evan Hu
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.