Dlaczego musimy instalować gulp globalnie i lokalnie?

2 podręczniki o gulp mówią, że muszę najpierw zainstalować gulp globalnie (z flagą -g), a potem jeszcze raz lokalnie. Dlaczego tego potrzebuję?

Podczas instalowania narzędzia globalnie, może być używane przez użytkownika jako narzędzie wiersza polecenia w dowolnym miejscu, w tym poza projektami węzłów. Globalne instalacje dla projektu węzła są złe, ponieważ utrudniają wdrożenie.

npm 5.2+

npxNarzędzie powiązane z npm 5.2rozwiązuje ten problem. Za jego pomocą możesz wywoływać narzędzia zainstalowane lokalnie, takie jak narzędzia zainstalowane globalnie (ale musisz rozpocząć polecenie od npx). Na przykład, jeśli chcesz wywołać lokalnie zainstalowany eslint, możesz:

npx eslint .

npm <5.2

W przypadku użycia w scriptpolu pliku package.json npmwyszukuje node_modulesnarzędzie, a także moduły zainstalowane globalnie, więc instalacja lokalna jest wystarczająca.

Więc jeśli jesteś zadowolony z (w pakiecie.json):

"devDependencies": {
    "gulp": "3.5.2"
}
"scripts": {
    "test": "gulp test"
}

itd. i działając z npm run testtym czasem nie powinieneś w ogóle potrzebować instalacji globalnej.

Obie metody przydają się do skonfigurowania projektu, ponieważ sudonie są potrzebne. Oznacza to również, że gulpzostanie zaktualizowany, gdy wersja zostanie zderzona z pakietem.json, więc wszyscy będą używać tej samej wersji gulp podczas programowania z twoim projektem.

Uzupełnienie:

Wygląda na to, że łyk zachowuje się nietypowo, gdy jest stosowany na całym świecie. Gdy jest używany jako instalacja globalna, gulp szuka lokalnie zainstalowanego gulpa, aby przekazać kontrolę. Dlatego globalna instalacja gulp wymaga do działania lokalnej instalacji gulp. Powyższa odpowiedź jest jednak nadal aktualna. Lokalne instalacje są zawsze lepsze niż instalacje globalne.

TLDR; Oto dlaczego :

Powodem tego jest to, że gulppróbuje uruchomić gulpfile.jstwoją lokalnie zainstalowaną wersję gulp, patrz tutaj . Stąd przyczyna globalnej i lokalnej instalacji gulp.

Zasadniczo, gdy instalujesz gulplokalnie, skryptu nie ma w twoim, PATHwięc nie możesz po prostu pisać gulpi oczekiwać, że powłoka znajdzie polecenie. Instalując go globalnie, gulpskrypt dostaje się do twojego, PATHponieważ node/bin/najprawdopodobniej katalog globalny jest na twojej ścieżce.

Aby jednak uszanować lokalne zależności, gulpużyje zainstalowanej lokalnie wersji do uruchomienia gulpfile.js.

Możesz połączyć globalnie zainstalowany gulplokalnie z

npm link gulp

Pytanie „ Dlaczego musimy instalować gulp globalnie i lokalnie? ” Można podzielić na następujące dwa pytania:

1. Dlaczego muszę instalować gulp lokalnie, jeśli już go zainstalowałem globalnie?

2. Dlaczego muszę instalować gulp globalnie, jeśli już go zainstalowałem lokalnie?

Kilka innych udzieliło doskonałych odpowiedzi na te pytania w oderwaniu, ale pomyślałem, że korzystne byłoby skonsolidowanie informacji w ujednoliconej odpowiedzi.

Dlaczego muszę instalować gulp lokalnie, jeśli już go zainstalowałem globalnie?

Uzasadnienie lokalnego instalowania łyka składa się z kilku powodów:

1. Lokalne uwzględnienie zależności projektu zapewnia, że ​​użyta wersja gulp (lub inne zależności) jest pierwotnie zamierzoną wersją.
2. Węzeł domyślnie nie bierze pod uwagę modułów globalnych, gdy używa się metody replace () (którą należy dołączyć do skryptu). Ostatecznie dzieje się tak, ponieważ ścieżka do globalnych modułów nie jest domyślnie dodawana do NODE_PATH.
3. Według zespołu programistów Node lokalne moduły ładują się szybciej. Nie mogę powiedzieć, dlaczego tak jest, ale wydaje się, że jest to bardziej odpowiednie do wykorzystania węzła w produkcji (tj. Zależnościach w czasie wykonywania) niż w rozwoju (tj. Zależności deweloperów). Podejrzewam, że jest to uzasadniony powód, ponieważ niektórym może zależeć na uzyskaniu niewielkiej przewagi prędkości podczas ładowania modułów lokalnych w porównaniu do globalnych, ale możesz podnieść brwi z tego powodu.

Dlaczego muszę instalować gulp globalnie, jeśli już go zainstalowałem lokalnie?

1. Uzasadnieniem globalnej instalacji programu gulp jest tak naprawdę wygoda automatycznego uruchamiania programu gulp w ścieżce systemowej.

Aby uniknąć instalacji lokalnej, możesz użyć tej opcji npm link [package], ale polecenie link oraz install --globalpolecenie wydają się nie obsługiwać tej --save-devopcji, co oznacza, że ​​nie wydaje się, aby istniał łatwy sposób na zainstalowanie gulp globalnie, a następnie łatwe dodanie dowolnej wersji, która ma być twój lokalny plik package.json.

Ostatecznie uważam, że sensowniej jest mieć opcję korzystania z globalnych modułów, aby uniknąć konieczności duplikowania instalacji wspólnych narzędzi we wszystkich projektach, szczególnie w przypadku narzędzi programistycznych, takich jak chrząknięcie, gulp, jshint itp. Niestety to wygląda na to, że kończysz walkę z narzędziami, gdy idziesz pod prąd.

Technicznie nie musisz instalować go globalnie, jeśli node_modulesfolder w instalacji lokalnej znajduje się w twoim PATH. Zasadniczo nie jest to dobry pomysł.

Alternatywnie, jeśli npm testreferencje gulp, możesz po prostu wpisać, npm testa uruchomi się lokalny łyk.

Nigdy nie instalowałem gulp na całym świecie - myślę, że to zła forma.

Nie jestem pewien, czy nasz problem był bezpośrednio związany z instalowaniem gulp tylko lokalnie. Ale musieliśmy sami zainstalować wiele zależności. Doprowadziło to do powstania „ogromnego” pakietu.json i nie jesteśmy pewni, czy naprawdę dobrym pomysłem jest instalowanie gulp tylko lokalnie. Musieliśmy to zrobić ze względu na środowisko kompilacji. Ale nie poleciłbym instalowania gulpa nie na całym świecie, jeśli nie jest to absolutnie konieczne. Napotkaliśmy podobne problemy, jak opisano w poniższym poście na blogu

Żaden z tych problemów nie pojawia się u żadnego z naszych programistów na ich lokalnych komputerach, ponieważ wszyscy zainstalowali gulp na całym świecie. W systemie kompilacji mieliśmy opisane problemy. Jeśli ktoś jest zainteresowany, mógłbym głębiej zagłębić się w tę kwestię. Ale teraz chciałem tylko wspomnieć, że nie jest to łatwa ścieżka do instalacji gulp tylko lokalnie.

Tylko dlatego, że nie widziałem go tutaj, jeśli korzystasz z systemu MacOS lub Linux, sugeruję dodanie tego do PATH (w bashrc itp.):

node_modules/.bin

Dzięki temu względnemu wpisowi ścieżki, jeśli siedzisz w folderze głównym dowolnego projektu węzła, możesz uruchomić dowolne narzędzie wiersza poleceń (eslint, gulp itp.) Bez obawy o „globalne instalacje” npm runitp.

Gdy to zrobiłem, nigdy nie instalowałem modułu globalnie.