2013-06-19 34 views
27

Tài liệu Bower cho biếtTại sao nên kiểm tra các thành phần bower?

N.B. Nếu bạn không phải là tác giả của một gói được dự định sẽ được người khác tiêu thụ (ví dụ: bạn đang xây dựng một ứng dụng web), bạn nên luôn kiểm tra các gói đã cài đặt trong điều khiển nguồn.

Có ai có câu trả lời hay không về lý do không?

Nếu tôi đang làm cho một ứng dụng web tôi không muốn repo của tôi lộn xộn với bản cập nhật trong phiên bản của thư viện X.

Tôi chỉ muốn cập nhật phụ thuộc bower.json. Tôi nghĩ rằng hầu hết các dự án sẽ có một bước xây dựng hoặc tương tự, ví dụ với grunt. Bước xây dựng sẽ đảm bảo gọi cài đặt/cập nhật bower trước khi xây dựng, để các tệp đó có mặt cho concat/minification etc. Hoặc thậm chí là một bản sao đơn giản cho một số thư mục dist.

Tôi có thiếu gì đó không?

Trả lời

28

Đó là để khóa phụ thuộc của bạn để ngăn chặn sự phụ thuộc xấu từ việc phá vỡ ứng dụng của bạn hoặc từ xa không hoạt động để ngăn việc triển khai. Điều này có thể xảy ra mặc dù bạn có một bước xây dựng, vì bạn có thể không kiểm tra kỹ lưỡng trên mọi bản dựng và các thử nghiệm tự động không bắt được mọi thứ, đặc biệt là không phải hồi quy trực quan. Ngoài ra, nhiều nhà phát triển có thể có các phiên bản khác nhau của sự phụ thuộc. Bằng cách có các phụ thuộc cam kết bạn đảm bảo mọi người vẫn ở trên cùng một phiên bản. Tôi cũng tìm thấy sự khác biệt là một cách tốt để đảm bảo không có gì độc hại được giới thiệu trong cây phụ thuộc.

Trong thế giới nút npm shrinkwrap giải quyết một phần vấn đề này, nhưng chưa thực hiện kiểm tra khớp. Bower hiện đang mở ticket để thực hiện tương tự.

Bạn có thể đọc thêm về nó trong bài viết trên blog này: Checking in front-end dependencies

+0

Vâng tôi đoán tôi nghĩ tôi có thể sử dụng 1.2.3 thay vì ~ 1.2.3 hoặc tương tự. (Hoặc thậm chí là ok nếu tôi tin tưởng thư viện để sử dụng semver) Nhưng tôi đoán nếu thư viện X có trong nó bower.json một depedency đến thư viện Y và sử dụng> = 2.3.4 hoặc tương tự sau đó tôi gặp rắc rối. Sẽ được mong đợi một tính năng shrinkwrap. –

+3

Có, và khóa xuống các phiên bản, thậm chí sâu, là không đủ vì thẻ và phiên bản có thể được ghi đè lên. Đó là lý do tại sao 'npm shrinkwrap' cần sự so khớp checksum của deps và đó là những gì chúng ta muốn trong Bower shrinkwrap ngay từ đầu. –

+0

Đây là lý do tương tự như để phát triển trò chơi. Bạn không nâng cấp các gói mọi lúc, do đó bạn có thể đóng băng hoặc "thu nhỏ" chúng ở một phiên bản cụ thể để ngăn sự chậm trễ trong việc triển khai hoặc xây dựng. –

0

Câu trả lời này là phi kỹ thuật nhưng một lý do thực tế để không kiểm tra trong các thành phần Chòi chơi.

Tôi muốn đề xuất các gói bower được khóa trong bower.json hơn là kiểm tra trong các gói này. Bởi vì tôi tin tưởng, bạn không thể có hàng ngàn tệp tải xuống và giải nén trong máy tính. Máy tính hoạt động chậm có vấn đề với đường dẫn tệp rất lớn và sâu. Và trong thế giới này của internet, tôi tin rằng nó luôn luôn dễ dàng để tải về các gói thay vì mang chúng xung quanh.

Nó chỉ là vấn đề ưu tiên. Tất cả đều xuất phát từ kinh nghiệm. Tôi đã kiểm tra trong một dự án với các thành phần bower trên Github và nó là tồi tệ hơn trong khi tải lên và tải xuống. Tôi đã làm điều đó thông qua một máy Mac tương đối mới.

Các vấn đề liên quan