Sự khác biệt giữa các phụ thuộc, devDependencies và peDependencies trong tệp npm pack.json là gì?


2029

Tài liệu này trả lời câu hỏi của tôi rất kém. Tôi không hiểu những lời giải thích đó. Ai đó có thể nói bằng những từ đơn giản hơn? Có thể với các ví dụ nếu khó chọn từ đơn giản?

EDIT cũng được thêm vào peerDependencies, có liên quan chặt chẽ và có thể gây nhầm lẫn.


48
Lưu ý cũng có optionalDependenciesngay bây giờ.
Aidan Feldman

118
@AidanFeldman "tùy chọn phụ thuộc" là oxymoron của tôi trong ngày
Nick Bull

1
tài liệu npm nói: "phụ thuộc": Gói yêu cầu của ứng dụng của bạn trong sản xuất. "devDependencies": Các gói chỉ cần thiết cho phát triển và thử nghiệm cục bộ. xem link: docs.npmjs.com/ từ
Deke

Câu trả lời:


2365

Tóm tắt những khác biệt về hành vi quan trọng:

  • dependencies được cài đặt trên cả hai:

    • npm install từ một thư mục chứa package.json
    • npm install $package trên bất kỳ thư mục khác
  • devDependencies Chúng tôi:

    • cũng được cài đặt trên npm installmột thư mục chứa package.json, trừ khi bạn vượt qua --productioncờ (đi lên câu trả lời của Gayan Charith ).
    • không được cài đặt trên npm install "$package"bất kỳ thư mục nào khác, trừ khi bạn cung cấp cho nó --devtùy chọn.
    • không được cài đặt quá cảnh.
  • peerDependencies:

    • trước 3.0: luôn được cài đặt nếu thiếu và gây ra lỗi nếu nhiều phiên bản phụ thuộc không tương thích sẽ được sử dụng bởi các phụ thuộc khác nhau.
    • dự kiến ​​bắt đầu vào ngày 3.0 (chưa được kiểm tra): đưa ra cảnh báo nếu thiếu npm installvà bạn phải tự mình giải quyết sự phụ thuộc. Khi chạy, nếu thiếu phụ thuộc, bạn sẽ gặp lỗi (được đề cập bởi @nextgentech )
  • Độ biến đổi (được đề cập bởi Ben Hutchison ):

    • dependencies được cài đặt liên tục: nếu A yêu cầu B và B yêu cầu C, thì C được cài đặt, nếu không, B không thể hoạt động và A.

    • devDependencieskhông được cài đặt quá cảnh. Ví dụ: chúng ta không cần kiểm tra B để kiểm tra A, vì vậy các phụ thuộc kiểm tra của B có thể bị bỏ qua.

Các tùy chọn liên quan không được thảo luận ở đây:

sự phụ thuộc

dependenciesđược yêu cầu để chạy, devDependencieschỉ để phát triển, ví dụ: kiểm tra đơn vị, chuyển mã từ CoffeeScript sang JavaScript, thu nhỏ, ...

Nếu bạn định phát triển một gói, bạn tải xuống (ví dụ như thông qua git clone), đi đến thư mục gốc chứa package.jsonvà chạy:

npm install

Vì bạn có nguồn thực tế, rõ ràng là bạn muốn phát triển nó, do đó, theo mặc định, cả hai dependencies(tất nhiên, vì bạn phải chạy để phát triển) và devDependencyphụ thuộc cũng được cài đặt.

Tuy nhiên, nếu bạn chỉ là người dùng cuối chỉ muốn cài đặt gói để sử dụng gói đó, bạn sẽ thực hiện từ bất kỳ thư mục nào:

npm install "$package"

Trong trường hợp đó, thông thường bạn không muốn phụ thuộc phát triển, vì vậy bạn chỉ cần lấy những gì cần thiết để sử dụng gói : dependencies.

Nếu bạn thực sự muốn cài đặt các gói phát triển trong trường hợp đó, bạn có thể đặt devtùy chọn cấu hình true, có thể từ dòng lệnh là:

npm install "$package" --dev

Tùy chọn này falsetheo mặc định vì đây là trường hợp ít phổ biến hơn nhiều.

đồng đẳng

(Đã kiểm tra trước 3.0)

Nguồn: https://nodejs.org/en/blog/npm/peer-dependencies/

Với các phụ thuộc thông thường, bạn có thể có nhiều phiên bản của phụ thuộc: đơn giản là nó được cài đặt bên trong node_modulesphần phụ thuộc.

Ví dụ, nếu dependency1dependency2cả hai phụ thuộc vào dependency3các phiên bản khác nhau, cây dự án sẽ trông như sau:

root/node_modules/
                 |
                 +- dependency1/node_modules/
                 |                          |
                 |                          +- dependency3 v1.0/
                 |
                 |
                 +- dependency2/node_modules/
                                            |
                                            +- dependency3 v2.0/

Tuy nhiên, các plugin là các gói thường không yêu cầu gói khác, được gọi là máy chủ trong ngữ cảnh này. Thay thế:

  • bổ sung được yêu cầu bởi máy chủ lưu trữ
  • plugin cung cấp một giao diện chuẩn mà chủ nhà mong muốn tìm thấy
  • chỉ có máy chủ sẽ được người dùng gọi trực tiếp, do đó phải có một phiên bản duy nhất của nó.

Ví dụ, nếu dependency1dependency2ngang hàng phụ thuộc vào dependency3, cây dự án sẽ trông như sau:

root/node_modules/
                 |
                 +- dependency1/
                 |
                 +- dependency2/
                 |
                 +- dependency3 v1.0/

Điều này xảy ra mặc dù bạn không bao giờ đề cập đến dependency3trong package.jsontập tin của bạn .

Tôi nghĩ rằng đây là một ví dụ của mẫu thiết kế Inversion of Control .

Một ví dụ mẫu về sự phụ thuộc ngang hàng là Grunt, máy chủ lưu trữ và các plugin của nó.

Ví dụ: trên một plugin Grunt như https://github.com/gruntjs/grunt-contrib-uglify , bạn sẽ thấy rằng:

  • grunt là một peer-dependency
  • chỉ require('grunt')có ở dưới tests/: nó không thực sự được sử dụng bởi chương trình.

Sau đó, khi người dùng sẽ sử dụng một plugin, anh ta sẽ ngầm yêu cầu plugin từ Gruntfilebằng cách thêm một grunt.loadNpmTasks('grunt-contrib-uglify')dòng, nhưng đó là gruntngười dùng sẽ gọi trực tiếp.

Điều này sẽ không hoạt động sau đó nếu mỗi plugin yêu cầu một phiên bản Grunt khác nhau.

Hướng dẫn sử dụng

Tôi nghĩ rằng tài liệu trả lời câu hỏi khá tốt, có thể bạn không đủ quen thuộc với nút / trình quản lý gói khác. Tôi có lẽ chỉ hiểu nó bởi vì tôi biết một chút về Ruby bundler.

Dòng chính là:

Những thứ này sẽ được cài đặt khi thực hiện liên kết npm hoặc cài đặt npm từ thư mục gốc của gói và có thể được quản lý như mọi tham số cấu hình npm khác. Xem npm-config (7) để biết thêm về chủ đề.

Và sau đó dưới npm-config (7) tìm dev:

Default: false
Type: Boolean

Install dev-dependencies along with packages.

5
Ah. Tôi thấy tôi đã hiểu lầm. Câu trả lời của bạn đọc như thể npm install packagelà một lệnh bạn sử dụng để cài đặt tất cả các gói không phụ thuộc vào dev, hơn là những gì tôi nghĩ bây giờ, đó là 'cài đặt gói được gọi là [gói]', đó là cách tôi nghĩ nó hoạt động trước khi đọc nó Nếu tôi là bạn, tôi sẽ chỉnh sửa để nói [tên gói] cho thấy rõ ý của bạn là 'tên-tên-đây'.
Tom W

184
Điều đó thật tuyệt! Tôi chưa bao giờ nhận ra, nhưng câu trả lời này đã dạy tôi rằng sự khác biệt phụ thuộc so với devDependencies chỉ được áp dụng nếu bạn sẽ xuất bản gói npm. Nếu bạn chỉ đang làm việc trên một ứng dụng hoặc trang web, thì nó không quá quan trọng. Cảm ơn!
jedd.ahyoung

3
Bài đăng này cần được cập nhật để phản ánh peerDependencieshành vi đã thay đổi trong npm @ 3 sắp tới. Từ blog.npmjs.org/post/110924823920/npm-weekly-5 : "Chúng tôi sẽ không tự động tải xuống phụ thuộc ngang hàng nữa. Thay vào đó, chúng tôi sẽ cảnh báo bạn nếu phụ thuộc ngang hàng chưa được cài đặt. Điều này yêu cầu bạn để tự giải quyết mâu thuẫn phụ thuộc vào chính mình, nhưng về lâu dài, điều này sẽ làm giảm khả năng bạn sẽ gặp khó khăn với các phụ thuộc của gói hàng. "
nextgentech

8
Ngoài ra, devDependencies không được cài đặt liên tục bởi các gói phụ thuộc. Ví dụ: gói A phụ thuộc vào gói B. Gói B phụ thuộc vào gói C và B cũng phụ thuộc vào gói D. Nếu bạn chạy npm installtừ gói A, bạn sẽ nhận được B và C chứ không phải D.
Ben Hutchison

9
Điều quan trọng cần lưu ý devDependencieslà không được cài đặt khi NODE_ENVđược đặt thành production.
Augusto Franzoia

491

Nếu bạn không muốn cài đặt devDependencies, bạn có thể sử dụng npm install --production


1
npm install --save là dành cho phần mềm phụ thuộc?
Vamsi Pavan Mahesh

19
cài đặt npm sẽ cài đặt tất cả các phụ thuộc. Cờ --save được sử dụng khi bạn muốn thêm mô-đun cụ thể vào pack.json. ví dụ: - npm install uglify --save sẽ cài đặt uglify trong thư mục dự án của bạn và thêm uglify vào dự án, tệp pack.json.
Gayan Charith

6
Và bởi vì chúng ta đang nói về devDependencies, bạn có thể sử dụng --save-dev để lưu mô-đun mới dưới dạng devDependency. Ví dụ: npm cài đặt uglify --save-dev
Mykaelos

9
Kể từ npm 5, --savetùy chọn không còn cần thiết nữa. Nếu bạn thực hiện "npm install my-pack", nó sẽ thêm gói của tôi dưới dạng phụ thuộc trong package.jsontệp của bạn .
Martin Carel

chỉ cần cài đặt npm
sultan aslam

116

Ví dụ, mocha thường là một devDepency, vì thử nghiệm không cần thiết trong sản xuất, trong khi express sẽ là một phụ thuộc.


4
Tôi sẽ nghiêng về việc đặt thử nghiệm như một sự phụ thuộc vì bạn có thể muốn chạy tự kiểm tra trước khi khởi chạy máy chủ sản xuất

47
Thay vào đó, tôi khuyên bạn nên sử dụng một dịch vụ tích hợp liên tục như Hudson hoặc CircleCI để chạy thử nghiệm của bạn và sau đó triển khai vào sản xuất nếu chúng vượt qua.
Dan Kohn

1
Việc kiểm tra máy chủ thực tế vẫn có thể có liên quan vì máy chủ CI có thể khác với máy chủ prod và sự khác biệt này có thể ngăn ứng dụng khởi động ...
Nicole

2
@Nicole tại sao bạn sẽ làm cho máy chủ dàn của bạn không giống nhau về cấu hình với sản phẩm của bạn?
Lucas

1
Sau đó, một lần nữa, việc thêm các phụ thuộc kiểm tra vì các phụ thuộc thông thường giới thiệu một loạt các thư viện bổ sung, mỗi thư viện có thể thất bại theo một cách nào đó. Tôi sẽ nghiêng (chơi chữ!) Về phía các máy chủ sản xuất trọng lượng nhẹ với càng ít mã trên chúng càng tốt. Hãy nhớ rằng, mã tốt nhất là không có mã!
Stijn de Witt

69

phụ thuộc Các phụ
thuộc mà dự án của bạn cần chạy, giống như một thư viện cung cấp các hàm mà bạn gọi từ mã của mình.
Chúng được cài đặt liên tục (nếu A phụ thuộc vào B phụ thuộc vào C, npm cài đặt trên A sẽ cài đặt B và C).
Ví dụ: lodash: dự án của bạn gọi một số hàm lodash.

devDependencies
Phụ thuộc bạn chỉ cần trong quá trình phát triển hoặc phát hành, như trình biên dịch lấy mã của bạn và biên dịch nó thành javascript, khung kiểm tra hoặc trình tạo tài liệu.
Chúng không được cài đặt liên tục (nếu A phụ thuộc vào B dev-phụ thuộc vào C, npm cài đặt trên A sẽ chỉ cài đặt B).
Ví dụ: grunt: dự án của bạn sử dụng grunt để tự xây dựng.

ngang hàng Các
phụ thuộc mà dự án của bạn nối vào hoặc sửa đổi, trong dự án mẹ, thường là một plugin cho một số thư viện hoặc công cụ khác. Nó chỉ nhằm mục đích kiểm tra, đảm bảo rằng dự án mẹ (dự án sẽ phụ thuộc vào dự án của bạn) có sự phụ thuộc vào dự án mà bạn nối vào. Vì vậy, nếu bạn tạo một plugin C có thêm chức năng cho thư viện B, thì ai đó tạo dự án A sẽ cần phải có sự phụ thuộc vào B nếu họ có sự phụ thuộc vào C.
Họ không được cài đặt (trừ khi npm <3), họ chỉ kiểm tra
Ví dụ: grunt: dự án của bạn thêm chức năng cho grunt và chỉ có thể được sử dụng cho các dự án sử dụng grunt.

Tài liệu này giải thích các phụ thuộc ngang hàng thực sự tốt: https://nodejs.org/en/blog/npm/peer-dependencies/

Ngoài ra, tài liệu npm đã được cải thiện theo thời gian và hiện có giải thích tốt hơn về các loại phụ thuộc khác nhau: https://github.com/npm/cli/blob/latest/doc/files/package.json.md#devdependencies


63

Để lưu gói vào gói.json dưới dạng phụ thuộc dev:

npm install "$package" --save-dev

Khi bạn chạy npm installnó sẽ cài đặt cả hai devDependenciesdependencies. Để tránh cài đặt devDependencieschạy:

npm install --production

3
bạn cũng có thể sử dụng: npm i -S
Maysara Alhindi

36

Có một số mô-đun và gói chỉ cần thiết cho phát triển, không cần thiết trong sản xuất. Giống như nó nói trong tài liệu :

Nếu ai đó đang có kế hoạch tải xuống và sử dụng mô-đun của bạn trong chương trình của họ, thì có lẽ họ không muốn hoặc không cần tải xuống và xây dựng khung kiểm tra hoặc tài liệu bên ngoài mà bạn sử dụng. Trong trường hợp này, tốt nhất là liệt kê các mục bổ sung này trong hàm băm devDependencies.


Điều gì xảy ra nếu bạn chỉ chạy tệp bundle.js khi sản xuất? Bạn có thực sự cần những phụ thuộc?
RegarBoy

Nếu bạn đang chạy bundle.js trên máy chủ, bạn đang thực hiện gói web phía máy chủ hoặc một cái gì đó ... Vui lòng kiểm tra xem đó có phải là vì nó thường không và thực sự phải mất rất nhiều công việc để chạy chính xác (tôi biết vì tôi đã làm điều đó). Tôi nghi ngờ bundle.js của bạn chỉ được phục vụ cho các trình duyệt và chứa mã phía máy khách.
Stijn de Witt

16

Một lời giải thích đơn giản làm cho nó rõ ràng hơn với tôi là:

Khi bạn triển khai ứng dụng của mình, các mô-đun phụ thuộc cần được cài đặt hoặc ứng dụng của bạn sẽ không hoạt động. Các mô-đun trong devDependencies không cần phải được cài đặt trên máy chủ sản xuất vì bạn không phát triển trên máy đó. liên kết


2
Vì vậy, nếu chúng tôi đang tạo trang web và trong phiên bản prod, tất cả các lib sẽ được nhập vào vendor.js, tất cả các dep của chúng tôi sẽ là dev deps nếu mã được biên dịch được đưa vào repo? Và nó nên được cam kết, vì điều khác lạ là bạn phải biên dịch mô-đun, không chỉ cài đặt nó (và thử nghiệm cũng ở đâu đó vì bất kỳ thay đổi nào trong các mô hình con có thể dẫn đến hồi quy) ...
Qwertiy

Câu trả lời tuyệt vời, nhưng có một câu hỏi? Webpack có thể xây dựng một gói bị hỏng không? Tôi đoán là các gói devDependencies sẽ không hoạt động trong phiên bản sản phẩm, webpack -pý tôi là. hãy trả lời câu hỏi của tôi
AmerllicA

Nếu có bất kỳ vấn đề nào trong khi xây dựng sản xuất, quy trình triển khai của bạn phải được thiết kế theo cách hiển thị lỗi tại thời điểm xây dựng và không đẩy mã bị hỏng sang sản xuất (ví dụ: bạn có thể thử Jenkins). Dù sao đi nữa, không cần phải cài đặt trên máy chủ sản xuất.
Jyoti Duhan

và những gì về phụ thuộc ngang hàng?
dev27

13

Tôi muốn thêm vào câu trả lời của tôi về những giải thích phụ thuộc này

  • dependencies được sử dụng để sử dụng trực tiếp trong cơ sở mã của bạn, những thứ thường kết thúc trong mã sản xuất hoặc các đoạn mã
  • devDependencies được sử dụng cho quá trình xây dựng, các công cụ giúp bạn quản lý cách mã kết thúc sẽ kết thúc, các mô-đun kiểm tra của bên thứ ba, (ví dụ: công cụ gói webpack)

Còn tài sản css thì sao?
Brian Zelip

8

Nói ngắn gọn

  1. Phụ thuộc - npm install <package> --save-prodcài đặt các gói theo yêu cầu của ứng dụng của bạn trong môi trường sản xuất.

  2. DevDependencies - npm install <package> --save-devcài đặt các gói chỉ cần cho phát triển và thử nghiệm cục bộ

  3. Chỉ cần gõ npm installcài đặt tất cả các gói được đề cập trong gói.json

Vì vậy, nếu bạn đang làm việc trên máy tính cục bộ của mình, chỉ cần gõ npm installvà tiếp tục :)


6

peerDependencieskhông có ý nghĩa gì đối với tôi cho đến khi tôi đọc đoạn trích này từ một bài đăng trên blog về chủ đề Ciro đã đề cập ở trên :

Những gì [ plugin ] cần là một cách thể hiện các phụ thuộc này của Google giữa các plugin và gói máy chủ của chúng. Nói cách khác, tôi chỉ hoạt động khi được cắm vào phiên bản 1.2.x của gói máy chủ, vì vậy nếu bạn cài đặt cho tôi, hãy chắc chắn rằng nó cùng với một máy chủ tương thích. Chúng tôi gọi mối quan hệ này là một phụ thuộc ngang hàng.

Plugin không mong đợi một phiên bản cụ thể của máy chủ ...

peerDependenciesdành cho các plugin, thư viện yêu cầu thư viện "máy chủ" thực hiện chức năng của chúng, nhưng có thể đã được viết vào thời điểm trước khi phiên bản mới nhất của máy chủ được phát hành.

Nghĩa là, nếu tôi viết PluginX v1cho HostLibraryX v3và đi bộ, không có đảm bảo PluginX v1sẽ làm việc khi HostLibraryX v4(hoặc thậm chí HostLibraryX v3.0.1) được phát hành.

... nhưng plugin không phụ thuộc vào máy chủ ...

Từ quan điểm của plugin, nó chỉ thêm các chức năng cho thư viện máy chủ. Tôi không thực sự "cần" máy chủ để thêm phụ thuộc vào plugin và plugin thường không phụ thuộc vào máy chủ của chúng. Nếu bạn không có máy chủ lưu trữ, plugin sẽ vô hại.

Điều này có nghĩa dependencieslà không thực sự là khái niệm đúng cho các plugin.

Tệ hơn nữa, nếu máy chủ của tôi bị đối xử như một người phụ thuộc, chúng tôi sẽ gặp tình huống tương tự bài đăng trên blog (chỉnh sửa một chút để sử dụng máy chủ & plugin tạo câu trả lời này):

Nhưng bây giờ, [nếu chúng ta coi phiên bản đương đại của HostL LibraryX là một phụ thuộc cho PluginX,] đang chạy npm install kết quả trong biểu đồ phụ thuộc không mong muốn của

├── HostLibraryX@4.0.0
└─┬ PluginX@1.0.0
  └── HostLibraryX@3.0.0

Tôi sẽ để lại những thất bại tinh vi đến từ plugin bằng cách sử dụng API [HostL LibraryX] khác với ứng dụng chính theo trí tưởng tượng của bạn.

... và máy chủ rõ ràng không phụ thuộc vào plugin ...

... đó là toàn bộ điểm của plugin. Bây giờ nếu máy chủ đủ tốt để bao gồm thông tin phụ thuộc cho tất cả các plugin của nó, điều đó sẽ giải quyết được vấn đề, nhưng điều đó cũng sẽ giới thiệu một vấn đề văn hóa mới rất lớn : quản lý plugin!

Điểm chung của các plugin là chúng có thể ghép nối ẩn danh. Trong một thế giới hoàn hảo, việc quản lý tất cả các máy chủ sẽ gọn gàng và ngăn nắp, nhưng chúng tôi sẽ không yêu cầu các thư viện bầy mèo.

Nếu chúng ta không phụ thuộc vào thứ bậc, có thể chúng ta là những người ngang hàng ...

Thay vào đó, chúng tôi có khái niệm là đồng nghiệp. Cả máy chủ và plugin đều không nằm trong nhóm phụ thuộc của nhau. Cả hai đều sống ở cùng cấp độ của biểu đồ phụ thuộc.


... nhưng đây không phải là một mối quan hệ tự động. <<< Moneyball !!!

Nếu tôi PluginX v1mong đợi một người ngang hàng (nghĩa là có sự ngang hàng ) HostLibraryX v3, tôi sẽ nói như vậy. Nếu bạn đã tự động nâng cấp lên phiên bản mới nhất HostLibraryX v4(lưu ý đó là phiên bản 4 ) đã Plugin v1cài đặt, bạn cần biết, phải không?

npm không thể quản lý tình huống này cho tôi -

"Này, tôi thấy bạn đang sử dụng PluginX v1! Tôi đang tự động hạ cấp HostLibraryXtừ v4 xuống v3, kk?"

... hoặc là...

"Này tôi thấy bạn đang sử dụng PluginX v1. Đó là hy vọng HostLibraryX v3, mà bạn đã để lại trong bụi trong khi cập nhật cuối cùng của bạn. Để được an toàn, tôi sẽ tự động gỡ bỏ cài đặt Plugin v1!! 1!

Thế còn không, npm?!

Vì vậy, npm không. Nó cảnh báo bạn về tình huống và cho phép bạn tìm hiểu xem HostLibraryX v4có phải là một đồng nghiệp phù hợp hay không Plugin v1.


Coda

peerDependencyQuản lý tốt các plugin sẽ làm cho khái niệm này hoạt động trực quan hơn trong thực tế. Từ bài đăng trên blog , một lần nữa ...

Một lời khuyên: các yêu cầu phụ thuộc ngang hàng, không giống như các yêu cầu đối với các phụ thuộc thông thường, nên được khoan dung. Bạn không nên khóa phụ thuộc ngang hàng của mình xuống các phiên bản vá cụ thể. Sẽ rất khó chịu nếu một plugin Chai phụ thuộc vào Chai 1.4.1, trong khi một plugin khác phụ thuộc vào Chai 1.5.0, đơn giản vì các tác giả lười biếng và không dành thời gian để tìm ra phiên bản Chai tối thiểu thực sự của họ. tương thích với.


4

Phụ thuộc vs phụ thuộc dev

Phụ thuộc dev là các mô-đun chỉ được yêu cầu trong quá trình phát triển trong khi phụ thuộc được yêu cầu trong thời gian chạy. Nếu bạn đang triển khai ứng dụng của mình, các phụ thuộc phải được cài đặt, nếu không ứng dụng của bạn sẽ không hoạt động. Các thư viện mà bạn gọi từ mã của bạn cho phép chương trình chạy có thể được coi là phụ thuộc.

Ví dụ: Phản ứng, Phản ứng - dom

Các mô đun phụ thuộc dev không cần phải được cài đặt trong máy chủ sản xuất vì bạn sẽ không phát triển trong máy đó. Các trình biên dịch chuyển mã của bạn thành javascript, khung kiểm tra và trình tạo tài liệu có thể được coi là phụ thuộc dev vì chúng chỉ được yêu cầu trong quá trình phát triển.

Ví dụ: ESLint, Babel, webpack

@FYI,

mod-a
  dev-dependents:
    - mod-b
  dependents:
    - mod-c

mod-d
  dev-dependents:
    - mod-e
  dependents:
    - mod-a

----

npm install mod-d

installed modules:
  - mod-d
  - mod-a
  - mod-c

----

checkout the mod-d code repository

npm install

installed modules:
  - mod-a
  - mod-c
  - mod-e

Nếu bạn đang xuất bản đến npm, thì điều quan trọng là bạn phải sử dụng cờ chính xác cho các mô-đun chính xác. Nếu đó là thứ mà mô-đun npm của bạn cần để hoạt động, thì hãy sử dụng cờ "--save" để lưu mô-đun làm phụ thuộc. Nếu đó là thứ mà mô-đun của bạn không cần hoạt động nhưng nó cần để thử nghiệm, thì hãy sử dụng cờ "--save-dev".

# For dependent modules
npm install dependent-module --save

# For dev-dependent modules
npm install development-module --save-dev

1

Khi cố gắng phân phối một gói npm bạn nên tránh sử dụng dependencies. Thay vào đó bạn cần xem xét thêm nó vào peerDependencieshoặc loại bỏ nó khỏi dependencies.


1

Tôi tìm thấy một lời giải thích đơn giản.

Câu trả lời ngắn:

phụ thuộc "... là những thứ mà dự án của bạn thực sự cần để có thể làm việc trong sản xuất."

sự phụ thuộc "... là những thứ bạn cần trong quá trình phát triển."

đồng đẳng "nếu bạn muốn tạo và xuất bản thư viện của riêng mình để nó có thể được sử dụng như một phụ thuộc"

Thêm chi tiết trong bài đăng này: https://code-trotter.com/web/dependencies-vs-devdependencies-vs-peerdependencies

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.