Hogyan kell használni a Dependabot-t a környezet naprakészen tartásához

A függőségek hozzáadása egy projekthez gyakran segít abban, hogy ne találja újra a kereket. De ugyanakkor problémákat okozhat a projekt számos különböző aspektusában:

  • Verziókészítés: néha a függőségek más függőségek meghatározott verzióit igényelhetik, és ez csuklást okozhat az alkalmazásban
  • Csomagolás: Vigyáznia kell, hogy ne kerüljön túl sok extra kódra, amely felduzzasztja a csomagokat
  • Frissítés: A JavaScript gyorsan mozog, és ha nem frissíti rendszeresen a csomagokat, a jövőben a Jengát fogja játszani.

Különböző eszközök léteznek a függőségek frissítésével, például a Dependencies.io, a Snyk és a Dependabot. Mivel egy ideje használom a Dependabot, úgy döntöttem, hogy írok a tapasztalataimról.

A Dependabot egy olyan eszköz, amelyet a GitHub egy évvel ezelőtt vásárolt meg, és ellenőrzi a különböző nyelvű függőségfájlokat (Ruby, JavaScript, Python, PHP, Elixir, hogy csak néhányat említsünk), és megtalálja a projektben használt könyvtárak új verzióit. Itt van a beállítás:

Dependabot képernyőkép

A napi frissítések elsöprőek lehetnek, és úgy gondolom, hogy a heti frissítéseknek jobb költség / haszon. Kihívom magamnak a Pull kéréseket, hogy értesítéseket kaphassak, mihelyt megnyílnak.

Hogyan kell hatékonyan használni a Dependabot-t?

A Dependabot minden egyes PR-ben tartalmazza a kiadási jegyzeteket, a változásnaplókat, a linkeket és a biztonsági réseket, amikor csak lehetséges. Ez azért hasznos, mert megnézheti az információkat, és eldöntheti, folytatja-e vagy sem.

Pragmatikus programozóként azonban szeretnénk biztosítani, hogy a dolgok ne törjenek össze. A PR részletek fontosak, de ennél is többet szeretnénk a projekt összes (vagy szinte minden) teljesítésének szimulációjáról.

CI integráció

Ez a képernyőkép megmutatja, hogy mi történik minden alkalommal, amikor egy PR megnyílik a munkám komponensek könyvtárának alapjában.

  • Tesztek (Jest / Bundle) : A Jest feladat teszteli a React összetevőket, míg a Bundle feladat szimulálja azokat a csomagolási parancsokat, amelyeket futtatunk, amikor frissíteni akarjuk a csomagot az NPM nyilvántartásban
  • Linters (Stíluslapok / JavaScript) : a stíluslapfájlok az egyedi sass-lint beállítást követik, a JS kód pedig az ESLint szabályok sorozatát követi. Ha a PR egy linter új verzióját vezeti be új szabályokkal, akkor ezt meg tudjuk fogni.
  • Cypress (Pillanatkép tesztelése / Kisegítő lehetőségek tesztelése) : ha egy új csomag olyan változtatásokat vezet be, amelyek tükröződhetnek az alkatrészek megjelenésében, a Cypress rögzíti a különbséget, képernyőképet készít róla és tárolja az S3-ban. Mivel a Cypress-nek a dokumentációs webhely élő verziójára van szüksége, a Gatsby építési folyamatát is lefedjük.

Mindezen lépésekkel nagyon valószínűtlen, hogy egy külső csomag megtörje a főágunkat. Dicséret munkatársamnak, Grant Lee-nek, aki szintén ezen a projekten dolgozik.

A blogomra is felkerült. Ha tetszik ez a tartalom, kövessen a Twitteren és a GitHub-on. Zhang Kenny borítóképe az Unsplash-on