Wpis z mikrobloga

@koziolek666: Ale po prostu nie masz pojęcia o temacie. Podpisywanie bibliotek nie na tu nic do rzeczy, bo jeśli autor zrobi npm unpublish to nikt nie może opublikować modułu o tej samej nazwie.
left-pad jest przypadkiem szczególnym, bo szef npm Inc. ręcznie na to pozwolił z weryfikacją identyczności opublikowanego kodu. Nowy autor nie może rozwijać wersji 0.x, a inne moduły korzystały z tej wersji major. Wersja 0.3 jest w pełni archiwalna.
@Ginden: nie rozumiesz na czym polega podpisywanie kodu. I dlaczego jest ono takie ważne.

Ponad to mamy tu dwa problemy. Pierwszy, że brakuje lokalnego repozytorium już ściągniętych bibliotek, ale to pikuś. Drugim jest to, że nawet pomimo oznaczenia biblioteki jako unpublished nie może być tak, że ktoś może coś podstawić pod taką samą nazwą. A takie coś się stało, bo left-pad to tylko niewielki wycinek.

Na chwilę obecną wiele modułów wcześniej
@koziolek666: Co to za stek bzdur. Zależności są złe? Dzięki nim:

a) oszczędzami czas czyli pieniądze bo nie wynajdujemy koła od nowa
b) mamy moduł który jest zarządzany/używany/testowany przez N osób
c) upraszczamy kod bo korzystamy z gotowych funkcji modułu zamiast tworzyć jego imlpementację
d) zmniejszamy koszt wejścia w projekt dla innych programistów, którzy prawdopodobnie ten projekt będą znali

Natomiast zgodzę się z tym że sam NPM jest daleki od ideału,
Drugim jest to, że nawet pomimo oznaczenia biblioteki jako unpublished nie może być tak, że ktoś może coś podstawić pod taką samą nazwą.

@koziolek666: Tylko że jest to możliwe tylko za zgodą firmy zarządzającej repozytorium.

Na chwilę obecną wiele modułów wcześniej zarządzanych przez tego gościa zostało "zesquatowanych" i nie ma pewności czy kod, który pobierasz przy każdym buildzie to ten sam kod, który był tydzień temu w repozytorium.

Mówię, nie masz
@koziolek666: Przeczytaj chociaż co wklejasz:

Piekło zależności (ang. Dependency hell) – potoczny termin określający błędnie zdefiniowane lub trudne do spełnienia zależności, uniemożliwiające lub utrudniające instalację oprogramowania.

Takiej sytuacji w ekosystemie node'a w zasadzie nie ma. Każdy moduł jest zamkniętą całością, która sama sobie instaluje i rozwiązuje zależności. W ten sposób nie ma problemu konfliktów między różnymi zależnościami, npm też automatycznie rozwiązuje cykliczne zależności.
@koziolek666: Jasne zgodzę się że sam zestaw funkcjonalności jest bardzo rozdrobniony, ale sytuacja jest taka sama jak wszędzie, wg mnie to kwestia tego że Node jest jeszcze stosunkowo młody (w sensie hype na niego jest jeszcze cały czas wzrastający) i po prostu pewnych elementów brakuje.

Obecnie w Node jest po prostu duży rozpiździel, bo jest masa modułów np nie korzystających z promise tylko operujących na callbackach, jest masa mini-gówno-modułów typu leftpad
@larvaexotech: Różnica pomiędzy php, a nodeJS leży gdzieś indziej. Node, a w zasadzie sam JS, ma bardzo ubogą bibliotekę standardową. To oznacza, że trzeba dużo rzeczy dopisać samemu.

To na co chciałem zwrócić uwagę to fakt, że w ekosystemie node nastąpiła zbyt duża granulacja. Dodatkowo często jako osobne zależności egzystują rzeczy, które zależnościami być nie powinny.

@Ginden: Do momentu aż pośrednio korzystasz z dwóch różnych wersji tej samej biblioteki i