Bạn có nên cam kết thư mục node_modules cho Git không?

Đó là một câu hỏi hay để có. Có những ưu và nhược điểm. Tôi thảo luận về chủ đề để bạn có thể đưa ra ý kiến của riêng mình.

Bạn có nên cam kết thư mục node_modules cho Git không?

Tôi đề cập đến Git nhưng điều tương tự cũng áp dụng cho bất kỳ hệ thống kiểm soát phiên bản nào mà bạn tình cờ sử dụng

Đó là một câu hỏi hay để có. Có những ưu và nhược điểm.

Tôi đề nghị mặc định làkhông phảicam kết thư mục node_modules và thay vào đó thêm nó vào.gitignoretập tin.

Bạn có thể có những nhu cầu đặc biệt làm đảo ngược quyết định này.

Tôi thảo luận về chủ đề để bạn có thể đưa ra ý kiến của riêng mình.

Dưới đây là một số lập luận ủng hộ việc không cam kết node_modules

Bạn giữ lịch sử Git của mình sạch sẽ. Khi bạn thêm một gói mới, bạn lưu trữpackage.jsonpackage-lock.jsonthay đổi tệp. Khi bạn quyết định cập nhật phiên bản gói, tất cả những gì bạn lưu trữ làpackage-lock.jsonthay đổi tập tin.

package-lock.jsonlà một tính năng tương đối mới của npm, làm mất đithu nhỏ bọclệnh được sử dụng trong quá khứ

Bạn tránh phải đặt có thể hàng trăm MB phụ thuộc vào kho lưu trữ của mình và điều này có nghĩa là theo thời gian, nó sẽ nhanh hơn để làm việc với. Chuyển các nhánh và kiểm tra mã là 2 hoạt động bị ảnh hưởng rất nhiều bởi kích thước kho lưu trữ.

Khi làm việc với các chi nhánh, bạn có thể có xung đột hợp nhất mở rộng ra ngoài mã của bạn và thay vào đó, liên quan đến mã phụ thuộc. Điều này không tốt để giải quyết và có thể khiến bạn mất nhiều thời gian. Tránh đặt

Một yêu cầu kéo hoặc hợp nhất nếu thay đổi các phụ thuộc, sẽ có nhiều tệp hơn tham gia vào quá trình. Các công cụ trở nên chậm hơn hoặc thậm chí quyết định không hiển thị toàn bộ sự khác biệt (ví dụ: GitHub)

Mô-đun nút gốc cần được biên dịch lại nếu bạn triển khai trên nền tảng khác với máy phát triển của mình (trường hợp sử dụng phổ biến: bạn phát triển trên Mac, triển khai trên Linux). Bạn cần gọinpm rebuild, làm mất đồng bộ máy chủ.

Không cam kết node_modules có nghĩa là bạn cần liệt kê tất cả các mô-đun của mình trongpackage.json(vàpackage-lock.json) như một bước bắt buộc. Điều này thật tuyệt vì bạn có thể không cần mẫn để làm như vậy và một số hoạt động npm có thể bị hỏng nếu bạn không làm như vậy.

Mẹo: không cần sử dụng phiên bản cụ thể trongpackage.jsontệp, không còn nữa kể từ khi giới thiệupackage-lock.jsontập tin.

Nếu bạn sử dụng riêngdependenciesdevDependenciesbộ, bằng cách cam kếtnode_modulesthư mục về cơ bản bạn đang cam kếtdevDependenciesvà không có cách nào (dễ dàng) để bản dựng sản xuất loại bỏ chúng.

Những lý do có thể khiến bạn phạm vào node_modules và cách giảm thiểu chúng

Annpmgói có thể bị tác giả của nó xóa khỏi sổ đăng ký npm. Nó đã xảy ra với người nổi tiếngleft-pad incident in 2016 (đọc thêm). Điều này rất hiếm khi xảy ra đối với các gói phổ biến. Nếu điều này xảy ra, bạn có thể không còn quyền truy cập vào phần chức năng cụ thể đó nữa.

Bạn cũng có thể tranh luận rằngnpmkhông được đảm bảo sẽ tồn tại vô thời hạn, nó có thể biến mất, vì vậy, một cách dễ dàng để đảm bảo có mã đầy đủ của ứng dụng của bạn trong tương lai là cam kết nó cùng với ứng dụng của bạn.

Mỗi khi bạn sử dụng một gói, hãy tạo một nhánh rẽ trên GitHub. Thỉnh thoảng, hãy cập nhật nguồn gốc (có thể được tự động hóa).

Điều này không phải lúc nào cũng thực tế vì các gói có thể có hàng chục phụ thuộc riêng của chúng.

Bạn có thể sử dụng máy chủ lưu trữ riêng cho dự án của mình và sử dụng máy chủ đó để lưu trữ tất cả các phần phụ thuộc của bạn.

Các tùy chọn bao gồm

Một lý do khác để cam kết các phụ thuộc là khả năng nhanh chóng chỉnh sửa mã, nếu bạn tìm thấy lỗi hoặc nếu bạn muốn thêm thứ gì đó vào thư viện.

Đây là một con dao hai lưỡi: nếu bạn làm như vậy, bạn sẽ mất khả năng nâng cấp gói nếu các bản phát hành mới được tạo ra và nó chỉ tốt cho các bản sửa lỗi nhanh chóng, tạm thời.

Giải pháp tối ưu là gửi một PR thực hiện những gì bạn muốn cho dự án ban đầu hoặc fork nó và sử dụng fork của bạn làm phụ thuộc.

Tải xuống miễn phí của tôiSổ tay Node.js


Các hướng dẫn nút khác: