Tôi có nên kiểm tra node_modules để git khi tạo ứng dụng node.js trên Heroku không?


368

Tôi đã làm theo các hướng dẫn bắt đầu cơ bản cho node.js trên Heroku tại đây:

https://devcenter.heroku.com/clists/nodejs

Các hướng dẫn này không bảo bạn tạo một nút .mitignore node_modules, và do đó ngụ ý rằng node_modules nên được kiểm tra để git. Khi tôi bao gồm node_modules trong git, ứng dụng bắt đầu của tôi chạy đúng.

Khi tôi làm theo ví dụ nâng cao hơn tại:

https://devcenter.heroku.com/articles/realtime-polyglot-app-node-ruby-mongodb-socketio https://github.com/mongolab/tractorpush-server (nguồn)

Nó hướng dẫn tôi thêm node_modules vào .gitignore. Vì vậy, tôi đã loại bỏ node_modules khỏi git, thêm nó vào .gitignore, sau đó triển khai lại. Lần này việc triển khai thất bại như vậy:

-----> Heroku receiving push
-----> Node.js app detected
-----> Resolving engine versions
       Using Node.js version: 0.8.2
       Using npm version: 1.0.106
-----> Fetching Node.js binaries
-----> Vendoring node into slug
-----> Installing dependencies with npm
       Error: npm doesn't work with node v0.8.2
       Required: node@0.4 || 0.5 || 0.6
           at /tmp/node-npm-5iGk/bin/npm-cli.js:57:23
           at Object.<anonymous> (/tmp/node-npm-5iGk/bin/npm-cli.js:77:3)
           at Module._compile (module.js:449:26)
           at Object.Module._extensions..js (module.js:467:10)
           at Module.load (module.js:356:32)
           at Function.Module._load (module.js:312:12)
           at Module.require (module.js:362:17)
           at require (module.js:378:17)
           at Object.<anonymous> (/tmp/node-npm-5iGk/cli.js:2:1)
           at Module._compile (module.js:449:26)
       Error: npm doesn't work with node v0.8.2
       Required: node@0.4 || 0.5 || 0.6
           at /tmp/node-npm-5iGk/bin/npm-cli.js:57:23
           at Object.<anonymous> (/tmp/node-npm-5iGk/bin/npm-cli.js:77:3)
           at Module._compile (module.js:449:26)
           at Object.Module._extensions..js (module.js:467:10)
           at Module.load (module.js:356:32)
           at Function.Module._load (module.js:312:12)
           at Module.require (module.js:362:17)
           at require (module.js:378:17)
           at Object.<anonymous> (/tmp/node-npm-5iGk/cli.js:2:1)
           at Module._compile (module.js:449:26)
       Dependencies installed
-----> Discovering process types
       Procfile declares types -> mongod, redis, web
-----> Compiled slug size is 5.0MB
-----> Launching... done, v9

Chạy "heroku ps" xác nhận sự cố. Ok, không có vấn đề gì, vì vậy tôi đã khôi phục lại thay đổi, thêm node_module trở lại kho git và xóa nó khỏi .gitignore. Tuy nhiên, ngay cả sau khi hoàn nguyên, tôi vẫn nhận được thông báo lỗi tương tự khi triển khai nhưng bây giờ ứng dụng đang chạy lại chính xác. Chạy "heroku ps" cho tôi biết ứng dụng đang chạy.

Vì vậy, câu hỏi của tôi là những gì đúng cách để làm điều này? Bao gồm node_modules hay không? Và tại sao tôi vẫn nhận được thông báo lỗi khi tôi quay lại? Tôi đoán là kho git đang ở trạng thái xấu về phía Heroku?


10
Tôi là chủ sở hữu ngôn ngữ Node tại Heroku và câu trả lời rất đơn giản: Không. Không đăng ký node_modulesứng dụng Heroku.
hunterloftis

@hunterloftis 'Không kiểm tra node_modules vào ' hoặc 'Không kiểm tra node_modules thành '? Để làm rõ, với tư cách là chủ sở hữu ngôn ngữ Node tại Heroku, bạn có muốn chúng tôi tải lên toàn bộ nút_modules thông qua git đẩy của mình hay không? Tôi không thích do lãng phí băng thông và thực tế là Heroku sẽ có được chúng trong phần phụ trợ của cú đẩy git của tôi; tuy nhiên, tôi đã phải chỉnh sửa các tệp trong node_modules của mình theo cách thủ công để Heroku tải ứng dụng của tôi. Do đó, tôi đã phải bỏ qua node_modules trừ toàn bộ mô-đun bao gồm tệp đã chỉnh sửa của tôi để làm cho nó hoạt động.
ZStoneDPM

Câu trả lời:


400

Cập nhật lần thứ hai

Câu hỏi thường gặp không còn nữa.

Từ các tài liệu của shrinkwrap:

Nếu bạn muốn khóa các byte cụ thể có trong một gói, ví dụ để có độ tin cậy 100% về khả năng tái tạo triển khai hoặc xây dựng, thì bạn nên kiểm tra các phụ thuộc của mình vào kiểm soát nguồn hoặc theo đuổi một số cơ chế khác có thể xác minh nội dung chứ không phải phiên bản.

Shannon và Steven đã đề cập đến điều này trước đây nhưng tôi nghĩ, nó nên là một phần của câu trả lời được chấp nhận.


Cập nhật

Nguồn được liệt kê cho các khuyến nghị dưới đây đã được cập nhật . Họ không còn đề nghị node_modulesthư mục được cam kết.

Thông thường, không. Cho phép npm để giải quyết phụ thuộc cho các gói của bạn.

Đối với các gói bạn triển khai, chẳng hạn như các trang web và ứng dụng, bạn nên sử dụng npm shrwrap để khóa cây phụ thuộc đầy đủ của bạn:

https://docs.npmjs.com/cli/shrinkwrap


Bài gốc

Để tham khảo, npm FAQ trả lời rõ ràng câu hỏi của bạn:

Kiểm tra node_modules vào git để biết những thứ bạn triển khai, chẳng hạn như trang web và ứng dụng. Không kiểm tra node_modules vào git cho các thư viện và mô-đun dự định sẽ được sử dụng lại. Sử dụng npm để quản lý các phụ thuộc trong môi trường dev của bạn, nhưng không phải trong các tập lệnh triển khai của bạn.

và để có lý do chính đáng cho việc này, hãy đọc bài đăng của Mikeal Rogers về điều này .


Nguồn: https://docs.npmjs.com/misc/faq#should-i-check-my-node-modules-folder-into-git


13
Điều này không đúng - thực tế nó là ý tưởng rất tồi. Nếu bạn đang phát triển trên Windows thì triển khai trên Linux, bạn sẽ cần xây dựng lại node_modules khi bạn triển khai. Có nghĩa là - hỗn loạn. Rất nhiều tập tin sửa đổi, và không biết phải làm gì.
dùng3690202

8
Điều đó là không thể - một số nhà phát triển của chúng tôi phát triển các cửa sổ nhắm mục tiêu, một số khác nhắm mục tiêu linux, nhưng cùng một cơ sở mã. Cách tiếp cận tốt nhất sẽ là không cam kết các mô-đun nút - rất tiếc.
dùng3690202

7
@ user3690202 Âm thanh như bạn có một trường hợp rất độc đáo, thay vì quy tắc, vì vậy nói "điều này không chính xác" có lẽ là một lời nói quá. Phải nói rằng, không chắc trường hợp sử dụng chính xác của bạn là gì, nhưng tôi không thể nghĩ ra bất kỳ lý do nào để sử dụng cả windows và linux để phát triển. Bám sát một và chạy thử nghiệm hoặc QA trên tất cả các nền tảng mà bạn hỗ trợ.
Kostia

16
@Kostia Trường hợp sử dụng của chúng tôi là một trường hợp khá phổ biến. Chúng tôi là tình nguyện viên và sử dụng máy móc của chúng tôi, không phải công ty. Có vẻ như một tình huống khá phổ biến đối với nguồn mở.
Adam

4
@Adam tiếp tuyến, bạn có thể thêm các tập tin được biên dịch vào .gitignore? Theo cách đó, nguồn nằm trong git, và bất kỳ thành phần được biên dịch nào cũng không, tương tự như cách disthoặc outputcác thư mục được phân bổ trong các dự án grunt và gulp.
Kostia

160

Mối quan tâm lớn nhất của tôi khi không kiểm tra node_modulesgit là 10 năm sau, khi ứng dụng sản xuất của bạn vẫn được sử dụng, npm có thể không xuất hiện. Hoặc npm có thể bị hỏng; hoặc các nhà bảo trì có thể quyết định xóa thư viện mà bạn dựa vào kho lưu trữ của họ; hoặc phiên bản bạn sử dụng có thể được cắt bớt.

Điều này có thể được giảm thiểu với các trình quản lý repo như maven, bởi vì bạn luôn có thể sử dụng Nexus hoặc Artifactory cục bộ của riêng bạn để duy trì một bản sao với các gói bạn sử dụng. Theo tôi hiểu, một hệ thống như vậy không tồn tại trong npm. Điều tương tự cũng xảy ra với các nhà quản lý thư viện phía khách hàng như Bower và Jamjs.

Nếu bạn đã cam kết các tệp với git repo của riêng mình, thì bạn có thể cập nhật chúng khi bạn muốn và bạn có thể thoải mái với các bản dựng lặp lại và kiến ​​thức rằng ứng dụng của bạn sẽ không bị hỏng do một số hành động của bên thứ ba.


10
Rất nhiều lựa chọn ngày hôm nay: Nexus ( issues.sonatype.org/browse/NEXUS-5852 ), Artifactory ( jfrog.com/jira/browse/RTFACT-5143 ), npm_lazy ( github.com/mixu/npm_lazy ), NPM-lazy- gương ( npmjs.org/package/npm-lazy-mirror ), v.v.
Johann

4
Trích dẫn từ npmjs FAQ: "Nếu bạn bị hoang tưởng về việc phụ thuộc vào hệ sinh thái npm, bạn nên chạy một máy nhân bản npm riêng tư hoặc bộ đệm riêng.". Tôi nghĩ rằng điều này chỉ ra vấn đề bạn đang đề cập, phải không?
Taylan

3
Một trường hợp trong các nhà phát triển
nguyên mẫu

2
Npm sẽ không biến mất trong đêm, vì vậy lợi ích không thực sự kết hợp tốt với sự mất đi sự rõ ràng trong lịch sử cam kết và kích thước gói lớn của bạn. Nếu ai đó đang xây dựng một ứng dụng mà họ nghĩ sẽ vẫn hoạt động sau 10 năm nữa, thật hợp lý khi hy vọng rằng nó sẽ nhận được rất nhiều bảo trì trên đường đi. Quan điểm về việc ngừng hoạt động NPM là một lập luận tốt hơn nhiều, mặc dù có lẽ có nhiều cách tốt hơn để giảm thiểu rủi ro đó hơn là cam kết với nguồn.
Sam P

3
Ngay cả một tháng sau cũng nguy hiểm nếu bạn không cam kết phụ thuộc (tốt nhất là trong một kho lưu trữ riêng). Khi tôi tìm thấy vào một buổi sáng khi tôi nhân bản một trong các dự án của mình và tìm thấy một phiên bản gói đã bị xóa khỏi npm. Tôi đã dành nửa ngày để thay đổi tất cả các phiên bản phụ thuộc xếp tầng của mình để có được cập nhật npm để hoạt động và xây dựng lại.
Richard

67

Bạn không nên đưanode_modules vào .gitignore(hoặc đúng hơn là bạn nên đưa node_modules vào nguồn của mình được triển khai cho Heroku).

Nếu node_modules:

  • tồn tại sau đó npm installsẽ sử dụng các lib được trả thù đó và sẽ xây dựng lại bất kỳ phụ thuộc nhị phân nào với npm rebuild.
  • không tồn tại sau đó npm installsẽ phải tự tìm nạp tất cả các phụ thuộc mà thêm thời gian vào bước biên dịch sên.

Xem nguồn buildpack của Node.js để biết các bước chính xác này

Tuy nhiên, lỗi ban đầu có vẻ không tương thích giữa các phiên bản npmnode. Đó là một ý tưởng tốt để luôn luôn đặt rõ ràng enginesphần của bạn packages.jsontheo hướng dẫn này để tránh các loại tình huống:

{
  "name": "myapp",
  "version": "0.0.1",
  "engines": {
    "node": "0.8.x",
    "npm":  "1.1.x"
  }
}

Điều này sẽ đảm bảo tính chẵn lẻ dev / prod và giảm khả năng xảy ra các tình huống như vậy trong tương lai.


Cảm ơn sự giúp đỡ của Ryan. Điều đó đã giúp tôi vượt qua lỗi phiên bản npm nhưng bây giờ nó không thành công khi biên dịch gói redis. Thông báo lỗi là "OSError: [Errno 2] Không có tệp hoặc thư mục như vậy: '/ Users / Jason / tastemade / tastebase / node_modules / redis-url / node_modules / redis / node_modules / hiredis / build'". Có vẻ như nó đang sử dụng một đường dẫn từ hộp cục bộ của tôi trên các máy chủ heroku. Có một số tệp nhất định trong node_modules tôi cần thêm vào .gitignore không?
Jason Griffin

Tôi không chắc điều gì đang xảy ra với thư viện cụ thể đó, nhưng tôi sẽ thử loại trừ node_modules khỏi git trong trường hợp này và xem liệu điều đó có giúp ích gì không (buộc npm phải tự tìm nạp mọi thứ và đảm bảo môi trường xây dựng mới).
Ryan Daigle

@RyanDaigle Thực hành tốt nhất hiện nay (tháng 11 năm 2013) được đề xuất bởi cả npm ( npmjs.org/doc/iêu ) và heroku ( devcenter.heroku.com/articles/ .) Là kiểm tra trong node_modules để git. Bạn sẽ cập nhật câu trả lời của bạn (vì nó có hóa đơn hàng đầu)?
Tim Diggins

Trong khi đẩy tới heroku, bạn sẽ nhận được đầu ra "-----> thư mục bộ đệm node_modules cho các bản dựng trong tương lai". Điều này là để rút ngắn quá trình biên dịch sên trong tương lai.
ph3nx

Tôi có một vấn đề là filepath node_modules quá dài để cam kết. Git sẽ không tìm thấy các tập tin.
Mã Pharaoh

22

Tôi sẽ để lại điều này sau bình luận này: Tôi có nên kiểm tra node_modules để git khi tạo ứng dụng node.js trên Heroku không?

Nhưng stackoverflow đã định dạng nó kỳ lạ. Nếu bạn không có các máy giống hệt nhau và đang kiểm tra trong node_modules, hãy thực hiện .gitignore trên các tiện ích mở rộng gốc. .Gitignore của chúng tôi trông giống như:

# Ignore native extensions in the node_modules folder (things changed by npm rebuild)
node_modules/**/*.node
node_modules/**/*.o
node_modules/**/*.a
node_modules/**/*.mk
node_modules/**/*.gypi
node_modules/**/*.target
node_modules/**/.deps/
node_modules/**/build/Makefile
node_modules/**/**/build/Makefile

Kiểm tra điều này bằng cách kiểm tra mọi thứ trước, sau đó yêu cầu một nhà phát triển khác thực hiện như sau:

rm -rf node_modules
git checkout -- node_modules
npm rebuild
git status

Đảm bảo rằng không có tập tin thay đổi.


Chỉ cần thêm điều này. Giải quyết vấn đề của tôi. Các cửa sổ github liên tục gặp sự cố khi cố gắng vượt qua hơn 7000 tệp node_module: /
Batman

10

Tôi tin rằng npm installkhông nên chạy trong môi trường sản xuất. Có một số điều có thể sai - mất điện npm, tải xuống các phụ thuộc mới hơn (dường như thu nhỏ đã giải quyết điều này) là hai trong số đó.

Mặt khác, node_moduleskhông nên cam kết trên git. Ngoài kích thước lớn của chúng, các cam kết bao gồm chúng có thể trở nên mất tập trung.

Các giải pháp tốt nhất sẽ là: npm installnên chạy trong môi trường CI tương tự như môi trường sản xuất. Tất cả các bài kiểm tra sẽ chạy và một tệp phát hành được nén sẽ được tạo sẽ bao gồm tất cả các phụ thuộc.


Tại sao bạn có một bước chạy trên CI mà sẽ không chạy như một phần của việc triển khai của bạn? Điều này có nghĩa là bạn không có sự tương đương giữa hai hệ thống! Như câu trả lời đã nói ở trên - hãy cam kết thư mục chỉ cần bỏ qua các tiện ích mở rộng riêng, theo cách đó bạn được bảo vệ cho những thứ như mất điện
npm

1
Cám ơn bạn đã góp ý. Tôi tin rằng node_modules chạy trong máy chủ sản xuất của bạn nên được tạo từ cài đặt npm, chứ không phải từ bất cứ điều gì các nhà phát triển đã cam kết. Thư mục node_modules của dev không nhất thiết phải khớp với nội dung của gói.json.
dùng2468170

8

Tôi đã sử dụng cả hai thư mục node_modules và thu nhỏ. Cả hai giải pháp đều không làm tôi hạnh phúc.

Tóm lại: node_modules đã cam kết thêm quá nhiều tiếng ồn vào kho lưu trữ.
Và shrwrap.json không dễ quản lý và không có gì đảm bảo rằng một số dự án thu nhỏ sẽ được xây dựng trong một vài năm.

Tôi thấy rằng Mozilla đang sử dụng một kho lưu trữ riêng cho một trong các dự án của họ https://github.com/mozilla-b2g/gaia-node-modules

Vì vậy, tôi không mất nhiều thời gian để thực hiện ý tưởng này trong một công cụ CLI nút https://github.com/bestander/npm-git-lock

Ngay trước mỗi bản dựng, hãy thêm
npm-git-lock --repo [git@bitbucket.org: your / own / node_modules / git / repository.git]

Nó sẽ tính toán hàm băm của gói.json của bạn và sẽ kiểm tra nội dung của node_modules từ một repo từ xa, hoặc, nếu đó là bản dựng đầu tiên cho gói.json này, sẽ làm sạch npm installvà đẩy kết quả đến repo từ xa.


5

Điều làm việc cho tôi là rõ ràng thêm một phiên bản npm vào pack.json ("npm": "1.1.x") và KHÔNG kiểm tra trong node_modules vào git. Việc triển khai có thể chậm hơn (vì nó tải các gói mỗi lần), nhưng tôi không thể biên dịch các gói khi chúng được kiểm tra. Heroku đang tìm kiếm các tệp chỉ tồn tại trên hộp cục bộ của tôi.


Nếu bạn cảm thấy câu trả lời của tôi là đúng, xin vui lòng chấp nhận nó? Cảm ơn bạn!
Ryan Daigle

Trong trường hợp điều này vẫn còn đang tranh luận, tôi sẽ xem bài đăng stackoverflow này gần như là một bản sao của câu hỏi của bạn ở trên: stackoverflow.com/questions/11459733/. Về cơ bản, có vẻ như quy ước là kiểm tra trong node_modules và quản lý các phiên bản của bạn của các mô-đun cục bộ. Điều này có vẻ khá hợp lý và có lẽ lời giải thích ngắn gọn nhất là đây: mikealrogers.com/posts/nodemodules-in-git.html Chúc may mắn!
warriorpostman

3

Thay vì kiểm tra trong node_modules, hãy tạo tệp pack.json cho ứng dụng của bạn.

Tệp pack.json chỉ định các phụ thuộc của ứng dụng của bạn. Heroku sau đó có thể nói với npm để cài đặt tất cả các phụ thuộc đó. Hướng dẫn mà bạn đã liên kết để chứa một phần trên các tệp pack.json.


Tôi có một gói.json. Nó có các thông tin sau: {"name": "nút-example", "phiên bản": "0.0.1", "phụ thuộc": {"express": "2.5.x", "redis-url": "0.1. 0 "," mongodb ":"> = 0.9.9 "}," engine ": {" nút ":" 0.8.x "}}
Jason Griffin

Tôi đã làm trên hộp cục bộ của mình để tạo thư mục node_modules. Đó là những gì tôi đã kiểm tra, sau đó xóa, sau đó thêm lại.
Jason Griffin

Sau khi xem hướng dẫn nhiều hơn, có vẻ như họ đang cam kết node_modules. Trong trường hợp đó, tôi không chắc có cách nào để không cam kết node_modules không. Xin lỗi
matzahboy

3

Tôi đang sử dụng giải pháp này:

  1. Tạo kho lưu trữ riêng biệt giữ node_modules. Nếu bạn có các mô đun gốc nên được xây dựng cho nền tảng cụ thể thì hãy tạo kho lưu trữ riêng cho từng nền tảng.
  2. Đính kèm các kho lưu trữ này vào kho dự án của bạn với git submodule:

git submodule add .../your_project_node_modules_windows.git node_modules_windows

git submodule add .../your_project_node_modules_linux_x86_64 node_modules_linux_x86_64

  1. Tạo liên kết từ nền tảng cụ thể node_modulesđến node_modulesthư mục và thêm node_modulesvào .gitignore.
  2. Chạy đi npm install.
  3. Cam kết thay đổi kho lưu trữ mô hình con.
  4. Cam kết thay đổi kho dự án của bạn.

Vì vậy, bạn có thể dễ dàng chuyển đổi giữa node_modulescác nền tảng khác nhau (ví dụ: nếu bạn đang phát triển trên OS X và triển khai lên Linux).


3

Từ https://web.archive.org/web/20150212165006/http://www.futurealoof.com/posts/nodemodules-in-git.html :

Chỉnh sửa: Liên kết ban đầu là liên kết này nhưng bây giờ đã chết. Cảm ơn @Flavio đã chỉ ra nó.

Tóm lại.

  • Chỉ kiểm tra node_modules cho các ứng dụng bạn triển khai, không sử dụng các gói bạn có thể sử dụng lại.
  • Bất kỳ phụ thuộc được biên dịch nào cũng phải kiểm tra nguồn của chúng, không phải các mục tiêu biên dịch và $ npm sẽ được xây dựng lại khi triển khai.

Phân yêu thich của tôi:

Tất cả những người bạn đã thêm node_modules vào gitignore của bạn, loại bỏ thứ rác rưởi đó, hôm nay , đó là một tạo tác của thời đại mà tất cả chúng ta đều rất vui khi bỏ lại phía sau. Thời đại của các mô-đun toàn cầu đã chết.


Trang web bạn liên kết dường như đã hết hạn và hiện đầy quảng cáo lừa đảo. Tôi ước những quảng cáo đó là "hiện vật của một thời đại mà tất cả chúng ta đều quá hạnh phúc khi bỏ lại phía sau".
Flavio Copes

1
@FlavioCopes Cập nhật câu trả lời của tôi với liên kết từ Wayback Machine.
Benjamin Crouzier

2

http://nodejs.org/api/modules.html

Nút [...] bắt đầu tại thư mục mẹ của mô-đun hiện tại, đồng thời thêm /node_modulesvà cố gắng tải mô-đun từ vị trí đó.

Nếu nó không được tìm thấy ở đó, thì nó sẽ chuyển đến thư mục cha, và cứ thế , cho đến khi gốc của cây được chạm tới.

Nếu bạn đang sử dụng các mô-đun của riêng mình cho ứng dụng của mình, bạn có thể giữ các mô-đun đó ( và chỉ những mô-đun đó ) trong ứng dụng của mình /node_modules. Và chuyển tất cả các phụ thuộc khác vào thư mục cha.

Trường hợp sử dụng này khá tuyệt vời, nó cho phép bạn giữ các mô-đun bạn đã tạo riêng cho ứng dụng của mình với ứng dụng của bạn và không làm lộn xộn ứng dụng của bạn với các phụ thuộc có thể được cài đặt sau này.


1

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ản 1.1.0vì bạn đã sử dụng dấu ngã ( "studpid-package": "~1.0.1").

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


Đẩ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.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.