Pentu că (încă) un manager de pachete n-a omorât pe nimeni, Facebook a lansat o versiune proprie: Yarn.
Câteva extrase interesante:
Yarn is a new package manager that replaces the existing workflow for the npm client or other package managers while remaining compatible with the npm registry. It has the same feature set as existing workflows while operating faster, more securely, and more reliably.
.
The npm client installs dependencies into the node_modules directory non-deterministically. This means that based on the order dependencies are installed, the structure of a node_modules directory could be different from one person to another. These differences can cause “works on my machine” bugs that take a long time to hunt down.
Yarn resolves these issues around versioning and non-determinism by using lockfiles and an install algorithm that is deterministic and reliable. These lockfiles lock the installed dependencies to a specific version, and ensure that every install results in the exact same file structure in node_modules across all machines. The written lockfile uses a concise format with ordered keys to ensure that changes are minimal and review is simple.
.
[…] Yarn is able to parallelize operations, which maximizes resource utilization and makes the install process faster. On some Facebook projects, Yarn reduced the install process by an order of magnitude, from several minutes to just seconds.
npm-ul are o structura diferita fata de pip / Rubygems tocmai din limitele impuse de acestea.
npm ca volum a depasit orice package manager, automat apar si cerinte noi. modulecounts.com.
Acel “JS-world” are provocari multiple:
versiuni diferite de specificatii – ES5 vs ES6
environmente cu versiuni si capabilitati diferite
node.js (server) - v4 vs v6
IE9 vs Chrome vs Safari
webview - iOS vs Android
embedded hardware - capabilitati limitate
codul sursa este distribuit over the wire – size matters – women tried to warn us, but who listens?
Pe server ai control, stii ce poti instala sau nu, in browser / webview nu; singurul lucru care-l poti face e “feature detection” si build-uri speciale.
Cerintele clientilor sunt de genul: “aceeasi aplicatie sa mearga bine in browser, impachetat in webview pe Android / iOS, a si suportam IE9+”.
Este dificil sa faci build-uri pt. platforme multiple daca nu poti specifica ordinea de incarcare a modulelor, hence “non-determinism” si shrinkwrap.
Cand ai o aplicatie de 50+ module un deploy la un update poate fi destul de provocator, mai ales daca ai lucrat la un modul care depinde de alte 7 module din npm la care nu ai niciun control.
In 2012 a aparut Bower si Component.io pt. ca npm era foarte deficitar pe parte de frontend. Acum npm v3 pare sa mai rezolve din minusuri dar a scazut foarte mult in performanta si tot nu este o solutie viabila.
Yarn pare sa rezolve unele din problemele pe care npm le ignora de cativa ani, in special pe parte de frontend.
In prezent pe unele servere de productie folosesc pnpm - performant npm, sunt diferente mari in performanta.
I’ve also worked on a couple of application-level package managers (Bundler for Ruby and Cargo for Rust), so it’s no surprise that people have routinely asked me whether I’d consider writing a “bundler for node”.
Au ajuns la concluzia ca au nevoie sa emuleze un bundler pt. node, pe care l-au scris < 9 luni odata ce au realizat asta?
Project’s page [1]:
Yarn wouldn’t exist if it wasn’t for excellent prior art. Yarn has been inspired by the following projects: Bundler, Cargo, npm
Deci in final they caved in si au apelat la tested and proven package managers design.
Insa in loc sa faca asta in npm au ales in schimb metoda [2]:
i.e. [3]
This joins a list of other third-party registry clients that include ied, pnpm, npm-install and npmd. (Apologies if we missed any.)
Dap, foloseste npm repositories insa prin propriul proxy, chiar daca este for speed reasons si doar un mirror.
Utilizand asta de la bun inceput in viitor le va fi foarte usor to cut off the npm repo. (conspiracy theory time )
Si in sfarsit de ce nu au contribuit catre npm? deja exista shrinkwrap why not improve it? just for the sake of more fragmentation and politics?
bundler si npm au aparut in acelasi an. npm-ul a fost mult timp one man show, Isaacs s-a focusat mult timp pe partea de storage, bundler avea deja rubygems.
npm ca si organizatie nu a avut resurse pt. rescrierea npm v3, au facut imbunatatiri incrementale dar nu sunt suficiente. Au fost multe issues deschise pe github pt. imbunatatiri, dar le-au cam ignorat.
Au precizat de multe ori ca se focuseaza pe partea de transfer si storage, au 1,000,000,000+ downloads pe saptamana, totul fiind free pt. users.
In opinia mea Yarn o sa fie binevenit pt. ei, ii scapa de partea de “frontend” si se pot focusa pe business-ul npm, partea de API.
La cat de mult foloseste FB. JS-community those costs should be pennies, pennies for them!
De altfel npmjs - scot profit din ceea ce fac.vs. de restul (Cargo, RubyGems, pip/PyPI, hex, etc.) unde nici nu se pune problema de asa ceva - which is mind boggling.
De atlfel sunt companii cu resurse infinite relativ cu alte limbaje care aparent they just poke things instead to help un-fragment the community.
Cu cat avansez mai mult in the brave-new-JS-world cu atat ma intreb mai des:
wth is wrong here? how can you mess up with such consistency for years?
Proiectul e binevenit din punctul meu de vedere.
Punctez faptul ca repo-ul are o licenta BSD fata de restul proiectelor marca FB, care au GPL + patent license disclaimer.
In urma comentariilor citite de pe reddit + hackernews, motivele sunt urmatoarele:
clientul original npm e foarte greu de modificat, codebase mare si vechi + foarte multi oameni/environment-uri care trebuiesc suportate
Facebook && altii fac o tona de deployment-uri, deci la ei problemele pe care majoritatea le intalnesc foarte rar sunt dese (versiuni diferite in dev vs staging, a uita sa faci shrinkwrap din nou dupa ce instalezi un nou modul, strategii de caching suboptimale)
Totusi asta nu inseamna ca toti vor trece la yarn de maine, pentru ca sincer pentru majoritatea nu sunt probleme uzuale. Daca faci un deploy de 1-2 ori pe zi si nu vrei sa faci neaparat lock pe versiuni fixe (cu shrinkwrap) nu te afecteaza atat de mult. Plus de asta, mai sunt si alte solutii pentru diversele probleme cu npm, ca de exemplu https://github.com/mixu/npm_lazy
)
