Jeśli nie chcesz instalować devDependencies możesz użyć npm install --production

Jako przykład mocha normalnie byłaby zależnością devDependency, ponieważ testowanie nie jest konieczne w produkcji, podczas gdy express byłby zależnością.

Zależności
Zależności, które musi uruchomić projekt, np. biblioteka, która udostępnia funkcje wywoływane z kodu.
Są instalowane przejściowo (Jeśli a zależy od B zależy od C, npm install na A zainstaluje B I C).
przykład lodash lodash: Twój projekt wywołuje niektóre funkcje lodash.

DevDependencies
Zależności, których potrzebujesz tylko podczas tworzenia lub wydawania, jak kompilatory, które pobierają Twój kod i kompilują go do javascript, frameworków testowych lub generatorów dokumentacji.
Nie są instalowane przejściowo (Jeśli a zależy od b dev-zależy od C, npm install on a zainstaluje tylko B).
przykład: grunt: Twój projekt używa grunt do budowania siebie.

PeerDependencies
Zależności, które twój projekt łączy lub modyfikuje w projekcie nadrzędnym, Zwykle wtyczka dla innej biblioteki lub narzędzia. Ma to być tylko kontrola, upewniając się, że projekt nadrzędny (projekt to będzie zależeć od Twojego projektu) ma zależność od projektu, do którego się przyłączysz. Więc jeśli tworzysz wtyczkę C, która dodaje funkcjonalność do biblioteki B, to ktoś tworzący projekt A będzie musiał mieć zależność od B, jeśli ma zależność od C.
Nie są zainstalowane (chyba że npm przykład: grunt: Twój projekt dodaje funkcjonalność grunt i może być używany tylko w projektach, które używają grunt.

Ta dokumentacja wyjaśnia zależności między rówieśnikami naprawdę dobrze: https://nodejs.org/en/blog/npm/peer-dependencies/

Również dokumentacja npm została z czasem ulepszona, a teraz ma lepsze wyjaśnienia różnych typów zależności: https://github.com/npm/cli/blob/latest/docs/content/configuring-npm/package-json.md#devdependencies

Aby zapisać pakiet do pakietu.json jako dev dependencies:

npm install "$package" --save-dev

Po uruchomieniu npm install zainstaluje zarówno devDependencies, jak i dependencies. Aby uniknąć instalacji devDependencies Uruchom:

npm install --production

Istnieje kilka modułów i pakietów niezbędnych tylko do rozwoju, które nie są potrzebne w produkcji. Jak to jest napisane w dokumentacji :

Jeśli ktoś planuje pobrać i wykorzystać twój moduł w swoim programie, to prawdopodobnie nie chce lub nie musi pobierać i budować zewnętrznego frameworka testowego lub dokumentacji, którego używasz. W takim przypadku najlepiej wymienić te dodatkowe elementy w hash devDependencies.

Proste wyjaśnienie, które sprawiło, że stało się to dla mnie bardziej jasne to:

Podczas wdrażania aplikacji, Moduły w zależności muszą być zainstalowane lub aplikacja nie będzie działać. Moduły w devDependencies nie muszą być instalowane na serwerze produkcyjnym, ponieważ nie rozwijasz ich na tej maszynie. link

Chciałbym dodać do odpowiedzi mój pogląd na te wyjaśnienia zależności

• dependencies są używane do bezpośredniego użycia w Twojej bazie kodowej, rzeczy, które zwykle kończą się w kodzie produkcyjnym, lub fragmenty kodu
• devDependencies są używane do procesu budowania, narzędzia, które pomogą Ci zarządzać tym, jak kod końcowy zakończy się, Moduły testowe innych firm, (np. Webpack stuff)

peerDependencies nie do końca miało to dla mnie sensu, dopóki nie przeczytałem tego fragmentu z posta na blogu na temat Ciro wspomniany powyżej :

Czego [ pluginy ] potrzebują jest sposobem wyrażania tych "zależności" pomiędzy wtyczkami a ich pakietem hosta. W pewien sposób można powiedzieć: "pracuję tylko po podłączeniu do wersji 1.2.x mojego pakietu hosta, więc jeśli zainstalujesz mnie, upewnij się, że jest on obok kompatybilnego hosta."Nazywamy ten związek rówieśnikiem zależność.

Wtyczka nie oczekuje konkretnej wersji hosta...

peerDependencies są dla wtyczek, bibliotek, które wymagają biblioteki "host" do wykonywania swojej funkcji, ale mogą być napisane w czasie przed najnowsza wersja hosta została wydana.

Oznacza to, że jeśli napiszę PluginX v1 dla HostLibraryX v3 i odejdę, nie ma gwarancji, że PluginX v1 zadziała, gdy HostLibraryX v4 (lub nawet HostLibraryX v3.0.1) zostanie zwolniony.

... ale wtyczka nie Zależy od gospodarza...

Z punktu widzenia wtyczki, to tylko dodaje funkcje do biblioteki hosta. Tak naprawdę nie" potrzebuję " hosta, aby dodać zależność do wtyczki, a wtyczki często nie zależą dosłownie od ich hosta. Jeśli nie masz hosta, wtyczka nie robi nic złego.

Oznacza to, że {[8] }nie jest właściwą koncepcją dla wtyczek.

Ale teraz, [jeśli traktujemy współczesną wersję HostLibraryX jako zależność dla PluginX,] uruchomienie npm install powoduje nieoczekiwany wykres zależności

├── [email protected]
└─┬ [email protected]
  └── [email protected]

Zostawię subtelne błędy, które pochodzą z wtyczki za pomocą innego [HostLibraryX] API niż główna aplikacja do wyobraźni.

... a host oczywiście nie zależy od wtyczki...

... o to chodzi z wtyczkami. Teraz, jeśli host był wystarczająco miły, aby włączyć informacje o zależnościach dla wszystkich swoich wtyczek, to rozwiązałoby problem, ale {36]} to również wprowadziłoby ogromny nowy problem kulturowy: zarządzanie wtyczkami!

Cały sens wtyczek jest taki, że mogą łączyć się w pary anonimowo. W idealnym świecie posiadanie hosta zarządzającego nimi wszystkimi byłoby schludne i uporządkowane, ale nie zamierzamy wymagają bibliotek.

Jeśli nie jesteśmy zależni hierarchicznie, może jesteśmy zależnymi rówieśnikami...

Zamiast tego, mamy pojęcie bycia rówieśnikami. Ani host, ani wtyczka nie znajdują się w zasobniku zależności innych. Oba żyją na tym samym poziomie grafu zależności.

... ale to nie jest automatyczny związek.

If I ' m PluginX v1 and expect a peer of (czyli have a peer of ) HostLibraryX v3, powiem tak. Jeśli zaktualizowano ją automatycznie do najnowszej HostLibraryX v4 (zauważ, że jest to wersja 4) i mieć Plugin v1 zainstalowany, musisz wiedzieć, prawda?

npm nie mogę sobie poradzić z tą sytuacją ... ]}

"Hej, widzę, że używasz PluginX v1! Automatycznie obniżam HostLibraryX z v4 do v3, kk?"

W skrócie

1. Zależności - npm install <package> --save-prod instaluje Pakiety wymagane przez aplikację w środowisku produkcyjnym.

2. DevDependencies - npm install <package> --save-dev instaluje Pakiety wymagane tylko do lokalnego rozwoju i testowania

3. Wystarczy wpisać npm install instaluje wszystkie pakiety wymienione w paczka.json

Więc jeśli pracujesz na lokalnym komputerze po prostu wpisz npm install i kontynuuj :)

Znalazłem proste wyjaśnienie.

Krótka Odpowiedź:

Zależności "...czy te, które twój projekt naprawdę potrzebuje, aby móc pracować w produkcji."

DevDependencies "...są te, które są potrzebne podczas rozwoju."

PeerDependencies "jeśli chcesz utworzyć i opublikować własną bibliotekę, aby mogła być używana jako zależność"

Więcej szczegółów w tym post: https://code-trotter.com/web/dependencies-vs-devdependencies-vs-peerdependencies

Zależności vs dev dependencies

Dev dependencies są modułami, które są wymagane tylko podczas programowania, podczas gdy zależności są wymagane w czasie wykonywania. Jeśli wdrażasz aplikację, musisz zainstalować zależności, w przeciwnym razie aplikacja po prostu nie będzie działać. Biblioteki, które wywołujesz z kodu, który umożliwia uruchomienie programu, można uznać za zależności.

Eg-React, React-dom

Moduły zależności Dev nie muszą być instalowane na serwerze produkcyjnym, ponieważ nie będziesz się rozwijać w tej maszynie .Kompilatory, które ukrywają kod w javascript, frameworkach testowych i generatorach dokumentów, mogą być traktowane jako dev-dependencies, ponieważ są wymagane tylko podczas programowania.

Eg-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

Jeśli publikujesz w npm, ważne jest, aby użyć właściwej flagi dla właściwych modułów. Jeśli jest to coś, co twój moduł npm musi funkcjonować, użyj flaga "--save", aby zapisać moduł jako zależność. Jeśli twój moduł nie musi działać, ale jest potrzebny do testowania, Użyj flagi "--save-dev".

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

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

Podczas próby dystrybucji pakietu npm należy unikać używania dependencies. Zamiast tego należy rozważyć dodanie go do peerDependencies lub usunięcie go z dependencies.

Zależności

Są to pakiety, które twój pakiet musi uruchomić, więc będą one instalowane, gdy ludzie będą uruchamiać

 npm install PACKAGE-NAME

Przykładem może być użycie jQuery w projekcie. Jeśli ktoś nie ma zainstalowanego jQuery, to nie działa. Aby zapisać jako zależność, użyj

 npm install --save

Dev-Dependencies

Są to zależności, których używasz w rozwoju, ale nie są potrzebne, gdy ludzie go używają, więc gdy ludzie uruchamiają npm install, nie zainstaluje ich, ponieważ są nie trzeba. Na przykład, jeśli używasz mocha do testowania, ludzie nie potrzebują mocha do uruchomienia, więc npm install nie instaluje go. Aby zapisać jako zależność dev, użyj

npm install PACKAGE --save-dev

Peer Dependencies

Mogą być używane, jeśli chcesz utworzyć i opublikować własną bibliotekę, aby mogła być używana jako zależność. Na przykład, jeśli chcesz, aby twój pakiet był używany jako zależność w innym projekcie, to będą one również instalowane, gdy ktoś zainstaluje projekt, który ma twój projekt jako zależność. Przez większość czasu nie używasz zależności rówieśniczych.