Câu hỏi Sự khác nhau giữa Bower và npm là gì?


Sự khác biệt cơ bản giữa bower và npm? 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 bower và npm thay thế cho nhau trong các dự án của họ.


1612
2017-09-05 16:53


gốc


Câu trả lời liên quan stackoverflow.com/a/21199026/1310070 - sachinjain024
có thể trùng lặp Quản lý phụ thuộc Javascript: npm vs bower vs volo? - anotherdave
Câu trả lời cho câu hỏi này có vẻ đã lỗi thời. Ai đó có thể cho chúng tôi biết phải làm gì trong năm 2016 nếu chúng tôi sử dụng npm 3 có hỗ trợ phụ thuộc bằng phẳng không? Sự khác biệt giữa wince npm3 và bower là gì và thực hành tốt nhất hiện nay là gì? - amdev
Bottom-line, @amdev: bower hiện không được chấp nhận. npm (hoặc Yarn, mà chỉ là một sự khác biệt nhỏ) là nơi nó ở. Tôi không biết về bất kỳ lựa chọn thay thế khả thi nào. - XML


Các câu trả lời:


Tất cả các nhà quản lý gói đều có nhiều nhược điểm. Bạn chỉ cần chọn mà 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_modules theo mặc định), nhưng nó cũng hoạt động cho front-end khi được kết hợp với Trình duyệt hoặc WebPack.

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

Kích thước của repo

npm là nhiều, lớn hơn nhiều so với bower, bao gồm JavaScript mục đích chung (như country-data cho thông tin quốc gia hoặc sorts để sắp xếp các hàm 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 phong cách vv

Bower bao gồm các phong cách, v.v.

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

Xử lý phụ thuộc

Sự khác biệt lớn nhất là npm thực hiện các phụ thuộc lồng nhau (nhưng được căn chỉnh theo mặc định) trong khi Bower yêu cầu một cây phụ thuộc bằng phẳng (đặt gánh nặng của độ phân giải phụ thuộc vào 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ủa chúng có thể có các phần phụ thuộc của riêng chúng và vân vân. Đ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 sự phụ thuộc và vẫn hoạt động. Lưu ý vì npm v3, cây phụ thuộc sẽ bằng phẳng theo mặc định (tiết kiệm không gian) và chỉ làm tổ khi cần, ví dụ nếu hai phụ thuộc cần phiên bản riêng của dấu gạch dưới.

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ụ phát triển như Yeoman, Grunt, Gulp, JSHint, CoffeeScript, v.v.


Tài nguyên


1828
2017-09-06 08:09



Tại sao một cây phụ thuộc lồng nhau không làm tốt điều đó trên giao diện người dùng? - Lars Nyström
Có thể một gói npm front-end không phải là một cây phụ thuộc phẳng không? Tôi đang phải đối mặt với "tại sao chúng ta cần 2 người quản lý gói?" tình trạng khó xử. - Steven Vachon
Bạn có ý gì bởi "cây phụ thuộc bằng phẳng"? Cây phẳng là gì - một danh sách? Nó không phải là một cái cây. - mvmn
Trên thực tế, một con đường cũng là một cái cây. Nó chỉ là một trường hợp đặc biệt. Từ WikiPedia: "Trong toán học, và cụ thể hơn trong lý thuyết đồ thị, một cây là một đồ thị vô hướng, trong đó bất kỳ hai đỉnh nào được kết nối bằng chính xác một đường dẫn." - Jørgen Fogh
npm 3 hỗ trợ một cây phụ thuộc bằng phẳng ngay bây giờ. - vasa


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 chúng xử lý 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 duy nhất.

Trên Câu hỏi thường gặp về npm: (liên kết archive.org từ ngày 6 tháng 9 năm 2015)

Nó là khó khăn hơn nhiều để tránh xung đột phụ thuộc mà không làm tổ   phụ thuộc. Đâ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 Bower trang chủ:

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

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

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

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!

Bower:

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 đều ở cùng cấp.

Vì vậy, tại sao bận tâm sử dụng npm?

Có lẽ phụ thuộc B yêu cầu một phiên bản phụ thuộc khác nhau A phụ thuộc C. npm cài đặt cả hai phiên bản của sự phụ thuộc này để nó sẽ hoạt động, nhưng Bower sẽ cung cấp cho bạn cuộc xung đột bởi vì nó không thích trùng lặp (vì tải cùng một tài nguyên trên một trang web là rất kém 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 chọn phiên bản bạn muốn cài đặt theo cách thủ công. Điều này có thể có hiệu lực là một trong những phụ thuộc sẽ bị phá vỡ, nhưng đó là một cái gì đó mà bạn sẽ cần phải sửa chữa anyway.

Vì vậy, cách sử dụng phổ biến là Bower cho các gói mà bạn muốn xuất bản trên các trang web của bạn (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ư thử nghiệm, xây dựng, tối ưu hóa, kiểm tra, v.v. (ví dụ: thời gian phát triển, nơi trùng lặp ít quan tâm hơn).

Cập nhật cho npm 3:

npm 3 vẫn làm những việc 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 phải. Các phiên bản khác được cài đặt trong cây (module cha, sau đó 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 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


338
2017-11-24 13:10



Nó gần như là một cliché bây giờ mà "phát triển phần mềm là tất cả về thương mại-off." Đây là một ví dụ tốt. Người ta phải chọn hoặc ổn định hơn với npm  hoặc là tải tài nguyên tối thiểu với bower. - jfmercer
@ Shrek Tôi ngầm nói rằng bạn thực sự có thể sử dụng cả hai. Chúng có các mục đích khác nhau, như tôi nêu trong đoạn cuối cùng. Nó không phải là một sự đánh đổi trong mắt tôi. - Justus Romijn
Ahh, tôi thấy tôi hiểu lầm bạn. Hoặc tôi đã không đọc đủ kỹ. Cảm ơn bạn đã làm rõ. :-) Tốt là cả hai có thể được sử dụng mà không có một sự cân bằng. - jfmercer
@AlexAngas Tôi đã thêm bản cập nhật cho npm3. Nó vẫn có một số khác biệt lớn so với Bower. npm có lẽ sẽ luôn hỗ trợ nhiều phiên bản phụ thuộc, trong khi Bower thì không. - Justus Romijn
npm 3 đến gần hơn với bower;) - ni3


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à hình cầu.

Tôi nghĩ những áp phích trước đó đã bao hà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 phức tạp, lớn, mặc dù tôi không nghĩ đó là sự khác biệt quan trọng nhất.)

Tôi ngạc nhiên, tuy nhiên, không ai giải thích rõ ràng một trong những khác biệt cơ bản nhất giữa Bower và npm. Nếu bạn đọ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 ngẫu nhiên, như thể nó thậm chí có thể là một sự khác biệt cú pháp.

Nhưng sự khác biệt này modules so với globals (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 là tốt hơn.

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

Ở thư mục gốc, Bower sắp tải các tập tin kịch bản cũ. Bất kể những tập tin kịch bản có chứa, Bower sẽ tải chúng. Về cơ bản có nghĩa là Bower giống như bao gồm tất cả các kịch bản của bạn ở dạng cũ <script>trong <head> của HTML của bạn.

Vì vậy, cách tiếp cận cơ bản giống như 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 đang 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 bổ sung đó trong repo và ai đó có thể làm nhanh 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 thì xác định các phụ thuộc của nó trong bower.json, 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 tin được tải bởi Bower cần phải thay đổi. Đặc biệt, điều này có nghĩa là các tài nguyên được cung cấp trong các kịch bản được nạp bởi Bower sẽ (thường, nhưng không phải lúc nào) vẫn được định nghĩa là biến toàn cầu, có sẵn ở mọi nơi trong ngữ cảnh thực thi trình duyệt.

Phương pháp tiếp cận npm: Các mô đun JS chung, Chèn phụ thuộc rõ ràng

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

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

  • Mọi thứ bên trong một mô-đun đều hiệu quả không gian tên, nghĩa là nó không phải là một biến toàn cầu 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 cố ý tiêm vào một bối cảnh cụ thể (thường là một mô-đun khác) để tận 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 xung đột / xung đột. (Điều này xảy ra đáng ngạc nhiên thường xuyên, bởi vì mã của riêng bạn muốn sử dụng một phiên bản phụ thuộc, nhưng một trong những phụ thuộc bên ngoài của bạn chỉ định một phiên bản khác xung đột. Hoặc bạn có hai phụ thuộc bên ngoài mà mỗi phiên bản muốn có một phiên bản khác nhau.)
  • Bởi vì tất cả các phụ thuộc được tự chèn vào một mô-đun cụ thể, nó rất dễ dàng để lý do về chúng. Bạn biết thực tế: "Mã duy nhất tôi cần xem xét khi làm việc trê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 tiêm là đóng gói đằng sau biến bạn gán cho nó, và tất cả các mã thực thi bên trong một phạm vi giới hạn, những bất ngờ và va chạm trở nên rất không thể xảy ra. Nó là nhiều, ít có khả năng là 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ầu mà bạn không nhận ra nó, hoặc rằng bạn sẽ làm như vậy. (Nó có thể xảy ra, nhưng bạn thường phải đi ra khỏi con đường của bạn để làm điều đó, với một cái gì đó như window.variable. Một tai nạn mà vẫn có xu hướng xảy ra là phân công this.variable, không nhận ra rằng this thực sự là window trong ngữ cảnh hiện tại.)
  • Khi bạn muốn thử nghiệm 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 đang tiêm chích mọi thứ một cách rõ ràng, bạn có thể dễ dàng chế nhạo những phụ thuộc đó.

Đối với tôi, việc sử dụng các mô-đun cho mã front-end bắt đầu xuống: làm việc trong một bối cảnh hẹp hơn dễ dàng hơn để lý luận và thử nghiệm, và có sự chắc chắn hơn về những gì đang xảy 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, mà sẽ là một mô-đun, trước tiên bạn khai báo bất kỳ phụ thuộc bên ngoài nào bạn muốn sử dụng, như sau:

var React = require('react');

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

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

module.exports = myModule;

Sau đó, để sử dụng luồng công 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 trong thời gian chạy và tiêm chúng vào nhau khi cần.

VÀ, vì các mô-đun ES6 (mà bạn có thể sẽ chuyển thành ES5 với Babel hoặc tương tự) đang được chấp nhận rộng rãi và làm việc cả trong trình duyệt hoặc trong Node 4.0, chúng ta nên đề cập đến tổng quan tốt của những người là tốt.

Tìm hiểu thêm về các mô hình để làm việc với các mô-đun trong cái boong này.


EDIT (tháng 2 năm 2017): Facebook's Sợi là một thay thế / bổ sung tiềm năng rất quan trọng cho npm những ngày này: nhanh chóng, xác định, quản lý gói ngoại tuyến được xây dựng dựa trên những gì npm cung cấp cho bạn. Đó là một cái nhìn đáng giá cho bất kỳ dự án JS nào, đặc biệt là vì nó dễ dàng hoán đổi nó vào / ra.


256
2017-07-26 03:12



Vui mừng câu trả lời này là ở đây, các câu trả lời phổ biến khác không đề cập đến chi tiết này. npm buộc bạn phải viết mã mô-đun. - Juan Mendes


Bản cập nhật 2017-tháng 10

Bower cuối cùng đã được không dùng nữa. 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, bạn nê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 hơn Bower. Tại Spotify, chúng tôi sử dụng npm để đóng gói toàn bộ các mô-đun web (html, css, js) và nó hoạt động rất tốt.

Bản thân thương hiệu Bower là người quản lý gói cho web. Nó sẽ là tuyệt vời nếu điều này là đúng - một người quản lý gói mà làm cho cuộc sống của tôi tốt hơn như là một nhà phát triển front-end sẽ là tuyệt vời. Vấn đề là Bower không cung cấp dụng cụ chuyên dụng cho mục đích này. Nó cung cấp NO công cụ mà tôi biết rằng npm không, và đặc biệt là không có gì là đặc biệt hữu ích cho các nhà phát triển front-end. Chỉ đơn giản là không có lợi ích cho một nhà phát triển front-end sử dụng Bower trên npm.

Chúng ta nên ngừng sử dụng bower và củng cố xung quanh npm. Rất may, đó là những gì đang xảy ra:

Module counts - bower vs. npm

Với trình duyệt web hoặc webpack, nó trở nên siêu dễ dàng để nối tất cả các mô-đun của bạn thành các tệp được rút gọn lớn, 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 phải như vậy với Bower, mà sẽ đòi hỏi lao động nhiều hơn đáng kể để có được tác dụng tương tự.

npm cũng cung cấp cho bạn khả năng sử dụng nhiều phiên bản mô-đun cùng một lúc. 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ể tấn công bạn như một điều xấu, nhưng một khi bạn đã trải qua một vài lầ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 tính năng tuyệt vời. Lưu ý rằng npm bao gồm rất tiện dụng công cụ dedupe tự động đảm bảo rằng bạn chỉ sử dụng hai phiên bản của mô-đun nếu bạn thực sự  đến - nếu hai mô-đun cả hai có thể sử dụng cùng một phiên bản của một mô-đun, họ sẽ. Nhưng nếu họ không thể, bạn rất tiện dụng.

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


117
2017-07-04 10:48



webpack và npm thậm chí còn tốt hơn tôi nghĩ .. - refactor
<sarcasm> Xin lưu ý rằng ngay cả dự án "hello world" npm cần hơn 300 mô-đun để chạy ... </ sarcasm>: O - Mariusz Jamro
Tôi không đồng ý rằng "tệp được rút gọn lớn" là "tuyệt vời cho hiệu suất, đặc biệt đối với thiết bị di động". Hoàn toàn ngược lại: Băng thông hạn chế yêu cầu các tệp nhỏ, được tải theo yêu cầu. - Michael Franzl
Không phải lời khuyên rất tốt. Hầu hết các gói npm chỉ là phần phụ trợ nút. Nếu bạn không làm javascript trên backend, hoặc bạn không có một hệ thống mô-đun tại chỗ, số lượng các gói là không thích hợp vì Bower sẽ phù hợp với nhu cầu của bạn tốt hơn nhiều - Gerardo Grignoli
@GerardoGrignoli: bower đang trên đường ra. - Dan Dascalescu


Bower duy trì một phiên bản duy nhất của 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 là 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 tại địa phương. Bower là tốt cho trình duyệt bởi 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.


43
2017-07-19 20:59



Tôi cảm thấy rằng Sindre đề cập rằng khi ông nói về sự phụ thuộc lồng nhau. - Games Brainiac
@GamesBrainiac chính xác của bạn, chỉ nghĩ rằng tôi muốn đặt nó trong lời nói của riêng tôi. - Sagivf
@Sagivf Đây là KHÔNG PHẢI từ của bạn, trừ khi bạn cũng là những người cung cấp câu trả lời gốc đây - dayuloli
@Sagivf Không có gì sai với việc sao chép ** các bộ phận liên quan câu trả lời của người khác nếu họ không cung cấp câu trả lời ở đây. Nó chỉ nghe tôi một chút bạn nói "chỉ nghĩ rằng tôi muốn đặt nó trong lời nói của riêng tôi." Tín dụng nên đi đến nơi tín dụng đến hạn. - dayuloli
Tôi không biết tại sao các bạn lại chọn câu trả lời này rất nhiều. Có thực sự là thông tin / quan điểm mới trong câu trả lời này cho tôi. - Calvin


Nhóm của tôi đã rời khỏi Bower và chuyển sang npm vì:

  • Sử dụng có lập trình đã gây đau đớn
  • Giao diện của Bower liên tục thay đổi
  • Một số tính năng, như viết tắt của url, hoàn toàn bị hỏng
  • 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 các thẻ git gây đ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, hãy xem "Tại sao nhóm của tôi sử dụng npm thay vì bower".


31
2018-02-16 21:04





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

Trên một bàn tay npm được tạo ra để 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, minifiers và vv. 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 thức để xác định các phụ thuộc là tạo một tệp có tên package.json chứa một danh sách các phụ thuộc. Danh sách đó được công nhận bởi npm khi bạn chạy npm install, 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 lối vào của bạn. Các thư viện như jQuery, AngularJS, dấu gạch dưới, vv Tương tự như npm, nó có một tệp mà bạn có thể chỉ định 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 giao diện người dùng của bạn được cài đặt bằng cách chạy cài đặt bower 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.


14
2017-10-03 00:08



Với sự ra đời của npm dedupe, đây là một chút lỗi thời. Xem Câu trả lời của Mattias. - Dan Dascalescu


Đối với nhiều người làm việc với node.js, lợi ích chính của bower là quản lý các phụ thuộc 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 chúng. tuy nhiên, không phải tất cả các phụ thuộc của họ sẽ là các mô-đun node.js. Một số trong những người biên dịch sang javascript có thể có ngôn ngữ gốc cụ thể mangling kỳ lạ mà làm cho đi qua chúng xung quanh biên dịch để javascript 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 cần 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 một số gói phải là.


4
2017-10-11 20:42



Bài đăng trên blog npmjs này tuyên bố "Gói của bạn có thể chứa bất kỳ thứ gì, cho dù đó là ES6, JS phía máy khách hay thậm chí là HTML và CSS. Đây là những thứ tự nhiên xuất hiện cùng với JavaScript, vì vậy hãy đặt chúng vào đó". - Dan Dascalescu
Có sự khác biệt giữa có thể chứavà nên bao gồm. Tất nhiên chúng có thể chứa bất cứ thứ gì, nhưng nói chung, chúng nên bao gồm một số loại giao diện cho commonJS. Nó là 'quản lý gói nút' sau khi tất cả. Phần về Đây là những thứ tự nhiên bật lên cùng với Javascript


Bower và Npm là các trình quản lý gói cho javascript.

Bower

Bower được tạo ra chỉ để phát triển front-end. Nó sử dụng cây phụ thuộc bằng phẳng, chỉ yêu cầu một phiên bản cho mỗi gói, giảm tải trang. Nó chủ yếu nhằm mục đích tối thiểu tải tài nguyên. Nó có ít người đóng góp hơn và quá trình phát triển chậm.

Bower có một tệp cấu hình có tên bower.json. Trong tập tin này, chúng tôi có thể duy trì cấu hình cho Bower như phụ thuộc nào chúng tôi cần và chi tiết giấy phép, mô tả, tên và vv. Bower phù hợp cho các gói front-end như jquery, góc cạnh, phản ứng, ember, knockout, backbone và vân vân.

Npm

Npm thường được sử dụng để quản lý các mô đun Node.js, nhưng nó cũng hoạt động cho front-end. Nó sử dụng cây phụ thuộc lồng nhau cũng như cây phụ thuộc bằng phẳng. Nó là phổ biến và có rất nhiều người đóng góp. Vì vậy, phiên bản mới của nó luôn luôn đi kèm với các tính năng thú vị.

Npm có tệp cấu hình được gọi là package.json. Trong tập tin này, chúng tôi có thể duy trì cấu hình cho Npm như phụ thuộc chúng tôi cần và chi tiết giấy phép, mô tả, tên và vv. Npm cung cấp Dependencies và DevDependencies. Các phụ thuộc sẽ tải xuống và duy trì các tệp front-end như Jquery, Angular và vân vân. DevDependencies sẽ tải xuống và duy trì các công cụ phát triển như Grunt, Gulp, JSHint và vân vân.

Điều này rõ ràng không hoạt động tốt trên front-end, bởi vì chúng ta cần jQuery trong các dự án của chúng ta. Chúng ta chỉ cần một bản sao của jQuery, nhưng khi một gói khác yêu cầu jQuery, thì nó sẽ tải xuống một lần nữa một bản sao của jQuery. Đây là một trong những hạn chế chính của Npm.

Lưu ý chính: Lý do nhiều 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ụ phát triển. Nhân quản lý gói trong dự án của bạn làm cho công việc của bạn khó khăn hơn. Npm 3 kết hợp với trình duyệt hoặc là webpack là con đường để đi ngay bây giờ.


1
2018-01-07 09:26