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.
Jestli jste někdy řešili nasazování aplikace, asi víte, že všechno odladit může být celkem zdlouhavá záležitost. Dokážete si představit, že na to máte jen týden? Že je to nemožné? Není! Jde to a ani to nemusí být příliš složité.
Reportáž z virtuální konference FOSDEM. Minule jsem popsali Go room, dnes se věnujeme monitoringu a observability.
Mikrofrontendy jsou zajímavá adaptace konceptu microservices pro potřeby frontendového vývoje. Podívejte se, co to v praxi obnáší a proč jsme se v Seznam.cz rozhodli vyvinout náš vlastní microfrontend framework, Merkur.
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.pyarequirements.txtapod.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 pritomnyGemfilea 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“,