Primo soccorso per le dipendenze JavaScript interrotte

Vorrei scrivere su JavaScript dipendenze. Ma partiamo dall'inizio. Se siete uno sviluppatore di software, probabilmente sapete già che uno dei vostri numerosi ruoli non è certo quello di essere l'ennesimo inventore di ruote. Almeno, non nella maggior parte dei casi. Il mondo è andato avanti abbastanza da poter dire che oggi esistono pacchetti per quasi tutto, che rendono il nostro sviluppo più semplice ed efficiente.

Naturalmente questo non è un incoraggiamento a perdere interesse per altre questioni: ogni pacchetto ha un ampio spazio per migliorare ed evolvere. Tuttavia, il vostro obiettivo commerciale è quello di portare un pacchetto completo di prodotto su un piatto appena in tempo o addirittura prima che sia finito. I pacchetti vi aiuteranno a realizzare questi piani, portandovi npm o filato in cima alla lista dei vostri migliori amici, ma sappiate che ogni soluzione, così come questa, può comportare dei rischi. E noi cercheremo di descriverlo e di mostrarvi un modo migliore per cavarvela nell'articolo che segue.

Cominciamo con una storia...

Immaginate un grande JavaScript progetto. I requisiti aziendali obbligano gli sviluppatori a utilizzare un pacchetto specifico, che consente una corretta integrazione con un altro sistema del cliente. E questo va benissimo. MVP è stato portato in tempo, il contratto successivo è stato firmato e lo sviluppo è proseguito.. Il cliente chiede di integrare la parte successiva di un sistema, che richiede l'aggiornamento del vostro pacchetto.

Questa parte va bene, finché non vengono eseguiti i test. Sembra che il pacchetto contenga un semplice, ma scomodo bug, che non è ancora stato risolto in nessuna release del prodotto e si sa che ciò non avverrà abbastanza presto. Non si può semplicemente riparare il nodo_moduli elenco - dovrebbe essere rimosso dal vostro repository dal tracciamento, quindi i vostri collaboratori non sapranno mai nulla delle vostre modifiche! Mentre leggete queste righe, probabilmente avete già capito cosa fare: fork. Ma avete davvero bisogno di un martello del genere?

Comprendere il problema

Dovete essere consapevoli se il problema che state affrontando coinvolgerà solo voi o una comunità più ampia. A volte, le persone interpretano la mancanza di alcune funzionalità come un bug, il che non è sempre corretto. Pertanto, la vostra soluzione potrebbe non essere accettata da una comunità e non essere inclusa in un repository ufficiale. Tuttavia, ne avete ancora bisogno qui e ora. Bene, mettiamo una toppa!

Secondo le note di rilascio del repository github, il pacchetto di patch ) è stato rilasciato ufficialmente nel maggio 2017. Iè uno strumento potente, che permette di installare le modifiche all'interno del progetto di dipendenza nel vostro nodo_moduli elenco. Alcuni potrebbero dire che si tratta di una follia: il comando di installazione del gestore delle dipendenze sovrascriverà le modifiche.

Ebbene, questo è corretto. Tuttavia, un pacchetto di patch coesiste con npm e filato perfettamente (devo ammettere che per ora funziona leggermente meglio con npm, potete leggere di più nella sezione "Perché dovreste usare postinstall-prepare con Yarn?" del file README) e sfrutta appieno la preparazione dello script ("script": {"prepare":""}) del vostro pacchetto.json file. Patch-package crea letteralmente una cartella di diff tra le modifiche apportate e il pacchetto originale, memorizzata nella cartella patch del progetto attuale..

Dopo aver eseguito il comando install e scaricato tutte le dipendenze, applica la differenza alla directory del progetto, creando una ricostruzione perfetta delle modifiche per tutti i collaboratori. Questo semplifica la vita, non è vero? La soluzione presenta anche alcuni svantaggi. Il pacchetto patch non può correggere le dipendenze del vostro pacchetto né apportare modifiche in pacchetto.json.

In questo caso si può usare la soluzione fork. Inoltre, bisogna considerare il numero di modifiche che si stanno per applicare al pacchetto di dipendenze e se queste cresceranno nel tempo. In caso affermativo, si dovrebbe pensare attentamente all'uso di fork, poiché si tratta di un progetto proprio.

Non siate egoisti!

Il patching è un ottimo modo per risolvere le dipendenze senza creare fork infiniti e generare più sorgenti di progetto. Ma bisogna sempre ricordare che il vantaggio della comunità non deve essere unidirezionale. Se trovate un bug o ritenete di poter migliorare il pacchetto che state utilizzando, dovreste sempre considerare di aiutare gli altri registrando un problema o addirittura contribuendo al progetto!