Komentáře k článku
Jak (ne)psat webové aplikace – verzování

Při psaní aplikací v Node.js občas narazím na moduly obsahující zbytečné nedostatky, které vývojářům komplikují jejich používání. Následující článek rozebírá první z nich, a to chybné verzování modulů. Článek se zaměřuje na Node.js, nicméně postupy zde uvedené platí i pro ostatní jazyky a platformy.
Dodatek pro Python svět
Pěkný článek, díky! Kdyby někoho zajímalo něco k této problematice z Python světa, dávám odkaz na zajímavý článek – https://caremad.io/blog/setup-vs-requirement/ Tam se rozebírá například i rozdíl mezi závislostmi v
setup.py
arequirements.txt
apod.Moje strategie
Po mnoha letech programování v mnoha různých prostředích jsem došel k tomu, že verze závislostí specifikuju pokud možno exaktně. Omezuje to počet proměnných, které vstupují do hry. Výsledkem je shodné prostředí u všech uživatelů a vývojářů, méně problémů při rozběhávání aplikací, méně chybových hlášení u open source projektů atd.
Sémantické verzování je sice teoreticky pěkná věc, ale v praxi má málo projektů API popsané na takové úrovni, aby bylo jasné, co je součástí kontraktu (a tedy podléhá verzovacím pravidlům) a co nikoliv (a tedy se může kdykoliv rozbít). Snadno se tak stane, že se můj kód stane závislý na nějakém chování, které je v příští patch verzi změněno.
Na Node.js a npm je super, že strategie exaktních verzí je v něm technicky možná. Není problém, pokud používám knihovny A a B, přičemž A vyžaduje C ve verzi 1.2.3 a B ji chce ve verzi 1.3.0. Knihovna C je prostě nainstalována a nahrána dvakrát. Třeba v Ruby světě to takhle nefunguje, protože není možné nahrát najednou víc verzí jedné knihovny (kvůli tomu, že definované třídy jsou efektivně uložené v globálních proměnných, takže by se navzájem přepsaly). Verze závislostí u knihoven se tak musí specifikovat volněji, aby nedocházelo ke konfliktům při kombinování různých knihoven v aplikacích. Přiznávám, že se mi to vůbec nelíbí, ale Ruby takhle bohužel funguje.
Re: Moje strategie
David dovolim si vyjadrit nesuhlas s tvojim tvrdenim „Třeba v Ruby světě to takhle nefunguje, protože není možné nahrát najednou víc verzí jedné knihovny„.
Este rok dva dozadu som toto riesil oklukou cez tzv. gemsety v
rvm
. A dnes uz netreba ani to, v Ruby jebundler
. Ten umoznuje nainstalovat X verzii toho isteho gemu. Vsetky sa sice nainstaluju (by default) do globalneho gemsetu, ale ked je v projekte pritomnyGemfile
a projekt sa „exekuuje“ pomocoubundle exec
, projekt dostane vzdy pozadovanu verziu. Viac napr. tu (jeden z tisica podobnych clankov).Nie je to take elegantne ako pri
npm
, ale ucel to plni rovnaky. Okrem toho, aj bundler je mozne nastavit aby gemy instaloval do adresara v projekte, nie na nejake globalne miesto.Re: Moje strategie
Nerozumíme si. Instalace víc verzí knihovny samozřejmě není problém a o zmiňovaných řešeních vím. Jde mi ale o to, že nejde nahrát (pomocí
require
) a současně používat dvě různé verze stejné knihovny v rámci jedné aplikace. Takže pokud mají dva gemy, které chci používat, konflikní závislosti (ve smyslu verzí), mám problém.x pri verzii
A čo urobí v package.json:
„socket.io“: „0.9.x“,