Kui te olete tarkvaraarendaja, siis teate ilmselt juba, et üks teie paljudest rollidest ei ole kindlasti järjekordne ratta leiutaja. Vähemalt mitte enamikul juhtudel.
Tahaksin kirjutada järgmistest teemadest JavaScript sõltuvused. Aga alustame algusest. Kui te olete tarkvaraarendaja, siis teate ilmselt juba, et üks teie paljudest rollidest ei ole kindlasti järjekordne ratta leiutaja. Vähemalt mitte enamikul juhtudel. Maailm on jõudnud piisavalt kaugele, et öelda, et tänapäeval on olemas paketid peaaegu kõigeks, mis teevad meie arenduse lihtsamaks ja tõhusamaks.
See ei ole muidugi julgustus, et kaotada huvi teiste teemade vastu - igal paketil on üsna suur ruum, mida parandada ja arendada. Siiski on teie äriline eesmärk tuua täielik toode taldrikul just õigel ajal või isegi enne seda, kui see on üles. Paketid aitavad teil neid plaane täita, tuues npm või lõng oma parimate sõprade nimekirja tipus, kuid olge teadlik: iga lahendus, nagu ka see, võib tuua kaasa ka riski. Ja me püüame seda kirjeldada ja näidata teile allpool olevas artiklis paremaid võimalusi, kuidas sellest pääseda.
Alustame ühe looga...
Kujutage ette suurt JavaScript projekt. Ärinõue kohustab arendajaid kasutama konkreetset paketti, mis võimaldab nõuetekohast integreerimist kliendi teise süsteemiga. Ja see on täiesti okei. MVP on õigeaegselt toodud, järgmine leping on sõlmitud ja arendus jätkub. Klient palub integreerida süsteemi järgmine osa, mis nõuab teie paketi uuendamist.
See osa läheb hästi, kuni testid on tehtud. Tundub, et pakett sisaldab lihtsat, kuid ebamugavat viga, mida ei ole veel üheski tooteväljaandes parandatud ja on teada, et see ei juhtu niipea. Te ei saa lihtsalt parandada oma node_modules kataloog - see tuleks eemaldada teie repositooriumist jälgimisest, seega ei saa teie kaastöötajad kunagi midagi teie muudatustest teada! Noh, seda lugedes olete ilmselt juba aru saanud, mida teha - fork. Aga kas sul on tõesti sellist haamrit vaja?
Mõista oma probleemi
Te peate olema teadlik, kas probleem, millega te silmitsi seisate, puudutab ainult teid või suuremat kogukonda. Mõnikord tõlgendavad inimesed teatud funktsionaalsuse puudumist veana, mis ei ole alati õige. Seetõttu, teie lahendust ei pruugi kogukond heaks kiita ja see ei pruugi olla lisatud ametlikku repositooriumi.. Siiski vajate seda siin ja praegu. Noh, lappame seda!
Vastavalt githubi repositooriumi avaldamismärkuste kohaselt on patch-pakett ) ilmus ametlikult 2017. aasta mais. It on võimas tööriist, mis võimaldab muudatusi sõltuvusprojekti sees paigaldada oma node_modules kataloog. Mõned võivad öelda, et see on üsna hullumeelsus - tulistades installida käsk teie sõltuvuse haldur kirjutab muudatused üle.
Noh, see on õige. Siiski, plaaster-pakett eksisteerib koos npm ja lõng ideaalselt (pean tunnistama, et npm-iga töötab see seni veidi paremini, täpsemalt saab lugeda README faili peatükist "Miks peaksite kasutama postinstall-prepare koos Yarniga?") ja kasutab täielikult ära teie skripti ettevalmistamise ("script": { "prepare":""}) oma package.json faili. Patch-package loob sõna otseses mõttes dif-kataloogi teie muudatuste ja originaalpaketi vahel, mis on salvestatud teie tegeliku projekti patch-kausta sisse..
Pärast install-käsu käivitamist ja kõigi sõltuvuste allalaadimist rakendab ta selle erinevuse projekti kataloogi, tehes teie muudatuste täiusliku rekonstruktsiooni kõigile koostööpartneritele. See teeb teie elu lihtsamaks, kas pole? Sellel lahendusel on ka mõned puudused. Patch-pakett ei saa parandada teie paketi sõltuvusi ega teha mingeid muudatusi package.json.
Sellisel juhul võite kasutada kahvlilahendit. Samuti peate arvestama, kui palju muudatusi te kavatsete oma sõltuvuspaketti rakendada ja kas need aja jooksul kasvavad. Juhul kui on - peate hoolikalt mõtlema, kui kasutate forki, sest see on teie enda projekt.
Ära ole egoistlik!
Paigaldamine on suurepärane võimalus parandada oma sõltuvusi ilma lõputute hargnemiste ja mitmete projektiallikate loomiseta. Kuid te peaksite alati meeles pidama, et kogukonna ärakasutamine ei tohiks olla ühesuunaline. Kui leiate vea või tunnete, et saate kasutatavat paketti parandada, peaksite alati kaaluma teiste aitamist, registreerides probleemi või isegi panustades projekti!