Ensiapu rikkoutuneisiin JavaScript-riippuvuuksiin

Haluaisin kirjoittaa JavaScript riippuvuudet. Aloitetaan kuitenkin alusta. Jos olet ohjelmistokehittäjä, tiedät luultavasti jo, että yksi monista rooleistasi ei todellakaan ole olla jälleen yksi pyörän keksijä. Et ainakaan useimmissa tapauksissa. Maailma on edennyt sen verran pitkälle, että nykyään on olemassa paketteja lähes kaikkeen, mikä helpottaa ja tehostaa kehitystämme.

Tämä ei tietenkään kannusta menettämään kiinnostusta muihin asioihin - jokaisella paketilla on melko paljon tilaa parantua ja kehittyä. Liiketoimintasi tavoitteena on kuitenkin tuoda täydellinen tuote lautaselle juuri ajoissa tai jopa ennen kuin se on ylhäällä. Paketit auttavat sinua toteuttamaan nämä suunnitelmat, tuoden mukanasi npm tai lanka parhaiden ystäviesi listan kärjessä, mutta ole tietoinen siitä, että mikä tahansa ratkaisu, kuten tämäkin, voi tuoda mukanaan myös riskejä. Ja me yritämme kuvata sitä ja näyttää sinulle paremman tavan selvitä siitä alla olevassa artikkelissa.

Aloitetaan tarinalla...

Kuvittele suuri JavaScript projekti. Liiketoimintavaatimus velvoittaa kehittäjät käyttämään tiettyä pakettia, joka mahdollistaa asianmukaisen integroinnin asiakkaan toisen järjestelmän kanssa. Ja se on täysin oikein. MVP on tuotu ajoissa, seuraava sopimus on allekirjoitettu ja kehitys jatkuu.. Asiakas pyytää integroimaan järjestelmän seuraavan osan, joka edellyttää pakettisi päivitystä.

Tämä osa sujuu hyvin, kunnes testit tehdään. Näyttää siltä, että paketti sisältää yksinkertaisen, mutta epämukavan bugin, jota ei ole vielä korjattu missään tuoteversiossa, ja tiedetään, että näin ei tapahdu tarpeeksi pian. Et voi vain korjata node_modules hakemisto - se pitäisi poistaa arkistostasi seurannasta, joten yhteistyökumppanisi eivät koskaan saa tietää mitään muutoksistasi! No, tätä lukiessasi olet luultavasti jo ymmärtänyt, mitä pitää tehdä - haarukoida. Mutta tarvitsetko todella tällaista vasaraa?

Ymmärrä ongelmasi

Sinun on oltava tietoinen siitä, koskeeko kohtaamasi ongelma vain sinua vai laajempaa yhteisöä. Joskus ihmiset tulkitsevat tietyn toiminnallisuuden puutteen bugiksi, mikä ei aina pidä paikkaansa. Siksi, yhteisö ei välttämättä hyväksy ratkaisua, eikä sitä sisällytetä viralliseen arkistoon.. Tarvitset sitä kuitenkin vielä tässä ja nyt. No, korjataan se!

Github-tietovaraston julkaisutietojen mukaan patch-paketti ) julkaistiin virallisesti toukokuussa 2017. It on tehokas työkalu, jonka avulla riippuvuusprojektin sisällä tehdyt muutokset voidaan asentaa omaan node_modules hakemisto. Jotkut saattavat sanoa, että tämä on melko hulluutta - ampuminen asennuskomento riippuvuushallintasi korvaa muutokset.

No, tämä on oikein. Korjauspaketti on kuitenkin rinnakkain seuraavan kanssa. npm ja lanka täydellisesti (täytyy myöntää, että se toimii toistaiseksi hieman paremmin npm:n kanssa, voit lukea lisää README-tiedoston kohdasta "Why you should use postinstall-prepare with Yarn?") ja hyödyntää täysin skriptin valmistelua ("script": { "prepare":""}) sinun package.json tiedosto. Patch-package luo kirjaimellisesti diff-hakemiston muutosten ja alkuperäisen paketin välille, joka tallennetaan varsinaisen projektin patch-kansioon..

Kun install-komento on suoritettu ja kaikki riippuvuudet ladattu, se soveltaa tätä eroa projektin hakemistoon, jolloin muutoksistasi saadaan täydellinen rekonstruktio kaikille yhteistyökumppaneille. Se tekee elämästäsi yksinkertaisempaa, eikö totta? Ratkaisulla on myös joitakin haittoja. Korjauspaketti ei voi korjata pakettisi riippuvuuksia tai tehdä muutoksia osoitteeseen package.json.

Tässä tapauksessa voit käyttää haarukkaratkaisua. Sinun on myös otettava huomioon, kuinka monta muutosta aiot soveltaa riippuvuuspakettiisi ja kasvavatko ne ajan myötä. Jos tulee - sinun on harkittava tarkkaan, kun käytät fork:ta, koska kyseessä on oma projektisi.

Älä ole itsekäs!

Korjaaminen on loistava tapa korjata riippuvuuksia ilman loputtomia haarautumisia ja useiden projektilähteiden luomista. Sinun tulisi kuitenkin aina muistaa, että yhteisön hyödyntäminen ei saisi olla yksisuuntaista. Jos löydät bugin tai tunnet voivasi parantaa käyttämääsi pakettia, sinun kannattaa aina harkita muiden auttamista rekisteröimällä ongelma tai jopa osallistumalla projektiin!