Love - Alexandr Milov
‘Love’ by Ukrainian sculptor Alexander Milov

Wiemy już jak zoptymalizować samą instalację paczek npm, jak także przyspieszyć instalację z wykorzystaniem archiwizacji node_modules.

Teraz skoncentrujemy się na optymalizacji instalacji bez konieczności posiadania szybkiego dysku twardego!

W tym celu trzeba się zastanowić co można by byłoby zrobić by tak naprawdę te paczki zawsze były zainstalowane niezależnie od dynamicznie stworzonego folderu podczas budowania aplikacji na przykład w TeamCity. Wiemy, że folderem który nas interesuje jest folder node_modules, który za każdym razem musi istnieć w tej samej lokalizacji co nasz plik package.json. Jednak czy aby na pewno to musi być ta sama fizyczna lokalizacja? Czy może to może być skrót do tej lokalizacji? Skrót raczej jako tako nie, ale już Symbolic Link tak.

Sym link jest tak naprawdę referencją do innej lokalizacji, ale traktowaną “lokalnie”. Czyli my nie wiemy, że dane są fizycznie gdzie indziej, dla nas jest to nasz aktualny folder. Super nie?

Na windowsach możemy tworzyć symbolic link’s za pomocą polecenia mklink, nie jest to jakiś rocket science, wystarczy nam polecenie:

mklink /D LOKALNY_KATALOG C:\PRAWDZIWA_SCIEZKA

Gdzie LOKALNY_KATALOG to nazwa katalogu który ma być referencją do PRAWDZIWA_SCIEZKA.

Więc nasz skrypt teraz powinien wyglądać tak:

  1. Stworzenie katalogu jeżeli nie istnieje, do którego będzie tworzyć sym link
  2. Stworzyć sym link do katalogu z (1)
  3. Przeczyścić paczki (prune)
  4. Zainstalować paczki zgodnie z częścią 1

Teraz, mając scenariusz, możemy napisać nasz skrypt:

echo creating target for symlink

mkdir C:\npm-cache\_node_modules >nul 2>nul

echo creating symlink

mklink /D node_modules C:\npm-cache\_node_modules

echo clearing out unused packages

npm prune

echo installing packags

npm install --no-optional --skip-installed --cache "C:\npm-cache" --cache-min 9999999 --msvs_version=2012

Nie jest to trudne prawda? A niesamowicie przyspiesza npm install jeżeli musimy to wykonywać na build serwerach.

Podsumowanie npm install

W serii przeszliśmy od super wolnego npm install, do takiego, który trwa zaledwie kilka sekund. Przy czym wykorzystaliśmy nie tylko możliwości samego npm ale także naszej pomysłowości jak i systemu operacyjnego. Czy dałoby się to jeszcze bardziej przyspieszyć? Pewnie tak, czy naprawdę jest to nam potrzebne? To już zależy od waszego projektu i problemu. Mi wystarczyła opcja dzisiejsza, gdyż opcja 2 była za wolna ze względu na dysk twardy.

Teraz po 3 częściach, co uważacie? Warto tak wchodzić w szczegóły instalacji, czy to raczej powinno być rozwiązane przez osoby dostarczające narzędzie npm? Też mieliście problem z npm install i czasem jego wykonania na serwerach build? Jak go rozwiązaliście?

PODOBNE ARTYKUŁYWIĘCEJ OD AUTORA

4 KOMENTARZE

  2. Fajny cykl, wrócę kiedyś do tego, niestety ostatnio romans z node.js jest w odstawce ;(
    My zrobiliśmy trochę inaczej. Oprócz –no-optional i kilku innych elementów, których już dobrze nie pamiętam postawiliśmy na własny cache npm, który przy okazji daje możliwość wrzucania tam swoich własnych repo (sinopia – stosunkowo prosta instalacja i ma wszystko czego potrzebowaliśmy).
    Decyzja zapadła po kolejnym “padzie” oficjalnego repo, które niestety miewało często czkawkę (nie wiem jak teraz) i albo dostawaliśmy wielokrotne timeout’y w trakcie budowania, po czym w końcu leciał fail, albo trwało to niemiłosiernie długo (długie minuty) i stanowiło większość całego procesu CI. To rozwiązanie nie dało nam aż takich wyników jak to co piszesz, ale zeszliśmy do stabilnych kilku(nastu) sekund, które były good enough (no bo po co walczyć o kolejne 10 sekund, skoro proces wystawiania do AWS trwał w sumie kilka minut, więc zysk byłby niezauważalny).

    • @Ireneusz

      super, dzieki za sinopia – ciekawe. jeszcze zastanawia mnie npm-cache i czy by takze dzialal, ale nie mialem mozliwosci przetestowania.

      i tak :) walka o 10 sekund nie ma znaczenia.

Comments are closed.