Jak zdecydować, czy @ typy / * przechodzi w `dependencies` czy` devDependencies`?

200

Używam TypeScript 2 w moim projekcie. Chciałbym użyć biblioteki js, ale także pisania dla tej biblioteki. Mogę instalować typy za pomocą prostego npm install @types/some-library. Nie jestem pewien, czy powinienem --saveczy --save-devoni. Wydaje mi się, że nawet ReadetetTyped GitHub w pewnym sensie wspomina o obu wersjach, ale nigdy ich nie wyjaśnia. Wydaje mi się, że @typy powinny być włączone devDependencies, ponieważ typy są potrzebne do programowania i nie są używane w środowisku wykonawczym, ale widziałem wiele razy @typy w właśnie dependencies. Jestem zmieszany.

Jak zdecydować, czy @ typy / * przejdzie do dependenciesczy devDependencies? Czy faktycznie są jakieś mniej lub bardziej oficjalne instrukcje?

— kamyl
źródło

Czy generujesz pakiet, czy jest to pakiet, który będzie używany przez innych? Moim zdaniem wystarczy wprowadzić rozróżnienie między tym ostatnim dependenciesi devDependenciesdrugim przypadkiem.

— Valentin,

Robię trochę gry w js / ts od zera. Pakuję wszystko za pomocą webpacka. Bankomat nie ma żadnego zaplecza, ale możliwe jest, że zapakuję wszystko w Electron, aby pewnego dnia stał się samodzielny. Nie sądzę, żeby ktokolwiek kiedykolwiek używał tego jako zależności we własnej aplikacji, ale wydaje mi się, że to możliwe (pomyśl o mini grach w grach GTA; a moja gra jest open source). Nadal chcę się uczyć i stosować najlepsze praktyki i to jest główny powód, dla którego tworzę tę grę. Mam nadzieję, że wystarczająco dobrze wyjaśniłem mój przypadek użycia. :)

— kamyl

Tak, to ma sens, chciałem tylko upewnić się, że moja oryginalna odpowiedź była odpowiednia dla twojego przypadku użycia. Nadal uważam, że rozróżnienie pomiędzy devDependenciesi dependenciesnie ma znaczenia, gdy buduje pakiet, to jest coś, co create-react-appwymusza jak dobrze , ale w końcu to do ciebie, aby wybrać

— Valentin

Odpowiedzi:

140

Załóżmy, że tworzysz pakiet „A”, który ma pakiet @ types / some-module w devDependencies. Z jakiegoś powodu eksportujesz typ z @ types / some-module

import {SomeType} from 'some-module';
export default class APackageClass {
     constructor(private config: SomeType) {

     }
}

W tej chwili konsumenci maszynopisu pakietu „A” nie są w stanie odgadnąć, czym jest SomeType, ponieważ NIE są zainstalowane devDependencies pakietu „A”.

W tym konkretnym przypadku POTRZEBUJESZ umieścić pakiet @ types / * ze zwykłymi „zależnościami”. W innych przypadkach „devDependencies” są wystarczająco dobre.

— wookieb
źródło

Sugerujesz więc, że jeśli użyję tylko typu w implementacji, to może to być definicja typu devDependencies?

— Franklin Yu

Tak @FranklinYu. Gdy tylko typ pojawi się w pliku deklaracji, musisz go umieścić dependencies. W przeciwnym razie devDependenciesjest w porządku

— wookieb

Ale pakiet działa zarówno dla TS, jak i JS. Programiści JS nie potrzebują tych typów do kompilacji swojego kodu. Dodanie definicji typu dependenciesspowoduje rozdęcie drzewa zależności.

— Tyler Long

@TylerLong Correct. To nie jest idealne, ale taka jest rzeczywistość. Opcjonalnie możesz również użyć opcji „opcjonalneDzależności”, ale uważam, że w skali może to być bardzo denerwujące.

— wookieb

Jeśli tylko generujesz pakiet, może nie być konieczne rozróżnienie między dependenciesi devDependencies. Ta funkcja npmjest na ogół przydatna podczas publikowania pakietu, z którego mogą korzystać inni i nie chcesz spamować ich zbędnymi zależnościami.

Mogą istnieć inne przypadki użycia, w których podział zależności może być pomocny, ale chyba że masz wyraźną potrzebę, to radzę wybrać jedną z nich i umieścić tam wszystko. Podział ich później nie jest trudny, jeśli zajdzie taka potrzeba.

Dobrze znanym przykładem tej praktyki IRL jest create-react-app, domyślnie, niewyciskany bojler, w którym wszystko umieszcza dependencies, zobacz ten wątek i tę odpowiedź

— Valentin
źródło

Jeśli nie publikujesz pakietu, jest to poprawne, ale jeśli tak, nie ma to nic wspólnego z programowaniem vs. środowiskiem wykonawczym i wszystkim, co jest potrzebne do zbudowania tego pakietu, a tym, co jest potrzebne do korzystania z tego pakietu .

— Yogu,

@Yogu Właśnie dlatego wyróżniłem się na pierwszym miejscu, więc tak, całkowicie się z tobą zgadzam

— Valentin

Nie zgadzam się z tą radą. devDependenciesnie są instalowane, gdy to robisz npm install --production(lub npm ci --production), a zatem nie są dostępne podczas uruchamiania kodu produkcyjnego. Jest to bardzo znacząca różnica dla usługi, a nie tylko biblioteki.

— Brad Wilson

@BradWilson Masz rację, istnieje wiele przepływów pracy npm pod słońcem, jeśli twój przypadek użycia wymaga rozróżnienia, to zrób wszystko. Podaj własną odpowiedź na ten dylemat.

— Valentin

Zaktualizowałem swoją odpowiedź, aby wspomnieć o istnieniu innych przypadków użycia, w których to rozróżnienie może mieć znaczenie, i podałem przykłady ze świata rzeczywistego. Dziękujemy za opinię!

— Valentin,

W szczególnym przypadku wdrażania aplikacji Node.js w środowisku produkcyjnym chce się zainstalować tylko zależności potrzebne do uruchomienia aplikacji.

npm install --production lub

npm ci --production lub

yarn --production

W takim przypadku typy powinny znajdować się w devDependencies, aby zapobiec rozdęciu instalacji.

Uwaga: Wiem, że wspomniano o tym w komentarzu Brada Wilsona do innej odpowiedzi. Ta kwestia wydaje się jednak warta odpowiedzi.

— Carsten Führmann
źródło