Odpowiedź do komentarza z npm install Część 2

Stwierdziłem, że zamiast dawać komentarz do komentarza tomaszk-poz pod wpisem Optymalizacja npm install – Część 2 udostępnię tą odpowiedź jako post – ze względu chociażby na jej długość :)

Oficjalny komentarz brzmiał tak:

by tomaszk-poz

W moim projekcie jest 2MB źródeł (c#,js,scss, grafika) a po skonfigurowaniu gulpa do konwersji scss do css npm naściągał 30MB plików, 8170 plików i 2003 folderów. Do tego musiałem się nagimnastykować, żeby pasował node-sass (kombinacje install/uninstall, rebuild), bo nie chcałem z githubu ściągać binarki (licho wie jak z wirusami).

Pliki nie mogą być współdzielone, wszystko musi lecieć do node_modules. Zależności się powielają, w katalogach zalega mnóstwo plików (testy, źródła w C, js, yml). Spodziewałem się kilku plików a nie śmietnika.

Bower też nie lepszy – w nuget zdarzają się świeższe pakiety niż w bower (choćby underscore). Do tego doliczmy bezsens (podobnie jak npm) ściągania wszystkich plików dla jednego rozwiązania zamiast (tak jak to zrobiono w nuget) js z ew. css.

Sprawdziłem –no-optional i niestety to samo 40MB zajętego dysku/8177 plików, żeby być nowoczesnym i iść z duchem czasu (dla jednej funkcjonalności przy kompilowaniu!). Toż to 1/20 ilości plików w moim windows 10 :-D

Nie pomyślałeś nad rozwiązaniem ramdysk? Ram jest tani, pamięć szybka, zaś dyski SSD nie lubią małych plików, mają słabą wydajność przy takich plikach (widać to w testach IO4KB).
Spakowane archiwum node_modules na dany projekt można trzymać na ssd, zrobić z tego SHA1 i wynik zapisywać do repo. Przed buildem po SHA1 poszukać w magazynie (czy nawet redisie ;-) ) i rozpakować do ramu ew. cały zip trzymać w repo i rozpakowywać. Gdy zawartość node_modules sie nie zmienia, git nie robi kopii do nowych commitów tylko linkuje.

Całość dla mnie ponurego obrazu dopełnia słaba dokumentacja modułów, porzucanie projektów (np. takana – fajnie się zapowiadała, po windowsem problem, od roku na githubie brak akcji)
Moim zdaniem trzeba być ostrożnym z nodejs i npm.

Microsoft idzie w tę głupią modę, w VS2015 w WebEssentials wyrzucono cześć funkcjonalności, sugerując wykorzystanie gulpa, tylko, że jego obsługa lekko kuleje (np. w źródle nie wskazuje błedów w pliku źródłowym).
Moim zdaniem MS właśnie powinien włączyć stare WebEssentials do VS, kto to słyszał, żeby niezłe IDE także do JS domyślnie nie miało konwersji js/scss i innych operacji.

Sorki, musiałem się zastanowić jak Ci odpowiedzieć na Twój komentarz bo poruszyłeś w nim kilka kwestii jak i musiałem na problem spojrzeć z kilku punktów widzenia – bo jakbym był czystym programistą ruby czy też cały czas siedział na innych platformach to raczej bym nie zrozumiał trochę komentarza :) Ale jako użytkownik windows, wiem o co Ci chodzi i z czym masz problem – przynajmniej mi się tak to wydaje.

Spróbowałem się tutaj pogrupować:

• Wszystko musi znajdować się w node_modules
• Liczby rzeczy instalowanych przez npm:
  • Plików
  • Paczek
  • Powielonych zależności
• Rozmiar na dysku
• Konfiguracja tego wszystkiego by to działało tak jak chcesz
• SASS – rozdzieliłem, bo to special case
• Bower posiada starsze paczki niż nuget
• Problemy open source i opuszczania projektów
• WebEssentials było lepsze i MS powinno to przywrócić
• Obawa o wirusy

Oraz pytanie ogólnie czy nie lepiej by było to zrobić z wykorzystaniem ramdysk i kluczem SHA1 – różne opcje.

Zacznę od problemów które wymieniłeś i spróbuje na nie wszystkie odpowiedzieć po kolei. Jednak pragnę zaznaczyć :) npm nie jest idealnym rozwiązaniem, ma swoje problemy. Ale też nie jest złym rozwiązaniem i jest znacznie lepszym niż nuget pod względem wszystkiego – ot tworzenia paczek po ich instalację. NuGet sam w sobie ma mas

Wszystko musi znajdować się w node_modules

Tak, tak działa i tak został zaprojektowany npm. Nuget można oszukać, ale wtedy zaczynasz mieć per komputer per projekt ustawienia które trafiają do repo, bo plik z informacją o paczkach trzeba wrzucać. Jest to konfigurowalne z poziomu ustawień nuget.

W node_modules zaś masz swobodę i dostępne wszystkie systemowe narzędzia o czym będzie w Części 3. To znaczy, co możesz zrobić by folder niby istniał a nie istniał. Ale jak piszę dam na to odp w Części 3.

Plusem tego, że to się znajduje w jednym folderze jest taki, że łatwo tym zarządzać pod względem projektu. Do tego też dość łatwo się czyści takie projekty pozostawiając jedynie kod źródłowy.

Jak dla mnie, osobiście posiadanie wszystkich zależności w jednym miejscu jest super, bo jestem wstanie tym zarządzać. Nikt mi nie zrobi więcej linków do DLLek które są budowane przez projekt w innej gałęzi TFS. A tak ludzie robili bo się dało :) Więc tutaj jest to po prostu dobrze rozwiązane – proste rozwiązanie które śmiga.

Oczywiście, w Bower da się określić lokalizację ściąganych plików itp., jednak, to jest różnica – strona kliencka i strona serwerowa i dla mnie to ma znaczenie osobiście. Zaś node_modules jest i jest imo ok, mogliby dać możliwość zmiany miejsca instalacji ale znów, nie ma sensu bo da się to zrobić inaczej :) Do tego, dzięki temu, że coś jest w node_modules, pewne rzeczy mogą działać na zasadzie konwencji. A to już jest super fajne :) w razie co, może jak naprawdę chcesz, przydać Ci się komenda npm link – jednak trochę zachodu ona wymaga, część 3 pokarze jak to zrobić szybciej.

Ogólnie, to co jest w node_modules, Cię nie interesuje i interesować nie powinno. To co powinno Cię interesować to czy masz paczkę wykonującą twój kod. Jak Cię interesuje tylko to co chcesz, to nie znam takich technologii która by to dostarczała z nuget włącznie. Bo jak nie chcę nic dla .NET Framework 3.5, nie chcę by pliki statyczne były instalowane w predefiniowanych miejscach – paczka decyduje gdzie, więc wiesz :) nigdzie nie jest pięknie :)

Na koniec, trochę więcej o decyzji npm dlaczego tak a nie inaczej można przeczytać w FAQ: „node_modules” is the name of my deity’s arch-rival, and a Forbidden Word in my religion. Can I configure npm to use a different folder? :)

Liczba plików instalowanych przez npm

Node.js jest serwerem w którym pisze się w JavaScript. Aktualnie nie ma kompilatora chyba takiego co by zrobił binarkę z JavaScript (zaznaczam chyba bo świat jest porąbany), a co to znaczy? To, że jakoś aplikację trzeba móc napisać, a jak napisać to nie w jednym niezrozumiałym pliku ale w kilku tak by się dało to odczytać. Teraz to czy paczka będzie zawierała wszystko czy tylko build to już jest uzależnione od Twórcy paczek. Niezależnie od tego tak czy siak będzie to przynajmniej kilka plików.

To chyba tłumaczy trochę sprawy związane z liczbą plików i dlaczego ich jest aż tyle, ale czy jest ich jest aż tyle, żeby to stanowiło problem? Nie wiem. Mi to nie przeszkadza bo dla mnie node_modules to katalog do którego nie zaglądam bo i nie mam po co.

Liczba paczek instalowanych przez npm

Tutaj jest to dość jasne jak się spojrzy na problemy jakie miało jQuery. Nagle dostawało się super duży plik, z którego jedyną rzeczą jaką korzystaliśmy to selektory. W jQuery 2.0 to już zostało naprawione poprzez osobny projekt. To samo tyczy się wielu innych rzeczy. Dla przykładu czy by mieć event na załadowanie DOM potrzebny jest nam jQuery? Czy wystarczy coś super małego, zwinnego co robi tylko to?

Dla mnie odpowiedź jest prosta, nie potrzebuje jQuery i wolę ten mały przyjemny tool DomReady.

Teraz więc, npm posiada wiele paczek które są małe i są odpowiedzialne za określone rzeczy, odpalenie aplikacji, przesłanie eventu itp. Dzięki czemu masę programistów nie musi tego pisać od nowa. Tak naprawdę większość nie musi. Co jest niesamowicie dużym plusem. Stąd też liczba instalowanych paczek. Do tego, tutaj zależności są paczką, nie są DLLką instalowaną jak .NET Framework. Tutaj wszystko jest paczką i ma to ręce i nogi jak się pomyśli wszystkich platformach na których to jest dostępne.

Liczba powielonych zależności instalowanych przez npm

To się zmieniło w wersji 3.0:

Flat, flat, flat!

Your dependencies will now be installed maximally flat. Insofar as is possible, all of your dependencies, and their dependencies, and THEIR dependencies will be installed in your project’s node_modules folder with no nesting. You’ll only see modules nested underneath one another when two (or more) modules have conflicting dependencies.

Rozmiar na dysku

Tutaj jest mi bardzo ciężko się odnieść, gdyż:

• VS 2015 -> 10GB?
• .NET Framework -> 300MB?
• Plus dla ~80 (u mnie w projekcie) paczek nuget -> 200MB

Więc ciężko mówić o jakiś 40MB tutaj. Oczywiście pomijając środowisko, 40MB to też nie dużo kiedy przestrzeń jest tania. Mnie osobiście by to nie przeszkadzało, w szczególności iż jak pisałem wcześniej – nie interesuje mnie to co się dzieje w node_modules. Do tego ja bym tego nigdzie nie checkinował. Ma to swoje podłoże w tym, że muszę wiedzieć czy projekt zadziała mi wszędzie gdzie trzeba – nie wtedy kiedy mam node_modules w repozytorium, bo może a nóż ktoś wpadł na genialny pomysł i samemu coś tam zaktualizował? To wtedy jak będzie jak pójdziemy na staginig czy live env?

Więc jest to jedynie problem na moim dysku w chwili kiedy pracuje nad projektem. Lub dokładnie, może to być problem tylko i wyłącznie wtedy. Przynajmniej takie mam odczucia.

Konfiguracja tego wszystkiego by to działało tak jak chcesz

No, tutaj nie wiem czy chodzi o Gulp/Grunt i pisanie tasków, czy ogólnie by wszystko śmigało po zainstalowaniu paczek?

Przykład SASS będzie opisany poniżej, więc tutaj ciężko mi się do czegokolwiek odnieść, mogę zaś napisać dwa zdania o Gulp i Grunt.

Są to dla mnie dwa super bardzo zajefajne narzędzia, których brak w .NET odczuwam od lat. MS BUILD jest… istnieje ok, i nie będę się inaczej na jego temat wyrażał. Gdybym miał napisać coś i skonfigurować to z wykorzystaniem MS BUILD to bym sobie krakersami żyły pociął. Modułowość grunta i gulpa jest super, można za pomocą praktyki oczywiście napisać bardzo fajne, przejrzyste i praktyczne taski które będą robiły wszystko to co chcemy jak nie więcej. Czegoś takiego nigdy nie udałoby się uzyskać w rozsądnym czasie w Visual Studio.

SASS – rozdzieliłem, bo to special case

Dlaczego SASS jest special case? Bo SASS zawsze był Ruby, od 2012 roku trwają pracę na libSass – kompilatorze w C. By to skompilować pod Windows trzeba się dalej namęczyć. Ale chyba mniej niż by mieć w pełni działający Ruby. Czyja to wina? Ogólnie nikt się Windowsem nie przejmował z chłopaków którzy pisali tego typu rzeczy. Dlaczego? Bo kto by pomyślał, że ktoś kiedyś zacznie używać command line w windows? Nawet MS w to nie wierzyło, dlatego przez tyle lat zaniedbywali command line.

Ale wracając, z kompilacją są problemy a by Ci libSass działał, to musisz go skompilować. Kropka. Inną opcją to jest to co on robi w trakcie lub po instalacji – ściąga Ci binakrę. Ale to kwestia wirusów i do tego wrócimy w osobnym punkcie.

Bower posiada starsze paczki niż nuget

Tutaj mnie zatkałeś. Aż musiałem pogrzebać, zrobiłem parę testów na kilku paczkach. Na przykład underscore i wychodzi na to, że nuget był w plecy jeszcze wczoraj (dzisiaj nie wiem). W sensie, częściej się spotykam z tym, że nuget czegoś nie ma lub nie jest zaktualizowany niż bower.

Do tego, nuget wymaga ode mnie akceptacji narzuconej konwencji przez autora paczki lub przez MS. Czego nie znoszę po stronie klienckiej. Nie mam folderu Scripts u siebie, mam Content/js/lib. Wszystkie paczki nuget są u mnie następnie ręcznie kopiowane w odpowiednie miejsce. Czyli coś czego nie lubię baaardzo robić. Aktualizacja też do najlepszych nie należy.

Do tego jak się doda statyczne pliki i TFS to problemy gwarantowane, gdyż aktualizacja paczki ze statycznymi plikami traktowana jest jako operacja USUNIĘCIA pliku i wgrania nowego. Zamiast AKTUALIZACJI i usunięcia tych których nie ma w porównaniu z wcześniejszą paczką. Dlaczego o tym piszę? Bo jak masz 100 plików statycznych w nuget, i masz TFS to dostaniesz 100 razy modal window mówiący, że na pliku jest operacja usuń a ty chcesz to utworzyć czy jakoś tak.

Dla mnie tutaj znów nie ma porównania pomiędzy tym co oferuje nuget a co bower. Nuget może być dla dllek i niech tak zostanie. Ale od strony klienckiej nigdy nie powinien istnieć bo ma za dużo problemów z tym wszystkim.

Jeszcze jeden bardzo ważny problem nuget a który rozwiązuje Bower. Nuget wymaga ode mnie posiadania i checkinowania plików przez niego zainstalowanych. Bower zaś nie. Bower znów jest u mnie lokalnie a nie jest w repozytorium. Oczywiście, podobnie jak z npm, mogli by ludzie więcej uwagi przykładać do budowania paczek, by to miało ręce i nogi a nie było dumpem wszystkiego z projektu.

Problemy open source i opuszczania projektów

To jest ogólnie problem Open Source i na to się nic nie da zrobić. Tak samo jak niektóre firmy tak i tutaj, powstają repozytoria duchy. Plusem jest to (w zależności od licencji), że kod jest dostępny i możemy coś z nim zrobić. Jesteśmy wstanie coś naprawić. Albo sami coś nowego napisać.

Przynajmniej jest opcja. Bo w VS to albo coś jest, albo naprawdę mamy ciężki orzech do zgryzienia bo nie tylko musimy napisać coś co będzie nam coś robiło, ale także zastanowić się nad typem rozszerzenia, co i jak będziemy to robić z UI i co ja muszę dopisać do VS by mi to śmigało.

Zaś paczka która działa dla VS 2010|2 nie koniecznie będzie i na pewno bez re-buildu nie będzie działać na innych VSach. Do tego kodu przeważnie nie ma, a jedynym sposobem kontaktu z programistą jest forum pod rozszerzeniem.

To samo tyczy się paczek nuget.

Ale tak, problem istnieje i istnieć będzie, pytanie czy to naprawdę problem czy feature? Komuś się kiedyś chciało coś napisać, teraz mu się nie chce albo nie ma już czasu, albo może zginął w wypadku samochodowym? Nie wiadomo. Ale masz dostęp do kodu, możesz coś zrobić.

Do tego, przy wyborze paczek, warto jednak zachować jakiś standard wyboru:

• Musi posiadać plik ReadMe
• Musi posiadać repozytorium
• Musi być aktywne w ciągu ostatnich X dni/miesięcy/lat (pytanie czy projekt wymaga aktywności czy może już można spocząć na laurach?)
• Ile osób to pobiera, ile jest issues?

Ogólnie bardzo fajnie to pokazane jest w Understending NPM – warto się zastosować do takich zasad wszędzie – bower, npm, nuget etc.

WebEssentials było lepsze i MS powinno to przywrócić

Tutaj mógłbym pisać i pisać, więc skrócę to do punktów:

• WE 2012 nie miał sass, i korzystał z lessc dla LESS i to jeszcze opakowane w VBScript, który miał kłopot z polskim kodowaniem znakowym w trakcie odczytywania plików. Do tego wprowadzał brak opcji relatywnego odwoływania się plików w LESS. Ogólnie masa problemów. I słabe rozwiązanie.
• WE 2013 miał sass za pomocą… skompilowanego kompilatora SASS, który jest częścią paczki (trochę nawiązuje tutaj do wirusów, bo tutaj ściągasz parę toolsów, nie wiesz co w nich jest, nawet nie wiesz, że je masz, a masz, nie wiesz, że działają a działają), zaś less kompilowany jest za pomocą node. Czyli trochę zmian jest i sposobie działania
• WE 2015 nie posiada nic z tego co wyżej. Ale jest Web Compiler który zawiera to co potrzeba. Teraz jak działa Web Compiler? Znów na node. Nawet zawiera go jako część paczki (7zip) do tego zawiera także 7z.exe. To jak on kompiluje SASS? Tak samo jakbyś to robił ty – node-sass, z tą różnicą iż on ściąga Ci tą dllkę co może zawierać wirusa.

Więc nie wiem tak naprawdę jak WebEssentials miałoby być lepsze od node, kiedy ono z node korzysta. Prawda, było ładnie opakowane, ale moim zdaniem programiści Windows są za bardzo rozpieszczeni myszką – ogólna uwaga. Do tego, MS zawsze coś ograniczał, tutaj nie mamy tych ograniczeń, możemy wszystko tak jak chcemy i więcej niż VS umożliwia.

Obawa o wirusy

Prawda, mają prawo być i istnieć. Jednak popatrz na reputację danego repozytorium, także na to, że to jest github – który zakazuje czegoś takiego. Jakby wyszło, że w popularnym repo jest wirus, to by je zamknęli. Więc bym się nie obawiał aż tak. Do tego masz skanery, możesz przeskanować. Do tego nugetowi wierzysz, a to przecież ktoś u siebie lokalnie kompiluje… więc tutaj raczej bym aż tak bardzo nie panikował.

Ostrożności nigdy za wiele, ale znów, nie wolno przesadzać.

Pytanie o ramdysk itp

Chyba trzeba to rozbić na dwie sprawy, jedno to w ogóle wykorzystanie a drugie to sens wykorzystania tego na lokalnym projekcie na dev maszynie. Niezależnie od kontekstu, pomysł ciekawy, ale trochę imo przekombinowany :)

Jeżeli chodzi o dev maszynę, to nie, nawet nie robię optymalizacji npm, instaluje te paczki które są mi potrzebne i tyle. To jest w końcu dev, robię to raz na projekt, potem by jeszcze sprawdzić czy jakiejś nie pominąłem.

Zaś na build server rozwiązanie to jest trochę przesadne, w sensie pomysł ciekawy, ale za dużo z nim zachodu, do tego typ paczek i wersja mogą się zmieniać, więc to i tak musi być dynamiczne. Nawet po rozpakowaniu w ramdysk co będzie szybkie, to i tak trzeba odpalić prune i install na build serwerze. Tego się nie da pominąć, bo my musimy sprawdzić czy nasz projekt się kompiluje, i czy wszystkie zależności mogą zostać spełnione. Jak tak będzie. To potem wiemy, że za pół roku wykonamy tą samą czynność to nam to zadziała tak jak poprzednio. A to jest bardzo ważne kiedy musimy mieć wsparcie dla poprzednich wersji.

Podsumowanie

Mam nadzieję, że odpowiedziałem na Twoje pytania/wątpliwości. W szczególności te które Cię najbardziej trapiły. Jak nie to daj znać w komentarzu a postaram się już bez posta na to odpowiedzieć :)