Sự khác biệt giữa Bower và npm là gì?

Sự khác biệt cơ bản giữa bowervà là npmgì? Chỉ muốn một cái gì đó đơn giản và đơn giản. Tôi đã thấy một số đồng nghiệp của tôi sử dụng bowervà npmhoán đổi cho nhau trong các dự án của họ.

Tất cả các nhà quản lý gói có nhiều nhược điểm. Bạn chỉ cần chọn những gì bạn có thể sống với.

Lịch sử

npm bắt đầu quản lý các mô-đun node.js (đó là lý do tại sao các gói đi vào node_modulestheo mặc định), nhưng nó cũng hoạt động cho giao diện người dùng khi kết hợp với Browserify hoặc webpack .

Bower được tạo ra chỉ dành cho front-end và được tối ưu hóa với ý nghĩ đó.

Kích thước của repo

npm lớn hơn nhiều so với Bower, bao gồm JavaScript cho mục đích chung (như country-datathông tin quốc gia hoặc sortssắp xếp các chức năng có thể sử dụng được ở mặt trước hoặc mặt sau).

Bower có số lượng gói nhỏ hơn nhiều.

Xử lý các kiểu vv

Bower bao gồm các phong cách, vv

npm được tập trung vào JavaScript. Kiểu được tải xuống riêng hoặc được yêu cầu bởi một cái gì đó như npm-sasshoặcsass-npm .

Xử lý phụ thuộc

Sự khác biệt lớn nhất là npm không phụ thuộc lồng nhau (nhưng theo mặc định là phẳng) trong khi Bower yêu cầu cây phụ thuộc phẳng (đặt gánh nặng của độ phân giải phụ thuộc lên người dùng) .

Cây phụ thuộc lồng nhau có nghĩa là các phụ thuộc của bạn có thể có các phụ thuộc riêng có thể có riêng, v.v. Điều này cho phép hai mô-đun yêu cầu các phiên bản khác nhau của cùng một phụ thuộc và vẫn hoạt động. Lưu ý kể từ npm v3, cây phụ thuộc sẽ theo mặc định (tiết kiệm không gian) và chỉ lồng khi cần thiết, ví dụ: nếu hai phụ thuộc cần phiên bản Underscore của riêng chúng.

Một số dự án sử dụng cả hai là họ sử dụng Bower cho các gói front-end và npm cho các công cụ dành cho nhà phát triển như Yeoman, Grunt, Gulp, JSHint, CoffeeScript, v.v.

Tài nguyên

• Các phụ thuộc lồng nhau - Hiểu sâu về lý do tại sao node_modules hoạt động theo cách của nó

Câu trả lời này là một bổ sung cho câu trả lời của Sindre Sorhus. Sự khác biệt chính giữa npm và Bower là cách họ đối xử với các phụ thuộc đệ quy. Lưu ý rằng chúng có thể được sử dụng cùng nhau trong một dự án.

Trên npm FAQ : (link.org.org từ ngày 6 tháng 9 năm 2015)

Khó hơn nhiều để tránh xung đột phụ thuộc mà không phụ thuộc lồng nhau. Đây là nền tảng cho cách mà npm hoạt động, và đã được chứng minh là một cách tiếp cận cực kỳ thành công.

Trên trang chủ của Bower :

Bower được tối ưu hóa cho front-end. Bower sử dụng cây phụ thuộc phẳng, chỉ yêu cầu một phiên bản cho mỗi gói, giảm tải trang xuống mức tối thiểu.

Trong ngắn hạn, npm nhằm mục đích ổn định. Bower nhằm mục đích tải tài nguyên tối thiểu. Nếu bạn rút ra cấu trúc phụ thuộc, bạn sẽ thấy điều này:

chiều

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

Như bạn có thể thấy nó cài đặt một số phụ thuộc đệ quy. Phụ thuộc A có ba trường hợp cài đặt!

Cung cấp:

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

Ở đây bạn thấy rằng tất cả các phụ thuộc duy nhất là trên cùng một cấp độ.

Vì vậy, tại sao phải sử dụng npm?

Có thể phụ thuộc B yêu cầu một phiên bản phụ thuộc A khác với phụ thuộc C. npm cài đặt cả hai phiên bản của phụ thuộc này để nó vẫn hoạt động, nhưng Bower sẽ cung cấp cho bạn một xung đột vì không thích sao chép (vì tải cùng một tài nguyên trên trang web là rất không hiệu quả và tốn kém, nó cũng có thể đưa ra một số lỗi nghiêm trọng). Bạn sẽ phải tự chọn phiên bản nào bạn muốn cài đặt. Điều này có thể có tác động là một trong những phụ thuộc sẽ bị phá vỡ, nhưng đó là điều mà bạn sẽ cần phải khắc phục bằng mọi cách.

Vì vậy, cách sử dụng phổ biến là Bower cho các gói bạn muốn xuất bản trên các trang web của mình (ví dụ: thời gian chạy , nơi bạn tránh trùng lặp) và sử dụng npm cho các nội dung khác, như kiểm tra, xây dựng, tối ưu hóa, kiểm tra, v.v. (ví dụ: thời gian phát triển , trong đó sự trùng lặp là ít quan tâm).

Cập nhật cho npm 3:

npm 3 vẫn làm mọi thứ khác so với Bower. Nó sẽ cài đặt các phụ thuộc trên toàn cầu, nhưng chỉ cho phiên bản đầu tiên mà nó gặp. Các phiên bản khác được cài đặt trong cây (mô đun mẹ, sau đó là node_modules).

• [node_modules]
  • dep A v1.0
  • dep B v1.0
    • dep A v1.0 (sử dụng phiên bản gốc)
  • dep C v1.0
    • dep A v2.0 (phiên bản này khác với phiên bản gốc, vì vậy nó sẽ là một bản cài đặt lồng nhau)

Để biết thêm thông tin, tôi khuyên bạn nên đọc tài liệu của npm 3

TL; DR: Sự khác biệt lớn nhất trong sử dụng hàng ngày không phải là phụ thuộc lồng nhau ... đó là sự khác biệt giữa các mô-đun và toàn cầu.

Tôi nghĩ rằng các áp phích trước đã bao gồm một số khác biệt cơ bản. (việc sử dụng các phụ thuộc lồng nhau của npm thực sự rất hữu ích trong việc quản lý các ứng dụng lớn, phức tạp, mặc dù tôi không nghĩ đó là điểm khác biệt quan trọng nhất.)

Tuy nhiên, tôi ngạc nhiên rằng không ai giải thích rõ ràng một trong những điểm khác biệt cơ bản nhất giữa Bower và npm. Nếu bạn đọc các câu trả lời ở trên, bạn sẽ thấy từ 'mô-đun' được sử dụng thường xuyên trong ngữ cảnh của npm. Nhưng nó được đề cập một cách tình cờ, như thể nó thậm chí chỉ là một sự khác biệt cú pháp.

Nhưng sự khác biệt này của các mô-đun so với toàn cầu (hoặc mô-đun so với 'tập lệnh') có thể là sự khác biệt quan trọng nhất giữa Bower và npm. Cách tiếp cận npm của việc đưa mọi thứ vào các mô-đun yêu cầu bạn thay đổi cách bạn viết Javascript cho trình duyệt, gần như chắc chắn sẽ tốt hơn.

Phương pháp tiếp cận Bower: Tài nguyên toàn cầu, như <script>thẻ

Tại root, Bower là về việc tải các tập tin script đơn giản. Bất cứ tập tin script nào chứa, Bower sẽ tải chúng. Điều đó về cơ bản có nghĩa là Bower giống như bao gồm tất cả các tập lệnh của bạn ở dạng cũ <script>trong <head>HTML của bạn.

Vì vậy, cách tiếp cận cơ bản tương tự bạn đã từng sử dụng, nhưng bạn có được một số tiện ích tự động hóa tốt đẹp:

• Bạn đã từng cần bao gồm các phụ thuộc JS trong repo dự án của bạn (trong khi phát triển) hoặc nhận chúng thông qua CDN. Bây giờ, bạn có thể bỏ qua trọng lượng tải xuống thêm trong repo và ai đó có thể thực hiện nhanh chóng bower installvà ngay lập tức có những gì họ cần, tại địa phương.
• Nếu một phụ thuộc Bower sau đó chỉ định các phụ thuộc của chính nó bower.json, thì chúng cũng sẽ được tải xuống cho bạn.

Nhưng ngoài ra, Bower không thay đổi cách chúng ta viết javascript . Không có gì về những gì bên trong các tệp được tải bởi Bower cần phải thay đổi cả. Cụ thể, điều này có nghĩa là các tài nguyên được cung cấp trong các tập lệnh được tải bởi Bower sẽ (thường, nhưng không phải luôn luôn) vẫn được định nghĩa là các biến toàn cục , có sẵn từ bất kỳ đâu trong bối cảnh thực thi trình duyệt.

Cách tiếp cận npm: Các mô-đun JS thông thường, Tiêm phụ thuộc rõ ràng

Tất cả mã trong vùng đất Node (và do đó tất cả mã được tải qua npm) được cấu trúc dưới dạng các mô-đun (cụ thể, như một triển khai định dạng mô-đun CommonJS , hoặc bây giờ, dưới dạng mô-đun ES6). Vì vậy, nếu bạn sử dụng NPM để xử lý các phụ thuộc phía trình duyệt (thông qua Browserify hoặc một công việc khác làm cùng công việc), bạn sẽ cấu trúc mã của mình giống như cách làm của Node.

Những người thông minh hơn tôi đã giải quyết câu hỏi 'Tại sao các mô-đun?', Nhưng đây là tóm tắt về viên nang:

• Bất cứ điều gì bên trong một mô-đun đều được đặt tên một cách hiệu quả , có nghĩa là nó không còn là biến toàn cục nữa và bạn không thể vô tình tham chiếu nó mà không có ý định.
• Bất cứ điều gì bên trong một mô-đun phải được đưa vào một bối cảnh cụ thể (thường là một mô-đun khác) để sử dụng nó.
• Điều này có nghĩa là bạn có thể có nhiều phiên bản của cùng một phụ thuộc bên ngoài (lodash, giả sử) trong các phần khác nhau của ứng dụng của bạn và chúng sẽ không va chạm / xung đột. (Điều này xảy ra thường xuyên một cách đáng ngạc nhiên, bởi vì mã của riêng bạn muốn sử dụng một phiên bản của một phụ thuộc, nhưng một trong các phụ thuộc bên ngoài của bạn chỉ định một phiên bản khác xung đột.
• Bởi vì tất cả các phụ thuộc được chèn thủ công vào một mô-đun cụ thể, rất dễ dàng để lý giải về chúng. Bạn biết một sự thật: "Mã duy nhất tôi cần xem xét khi làm việc này là những gì tôi đã cố ý chọn để tiêm ở đây" .
• Bởi vì ngay cả nội dung của các mô-đun được chèn cũng được gói gọn sau biến bạn gán cho nó và tất cả các mã thực thi trong một phạm vi giới hạn, các bất ngờ và va chạm trở nên rất khó xảy ra. Rất ít khả năng một cái gì đó từ một trong những phụ thuộc của bạn sẽ vô tình xác định lại một biến toàn cục mà bạn không nhận ra nó, hoặc bạn sẽ làm như vậy. (Điều đó có thể xảy ra, nhưng bạn thường phải cố gắng thực hiện nó, với một cái gì đó giống như window.variable. Một tai nạn vẫn có xu hướng xảy ra là phân công this.variable, không nhận ra đó thisthực sự là windowtrong bối cảnh hiện tại.)
• Khi bạn muốn kiểm tra một mô-đun riêng lẻ, bạn có thể dễ dàng biết: chính xác những gì khác (phụ thuộc) đang ảnh hưởng đến mã chạy bên trong mô-đun? Và, bởi vì bạn rõ ràng tiêm tất cả mọi thứ, bạn có thể dễ dàng chế giễu những phụ thuộc đó.

Đối với tôi, việc sử dụng các mô-đun cho mã mặt trước có nghĩa là: làm việc trong một bối cảnh hẹp hơn nhiều để dễ dàng lý luận và kiểm tra, và có sự chắc chắn hơn về những gì đang diễn ra.

Chỉ mất khoảng 30 giây để tìm hiểu cách sử dụng cú pháp mô-đun CommonJS / Node. Bên trong một tệp JS đã cho, sẽ là một mô-đun, trước tiên bạn khai báo mọi phụ thuộc bên ngoài mà bạn muốn sử dụng, như sau:

var React = require('react');

Bên trong tệp / mô-đun, bạn làm bất cứ điều gì bạn thường làm và tạo một số đối tượng hoặc chức năng mà bạn muốn tiếp xúc với người dùng bên ngoài, có thể gọi nó là có thể myModule.

Ở cuối tệp, bạn xuất bất cứ thứ gì bạn muốn chia sẻ với mọi người, như thế này:

module.exports = myModule;

Sau đó, để sử dụng quy trình làm việc dựa trên CommonJS trong trình duyệt, bạn sẽ sử dụng các công cụ như Browserify để lấy tất cả các tệp mô-đun riêng lẻ đó, đóng gói nội dung của chúng khi chạy và tiêm chúng vào nhau khi cần.

VÀ, vì các mô-đun ES6 (có khả năng sẽ chuyển sang ES5 bằng Babel hoặc tương tự) đang được chấp nhận rộng rãi và hoạt động cả trong trình duyệt hoặc trong Nút 4.0, chúng ta cũng nên đề cập đến một tổng quan tốt về các mô-đun đó .

Thông tin thêm về các mẫu để làm việc với các mô-đun trong bộ bài này .

EDIT (Tháng 2 năm 2017): Sợi của Facebook là một sự thay thế / bổ sung tiềm năng rất quan trọng cho npm những ngày này: quản lý gói ngoại tuyến nhanh, mang tính quyết định, dựa trên những gì npm mang lại cho bạn. Nó đáng để xem xét cho bất kỳ dự án JS nào, đặc biệt là vì nó rất dễ dàng để trao đổi vào / ra.

EDIT (tháng 5 năm 2019) "Bower cuối cùng đã bị phản đối . Kết thúc câu chuyện." (h / t: @DanDascalescu, bên dưới, để tóm tắt về pithy.)

Và, trong khi Sợi vẫn hoạt động , rất nhiều động lực cho nó đã quay trở lại npm sau khi nó áp dụng một số tính năng chính của Sợi.

Cập nhật 2017-tháng 10

Bower cuối cùng đã bị phản đối . Kết thúc câu chuyện.

Câu trả lời cũ hơn

Từ Mattias Petter Johansson, nhà phát triển JavaScript tại Spotify :

Trong hầu hết các trường hợp, nó phù hợp hơn để sử dụng Browserify và npm trên Bower. Nó chỉ đơn giản là một giải pháp đóng gói tốt hơn cho các ứng dụng front-end so với Bower. Tại Spotify, chúng tôi sử dụng npm để đóng gói toàn bộ mô-đun web (html, css, js) và nó hoạt động rất tốt.

Bower tự coi mình là người quản lý gói cho web. Thật tuyệt vời nếu điều này là sự thật - một người quản lý gói làm cho cuộc sống của tôi trở thành một nhà phát triển front-end tuyệt vời hơn. Vấn đề là Bower không cung cấp dụng cụ chuyên dụng cho mục đích này. Nó không cung cấp công cụ mà tôi biết về npm đó, và đặc biệt là không có công cụ nào đặc biệt hữu ích cho các nhà phát triển front-end. Đơn giản là không có lợi ích gì cho nhà phát triển front-end sử dụng Bower qua npm.

Chúng ta nên ngừng sử dụng Bower và hợp nhất vào khoảng npm. Rất may, đó là những gì đang xảy ra :

Với browserify hoặc webpack, việc kết hợp tất cả các mô-đun của bạn thành các tệp được thu nhỏ lớn trở nên cực kỳ dễ dàng, rất tuyệt vời cho hiệu suất, đặc biệt là cho các thiết bị di động. Không như vậy với Bower, sẽ đòi hỏi nhiều lao động hơn để có được hiệu quả tương tự.

npm cũng cung cấp cho bạn khả năng sử dụng đồng thời nhiều phiên bản mô-đun. Nếu bạn chưa thực hiện nhiều phát triển ứng dụng, điều này ban đầu có thể khiến bạn trở thành một điều tồi tệ, nhưng một khi bạn đã trải qua một vài cơn địa ngục phụ thuộc, bạn sẽ nhận ra rằng có khả năng có nhiều phiên bản của một mô-đun là một điều khá tệ tính năng tuyệt vời. Lưu ý rằng npm bao gồm một công cụ khấu trừ rất tiện dụng , tự động đảm bảo rằng bạn chỉ sử dụng hai phiên bản của một mô-đun nếu bạn thực sự phải làm - nếu cả hai mô-đun có thể sử dụng cùng một phiên bản của một mô-đun, chúng sẽ. Nhưng nếu họ không thể , bạn có một tiện ích rất hữu ích.

(Lưu ý rằng Webpack và rollup được coi là tốt hơn Browserify kể từ tháng 8 năm 2016.)

Bower duy trì một phiên bản duy nhất của các mô-đun, nó chỉ cố gắng giúp bạn chọn đúng / tốt nhất cho bạn.

Quản lý phụ thuộc Javascript: npm vs bower vs volo?

NPM tốt hơn cho các mô-đun nút vì có một hệ thống mô-đun và bạn đang làm việc cục bộ. Bower tốt cho trình duyệt vì hiện tại chỉ có phạm vi toàn cầu và bạn muốn rất chọn lọc về phiên bản bạn làm việc cùng.

Nhóm của tôi chuyển khỏi Bower và di chuyển đến npm vì:

• Sử dụng chương trình là đau đớn
• Giao diện của Bower liên tục thay đổi
• Một số tính năng, như tốc ký url, bị hỏng hoàn toàn
• Sử dụng cả Bower và npm trong cùng một dự án đều gây đau đớn
• Giữ trường phiên bản bower.json đồng bộ hóa với thẻ git là điều đau đớn
• Kiểm soát nguồn! = Quản lý gói
• Hỗ trợ CommonJS không đơn giản

Để biết thêm chi tiết, xem "Tại sao nhóm của tôi sử dụng npm thay vì bower" .

Tìm thấy lời giải thích hữu ích này từ http://ng-learn.org/2013/11/Bower-vs-npm/

Một mặt npm đã được tạo để cài đặt các mô-đun được sử dụng trong môi trường node.js hoặc các công cụ phát triển được xây dựng bằng cách sử dụng node.js như Karma, lint, minifier, v.v. npm có thể cài đặt các mô-đun cục bộ trong một dự án (theo mặc định trong node_modules) hoặc trên toàn cầu để được sử dụng bởi nhiều dự án. Trong các dự án lớn, cách chỉ định các phụ thuộc là bằng cách tạo một tệp có tên là pack.json chứa danh sách các phụ thuộc. Danh sách đó được nhận ra bởi npm khi bạn chạy cài đặt npm, sau đó tải xuống và cài đặt chúng cho bạn.

Mặt khác, Bower được tạo ra để quản lý các phụ thuộc frontend của bạn. Các thư viện như jQuery, AngularJS, gạch dưới, v.v. Tương tự như npm, nó có một tệp trong đó bạn có thể chỉ định một danh sách các phụ thuộc được gọi là bower.json. Trong trường hợp này, các phụ thuộc lối vào của bạn được cài đặt bằng cách chạy cài đặt bower mà theo mặc định sẽ cài đặt chúng trong một thư mục có tên bower_components.

Như bạn có thể thấy, mặc dù chúng thực hiện một nhiệm vụ tương tự, chúng được nhắm mục tiêu đến một bộ thư viện rất khác.

Đối với nhiều người làm việc với node.js, một lợi ích chính của Bower là để quản lý các phụ thuộc hoàn toàn không phải là javascript. Nếu họ đang làm việc với các ngôn ngữ biên dịch thành javascript, npm có thể được sử dụng để quản lý một số phụ thuộc của họ. tuy nhiên, không phải tất cả các phụ thuộc của chúng sẽ là các mô-đun node.js. Một số trong số các trình biên dịch thành javascript có thể có sự xáo trộn cụ thể về ngôn ngữ nguồn khiến cho việc chuyển chúng xung quanh được biên dịch sang javascript trở thành một tùy chọn không phù hợp khi người dùng đang mong đợi mã nguồn.

Không phải tất cả mọi thứ trong gói npm đều phải là javascript hướng tới người dùng, nhưng đối với các gói thư viện npm, ít nhất là một số trong số đó phải như vậy.