Nên bao gồm thư mục của node_modules trong kho git

Tôi đang tự hỏi liệu chúng ta có nên theo dõi node_modules trong repo của mình hay thực hiện cài đặt npm khi kiểm tra mã không?

Câu trả lời không dễ như Alberto Zaccagni gợi ý. Nếu bạn phát triển các ứng dụng (đặc biệt là các ứng dụng doanh nghiệp), bao gồm node_modules trong git repo của bạn là một lựa chọn khả thi và lựa chọn thay thế nào bạn chọn tùy thuộc vào dự án của bạn.

Bởi vì anh ta đã tranh luận rất tốt với node_modules, tôi sẽ tập trung vào các đối số cho họ.

Hãy tưởng tượng rằng bạn vừa hoàn thành ứng dụng doanh nghiệp và bạn sẽ phải hỗ trợ nó trong 3-5 năm. Bạn chắc chắn không muốn phụ thuộc vào mô-đun npm của ai đó mà ngày mai có thể biến mất và bạn không thể cập nhật ứng dụng của mình nữa.

Hoặc bạn có các mô-đun riêng không thể truy cập từ internet và bạn không thể xây dựng ứng dụng của mình trên Internet. Hoặc có thể bạn không muốn phụ thuộc vào bản dựng cuối cùng của mình trên dịch vụ npm vì một số lý do.

Bạn có thể tìm thấy ưu và nhược điểm trong bài viết này của Addy Osmani (mặc dù đó là về Bower, nó gần như tương tự). Và tôi sẽ kết thúc bằng một trích dẫn từ trang chủ của Bower và bài viết của Addy:

Nếu bạn không cho phép một gói dự định sẽ được người khác sử dụng (ví dụ: bạn đang xây dựng một ứng dụng web), bạn phải luôn kiểm tra các gói đã cài đặt vào kiểm soát nguồn.

Chi tiết mô-đun được lưu trữ trong packages.json, đó là đủ. Không cần kiểm tra node_modules.

Mọi người thường lưu trữ node_modulestrong kiểm soát phiên bản để khóa các phụ thuộc của mô-đun, nhưng với npm cowrap không còn cần thiết nữa.

Một lời biện minh khác cho điểm này, như @ChrisCM đã viết trong bình luận:

Cũng đáng chú ý, bất kỳ mô-đun nào liên quan đến tiện ích mở rộng gốc sẽ không hoạt động kiến ​​trúc với kiến ​​trúc và cần được xây dựng lại. Cung cấp biện minh cụ thể cho KHÔNG bao gồm chúng trong repo.

Tôi khuyên bạn không nên kiểm tra trong node_modules vì các gói như PhantomJS và node-sass chẳng hạn, cài đặt nhị phân thích hợp cho hệ thống hiện tại.

Điều này có nghĩa là nếu một Dev chạy npm installtrên Linux và kiểm tra trong node_modules - nó sẽ không hoạt động đối với một Dev khác nhân bản repo trên Windows.

Tốt hơn là kiểm tra các tarball mà npm cài đặt tải xuống và chỉ npm-shrinkwrap.jsonvào chúng. Bạn có thể tự động hóa quá trình này bằng cách sử dụng thu nhỏ .

Chủ đề này khá cũ, tôi thấy. Nhưng tôi thiếu một số cập nhật cho các đối số được cung cấp ở đây do tình hình đã thay đổi trong hệ sinh thái của npm.

Tôi luôn khuyên không nên đặt node_modules dưới sự kiểm soát phiên bản. Gần như tất cả các lợi ích từ việc làm như được liệt kê trong bối cảnh câu trả lời được chấp nhận là khá lỗi thời cho đến nay.

1. Các gói đã xuất bản không thể bị thu hồi từ npm registry dễ dàng nữa. Vì vậy, bạn không phải sợ mất các phụ thuộc mà dự án của bạn đã dựa vào trước đó.

2. Việc đặt tệp pack-json.lock trong VCS sẽ giúp ích cho các phụ thuộc được cập nhật thường xuyên có thể dẫn đến các thiết lập khác nhau mặc dù dựa vào cùng một tệp pack.json.

Vì vậy, việc đặt node_modules vào VCS trong trường hợp có các công cụ xây dựng ngoại tuyến có thể được coi là trường hợp sử dụng đủ điều kiện còn lại. Tuy nhiên, node_modules thường phát triển khá nhanh. Bất kỳ cập nhật sẽ thay đổi rất nhiều tập tin. Và điều này đang ảnh hưởng đến kho lưu trữ theo những cách khác nhau. Nếu bạn thực sự xem xét ảnh hưởng lâu dài cũng có thể là một trở ngại.

Như svn của VCS tập trung yêu cầu chuyển các tệp đã cam kết và kiểm tra qua mạng sẽ chậm như địa ngục khi kiểm tra hoặc cập nhật thư mục node_modules.

Khi nói đến git, số lượng lớn các tệp bổ sung này sẽ ngay lập tức gây ô nhiễm kho lưu trữ. Hãy nhớ rằng git không theo dõi sự khác biệt giữa các phiên bản của bất kỳ tệp nào, nhưng đang lưu trữ các bản sao của một trong hai phiên bản của tệp ngay khi một ký tự thay đổi. Mỗi bản cập nhật cho bất kỳ sự phụ thuộc sẽ dẫn đến một thay đổi lớn khác. Kho git của bạn sẽ nhanh chóng phát triển rất lớn vì điều này ảnh hưởng đến các bản sao lưu và đồng bộ hóa từ xa. Nếu bạn quyết định loại bỏ node_modules khỏi kho git sau thì nó vẫn là một phần của nó vì lý do lịch sử. Nếu bạn đã phân phối kho git của mình cho một số máy chủ từ xa (ví dụ để sao lưu) thì việc dọn dẹp nó là một nhiệm vụ đau đớn và dễ bị lỗi khác mà bạn đang thực hiện.

Do đó, nếu bạn quan tâm đến các quy trình hiệu quả và muốn giữ mọi thứ "nhỏ", tôi muốn sử dụng một kho lưu trữ tạo tác riêng biệt như Nexos Rep Kho (hoặc chỉ một số máy chủ HTTP có lưu trữ ZIP) cung cấp một số bộ phụ thuộc được tải xuống trước đó để tải xuống.

Không theo dõi node_modulesvới kiểm soát nguồn là lựa chọn phù hợp vì một số mô-đun NodeJS, như trình điều khiển MongoDB NodeJS, sử dụng các tiện ích bổ sung NodeJS C ++. Các add-on này được biên dịch khi chạy npm installlệnh. Vì vậy, khi bạn theo dõi node_modulesthư mục, bạn có thể vô tình cam kết một tệp nhị phân cụ thể của hệ điều hành.

Tôi đồng ý với ivoszz rằng đôi khi rất hữu ích khi kiểm tra thư mục node_modules, nhưng ...

cảnh 1:

Một kịch bản: Bạn sử dụng gói được xóa khỏi npm. Nếu bạn có tất cả các mô-đun trong thư mục node_modules, thì đó sẽ không phải là vấn đề đối với bạn. Nếu bạn chỉ có tên gói trong gói.json, bạn không thể lấy tên đó nữa. Nếu một gói dưới 24 giờ, bạn có thể dễ dàng loại bỏ nó khỏi npm. Nếu nó cũ hơn 24 giờ, thì bạn cần liên hệ với họ. Nhưng:

Nếu bạn liên hệ với bộ phận hỗ trợ, họ sẽ kiểm tra xem nếu gỡ bỏ phiên bản gói đó của bạn sẽ phá vỡ mọi cài đặt khác. Nếu vậy, chúng tôi sẽ không loại bỏ nó.

đọc thêm

Vì vậy, cơ hội cho điều này là thấp, nhưng có kịch bản 2 ...

kịch bản 2:

Một kịch bản khác trong trường hợp này là: Bạn phát triển phiên bản doanh nghiệp của phần mềm hoặc phần mềm rất quan trọng và viết vào gói.json của bạn:

"dependencies": {
    "studpid-package": "~1.0.1"
}

Bạn sử dụng phương pháp function1(x) của gói đó.

Bây giờ các nhà phát triển gói studpid đổi tên phương thức function1(x)thành function2(x)và họ mắc lỗi ... Họ thay đổi phiên bản của gói từ 1.0.1sang 1.1.0. Đó là một vấn đề bởi vì khi bạn gọi npm installlần sau, bạn sẽ chấp nhận phiên bản1.1.0 vì bạn đã sử dụng dấu ngã ("studpid-package": "~1.0.1" ).

Gọi điện thoại function1(x) có thể gây ra lỗi và vấn đề bây giờ.

Nhưng:

Đẩy toàn bộ thư mục node_modules (thường là hơn 100 MB) vào kho lưu trữ của bạn, sẽ khiến bạn tốn dung lượng bộ nhớ. Một vài kb (chỉ gói.json) so với hàng trăm MB (pack.json & node_modules) ... Hãy suy nghĩ về nó.

Bạn có thể làm điều đó / nên nghĩ về nó nếu:

• phần mềm rất quan trọng

• nó làm bạn mất tiền khi gặp sự cố

• bạn không tin tưởng vào sổ đăng ký npm. npm được tập trung và về mặt lý thuyết có thể bị đóng cửa.

Bạn không cần phải xuất bản thư mục node_modules trong 99,9% trường hợp nếu:

• bạn phát triển một phần mềm chỉ dành cho chính mình.

• bạn đã lập trình một cái gì đó và chỉ muốn công bố kết quả trên GitHub vì người khác có thể quan tâm đến nó.

Nếu bạn không muốn node_modules có trong kho lưu trữ của mình, chỉ cần tạo một .gitignoretệp và thêm dòng node_modules.

Tôi muốn cung cấp một thay thế giữa đường.

1. Đừng thêm node_modulesvào git.
2. Sử dụng một package-lock.jsontập tin để đóng đinh các phiên bản phụ thuộc của bạn.
3. Trong CI hoặc quá trình phát hành của bạn, khi bạn phát hành một phiên bản, hãy tạo một bản sao của thư mục node_modules và sao lưu nó (ví dụ: trong bộ nhớ đám mây).

Trong trường hợp hiếm hoi mà bạn không thể truy cập NPM (hoặc các cơ quan đăng ký khác mà bạn sử dụng) hoặc một gói cụ thể trong NPM, bạn có một bản sao của node_modules và có thể tiếp tục làm việc cho đến khi bạn khôi phục quyền truy cập.

Một điều nữa cần xem xét: kiểm tra node_moduleslàm cho việc sử dụng sự khác biệt giữa dependenciesvàdevDependencies .

Mặt khác, người ta có thể nói rằng thật yên tâm khi đẩy mạnh sản xuất cùng một mã đã trải qua các thử nghiệm - bao gồm cả devDependencies.

node_modules không bắt buộc phải được đăng ký nếu phụ thuộc được đề cập trong pack.json. Bất kỳ lập trình viên nào khác có thể đơn giản nhận được nó bằng cách thực hiện cài đặt npm và npm đủ thông minh để tạo nút_modules trong thư mục làm việc của bạn cho dự án.