2016-10-21 15 views
11

Tôi giả định rằng khi phát triển dự án NPM, mỗi chi nhánh git (hoặc bất kỳ hệ thống kiểm soát phiên bản nào bạn sử dụng) có thể trỏ đến một bộ khác nhau của node_modules trên hệ thống tệp. Điều đó có đúng không? Nó hoạt động như thế nào? Liệu nó đặt ra bất kỳ vấn đề cho diskspace vv?Mỗi nhánh git của một dự án NPM có phụ thuộc node_modules khác nhau không?

Hoặc có lẽ, kể từ node_modules phổ biến nhất là .gitignore'd, sau đó các tệp node_modules được chia sẻ giữa các chi nhánh Git? Một lần nữa, nó sẽ hoạt động như thế nào?

* Lưu ý rằng Node.js/NPM về cơ bản khác với các nền tảng/ngôn ngữ khác vì các phụ thuộc thường được lưu trữ cục bộ vào một proejct thay vì ở một số vị trí trung tâm trên máy.

+1

Không. Có thể có một cách để làm điều đó, nhưng tôi thêm 'node_modules' vào' .gitignore' và vì chỉ có một nhánh được kiểm tra tại một thời điểm trong cùng một thư mục, tất cả chúng đều sử dụng cùng một mô-đun. –

+0

không có ý nghĩa - nếu một nhánh có các phụ thuộc hoặc phiên bản hoàn toàn khác với nhánh khác. Tôi không nghĩ rằng gitignore giải quyết được điều đó ... –

+0

Nếu một chi nhánh có sự phụ thuộc hoàn toàn khác với một nhánh khác, thì nó có thể là một dự án khác, và có lẽ thuộc về repo riêng của nó. Bạn có bao giờ định hợp nhất các nhánh này lại với nhau không? Điều đó đang được nói, bạn hoàn toàn có thể cam kết các nút 'node_modules' khác nhau để phân nhánh, nhưng đĩa sẽ bị ăn nhanh một cách nhanh chóng, đặc biệt là vì git không lưu trữ vùng lưu trữ, nhưng ảnh chụp nhanh của toàn bộ kho lưu trữ. Có lẽ bạn nên thực hiện tốt hơn các tệp 'package.json' khác nhau và chạy một git hook có thể cài đặt lại các phụ thuộc vào thanh toán chi nhánh. –

Trả lời

13

Theo quy ước, một không được thêm thêm bất kỳ tệp, thư viện hoặc tệp nhị phân nào có thể được tạo hoặc kéo vào từ nguồn bên ngoài. Điều này bao gồm những thứ như node_modules; vì điều đó được thực hiện dễ dàng * một khi bạn làm npm install, không có lý do hoặc khuyến khích nào ** muốn đặt điều đó vào kiểm soát nguồn của bạn. Tại tồi tệ nhất, nó cũng sẽ bloat kho lưu trữ của bạn, điền diffs của bạn với những điều bạn chỉ đơn giản là không kiểm soát và không nhất thiết muốn xem xét.

Tôi sẽ không mong đợi các nhánh Git khác nhau của dự án NPM chứa các thư mục node_modules khác nhau. Tôi chỉ mong đợi một thư mục node_modules, và nếu một chi nhánh đã cho tôi phù hợp về phụ thuộc, tôi sẽ xem xét để cài đặt lại các phụ thuộc (và lưu ý nó xuống để đảm bảo rằng một cái gì đó khác đã không đi awry).

Là phụ lục, bất kỳ tệp hoặc thư mục nào trong .gitignore chỉ đơn giản là không được lập chỉ mục hoặc theo dõi bởi Git. Nếu nội dung của các tập tin hoặc thư mục đó thay đổi, Git không phải là người khôn ngoan hơn. Điều này cũng có nghĩa là, khi chuyển đổi giữa các nhánh, nội dung của các tệp hoặc thư mục trong .gitignore vẫn giữ nguyên.

*: Miễn là thư viện bạn đang sử dụng không bị giật mạnh. Hoặc kho lưu trữ không bị ảnh hưởng bởi một DDoS khổng lồ.

**: Có thể có một số ưu đãi để làm điều này cho rằng độ tin cậy của các gói NPM nhất định đã không được 100% trong năm nay, nhưng đó là một đội bóng và quyết định kiến ​​trúc theo định hướng, và tôi nghi ngờ rằng đặt nó vào kiểm soát nguồn là cách lý tưởng và thuận tiện nhất để đối phó với nó.

3

Hai chi nhánh có bộ mô-đun nút khác nhau trong trường hợp một chi nhánh đang trong giai đoạn phát triển và chi nhánh khác là chi nhánh sản xuất của bạn. Trong trường hợp này, chi nhánh phát triển sẽ có nhiều mô-đun nút hơn là sản xuất. Nếu tôi không sai bất kỳ kịch bản nào khác có thể khiến bạn gặp rắc rối.

Đẩy node_modules đến kho kiểm soát phiên bản từ xa là xấu thực hành vì thế chỉ dựa vào NPM cài đặt bất cứ khi nào bạn sao chép một chi nhánh hoặc kéo các mã để tải về bất kỳ mô-đun nút mới được thêm vào package.json.

5

Có hai trường phái tư tưởng và cả hai đều có giá trị.

1) Không bao giờ kiểm tra trong node_modules và xây dựng lại trên triển khai/cài đặt

Cách tiếp cận dựa chủ yếu vào NPM và khả năng kết nối của môi trường triển khai của bạn. node_modules được tải xuống và cài đặt (và/hoặc được biên dịch) mỗi khi triển khai được chạy.

Vị trí: Kho lưu trữ của bạn nhỏ hơn nhiều.

Mô-đun NPM được cài đặt trong môi trường chúng sẽ chạy.

Mối quan tâm: Gắn với bên thứ ba để tìm nguồn - Đọc về toàn bộ điều đó left-pad. Nếu không thể tải xuống một phụ thuộc, toàn bộ hệ thống xây dựng của bạn sẽ bị treo khô. "Bộ đếm thời gian cũ và cáu kỉnh" sẽ trích dẫn điều này là lý do để kiểm tra mọi thứ trong (hoặc chạy NPM riêng của bạn ở đâu đó).

Quản lý chi nhánh - Giống như bạn đã đề cập trong câu hỏi, một số chi nhánh có thể không có cùng phụ thuộc. Dev1 thêm một tính năng mới và sử dụng một gói mới. Bây giờ Dev2 chạy chi nhánh dev hoặc bất kỳ thứ gì, và mọi thứ đều bị hỏng và họ cần phải biết đến gói npm install mới. Tinh tế hơn là trường hợp gói npm được thay đổi (bây giờ bạn cần npm updatenpm install sẽ không có gì thay đổi), hoặc ở đâu node_modules được nâng cấp để hoạt động trên "tính năng mới 10" nhưng chúng cần xóa mọi thứ ra để "hạ cấp "để đi sửa chữa" lỗi trước 43 ". Nếu bạn đang trong quá trình phát triển tích cực với một nhóm hơn 2-3 người, hãy chú ý đến điều này.

Thời gian xây dựng - Nếu đó là mối quan tâm, phải mất một chút thời gian để tải xuống và cài đặt mọi thứ. Hoặc dài hơn .

2) Luôn kiểm tra ở tất cả mọi thứ bạn có thể

Cách tiếp cận này bao gồm node_modules như một phần của repo.

Vị trí: Không phụ thuộc vào nguồn của bên thứ 3. Bạn có những gì bạn cần để chạy. Mã của bạn có thể tồn tại mãi mãi, và nó không quan trọng nếu npm là xuống hoặc một repo bị xóa.

Chi nhánh độc lập, tính năng rất mới từ Dev1 được tự động đưa vào khi Dev2 chuyển sang mà chi nhánh

Triển khai thời gian ngắn vì không có nhiều nhu cầu phải được cài đặt.

Mối quan tâm: Kho lưu trữ lớn hơn nhiều. Bản sao của mã mất nhiều thời gian hơn vì có nhiều tệp hơn.

Yêu cầu kéo cần được chăm sóc thêm. Nếu một gói được cập nhật (hoặc cài đặt) cùng với mã lõi, PR là một mớ hỗn độn và đôi khi không thể hiểu được. "500 tệp đã thay đổi", nhưng thực sự bạn đã cập nhật một gói và thay đổi hai dòng mã lõi. Nó có thể giúp chia nhỏ thành hai PR - một trong đó là một mớ hỗn độn (bản cập nhật gói) và một trong đó thực sự có thể xem xét lại (thay đổi mã lõi). Một lần nữa, hãy chuẩn bị cho cái này.Các gói sẽ không thay đổi quá thường xuyên, nhưng việc xem xét mã của bạn mất nhiều thời gian hơn (hoặc chăm sóc nhiều hơn một chút) khi chúng thực hiện.

Hệ điều hành Các gói phụ thuộc có thể bị hỏng. Về cơ bản, mọi thứ được cài đặt/biên dịch với gyp có thể phụ thuộc vào hệ điều hành (trong số những người khác). Hầu hết các gói là "JS thuần túy" và, chỉ là các tập lệnh, chạy ở mọi nơi. Hãy tưởng tượng tất cả các dev của bạn chạy và thử nghiệm trên OSX khi bạn triển khai lên Linux, bạn không thể kiểm tra các gói đã được biên dịch trên MAC vì chúng sẽ không chạy trên Linux. Một cách giải quyết khác cho việc này là xác định hầu hết các gói là "phụ thuộc dev" (--save-dev) và các gói cần biên dịch như bình thường ("sản xuất", --save), sau đó bạn chạy npm install --production để phụ thuộc dev không được cài đặt (và đã có sẵn), nhưng những người khác là.

Kết luận

Nó phụ thuộc. (Bạn có ghét nghe mọi lúc không?)

Tùy thuộc vào nhóm của bạn và mối quan tâm của bạn, bạn có thể tiếp cận. Cả hai đều có giá trị của họ, và bạn sẽ quyết định cái nào có lợi hơn cho bạn. Cả hai đều có nhược điểm là tốt, vì vậy hãy chú ý đến những số trước khi bạn nhận được một chút!

3

Cá nhân tôi bỏ qua .node_modules nhưng tôi có package.json khác nhau ở chi nhánh khác nhau và khi tôi chuyển tôi cài đặt lại phụ thuộc

1

Rõ ràng, vì bạn không có node_modules của bạn trong kho thực tế của bạn, bạn cần phải cài đặt các mô đun nút một lần nữa và mỗi nhánh có thể có yêu cầu riêng của nó, vì bạn có thể cập nhật server.js của mình với sự phụ thuộc mới và bạn cũng cần đảm bảo rằng bạn cũng có các phụ thuộc nút mới được thêm vào trong máy chủ sản xuất của mình.

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