Il costo delle dipendenze

npm install è la decisione più veloce nello sviluppo software. Hai un problema, qualcun altro lo ha risolto, il pacchetto ha centomila download settimanali e un badge verde su shields.io. Lo aggiungi, funziona, vai avanti.

Il costo non si vede subito. Si vede diciotto mesi dopo, quando il pacchetto viene abbandonato, o ha un breaking change in una versione major, o ha una vulnerabilità da patchare, o ha accumulato silenziosamente cinque livelli di dipendenze transitive che non sapevi di star distribuendo.

Ho mantenuto applicazioni in produzione per anni. I pacchetti di cui mi sono pentito raramente sono quelli grandi — React, Express, un driver per il database. Sono quelli piccoli, aggiunti per comodità, che si sono rivelati più difficili da rimuovere che da scrivere io stesso in primo luogo.

Cosa ti stai effettivamente prendendo in carico

Quando aggiungi una dipendenza, non stai solo aggiungendo codice. Ti stai prendendo in carico una relazione con un maintainer che non hai mai incontrato, le cui priorità potrebbero non coincidere con le tue, che potrebbe abbandonare il progetto domani o introdurre un breaking change senza preavviso.

Stai anche aggiungendo superficie. Ogni dipendenza è un vettore per attacchi alla supply chain, diventati sempre più comuni e sofisticati. L'incidente event-stream nel 2018, il sabotaggio di colors e faker nel 2022 — non erano casi limite oscuri. Hanno colpito milioni di progetti. Più pacchetti ci sono nel tuo albero di dipendenze, più rischi assorbi.

E stai aggiungendo attrito agli upgrade. Un progetto con duecento dipendenze è sostanzialmente più difficile da tenere aggiornato rispetto a uno con trenta. Patch di sicurezza, breaking change, conflitti tra peer dependency — si sommano. Il progetto che sembrava privo di debito tecnico il primo giorno lo accumula invisibilmente, nella cartella node_modules, ogni volta che aggiungi qualcosa di nuovo.

Le domande che mi faccio prima di aggiungere un pacchetto

Non ho una regola rigida contro le dipendenze — sarebbe impraticabile. Ma mi faccio una breve serie di domande prima di aggiungere qualsiasi cosa:

Posso scriverlo in meno di un'ora? Una funzione che genera uno slug da una stringa, formatta una data o clona in profondità un oggetto non vale una dipendenza. Vale venti righe di codice che possiedo e posso modificare senza chiedere il permesso a nessuno.

Il pacchetto è mantenuto attivamente? Ultimo commit due anni fa, quaranta issue aperte, nessuna risposta dal maintainer — è un pacchetto sulla via dell'abbandono. I numeri di download potrebbero ancora sembrare buoni perché nessuno ha pulito le proprie dipendenze. Il progetto è già morto.

Com'è l'albero delle dipendenze? Alcuni pacchetti sono wrapper sottili attorno ad altri pacchetti che wrappano altri pacchetti. Pensavi di aggiungere una cosa; ne hai aggiunte trenta. Esegui npm ls prima di fare commit.

Cosa succede se questo pacchetto scompare? Se la risposta è "dovrei riscrivere una parte core dell'applicazione", è un pacchetto che probabilmente dovresti scrivere tu stesso, o almeno nascondere dietro un'interfaccia per poterlo sostituire.

Quando le dipendenze valgono chiaramente il costo

Alcuni pacchetti rappresentano complessità genuina che non dovresti cercare di possedere. Un media server WebRTC, una libreria per generare PDF, un SDK per i pagamenti, un motore di ricerca full-text. La conoscenza di dominio incorporata in quei pacchetti ha richiesto anni per svilupparsi. Il costo di reimplementarli da zero non è un'ora — sono mesi, e si sbaglierebbero comunque in modi che la produzione rivelerebbe lentamente.

mediasoup è un buon esempio. Costruire un SFU da zero sarebbe un progetto pluriennale. Aggiungere mediasoup come dipendenza è una scommessa ragionevole su un progetto ben mantenuto e attivamente sviluppato, supportato da un utilizzo reale. L'alternativa non è realistica.

La stessa logica vale per qualsiasi pacchetto che risolve bene un problema genuinamente difficile. La domanda è se il problema sia davvero difficile o se lo sembri solo in quel momento.

La trappola del build vs. buy

C'è una versione di questo ragionamento che porta in un posto sbagliato: costruire tutto da soli perché non ci si fida delle dipendenze. Non è quello che sto dicendo.

L'obiettivo è essere deliberati. La maggior parte delle decisioni npm install avviene in modo riflessivo, senza pensare molto a cosa si sta scambiando. Il pacchetto ti fa risparmiare venti minuti oggi. La domanda è se costerà più di venti minuti nel corso della vita del progetto — in upgrade, nel debug di problemi transitori, nella gestione dei breaking change, nel carico cognitivo di tenere traccia di cosa fa ogni pacchetto nel tuo albero.

Per le piccole utility, la matematica di solito favorisce scriverle da soli. Per librerie complesse e ben mantenute che risolvono problemi genuinamente difficili, la matematica favorisce la dipendenza. L'errore è eseguire npm install senza fare i conti.

Come appare nella pratica

In Barba Studio, tengo deliberatamente basso il numero di dipendenze. La logica core di booking — scheduling, rilevamento dei conflitti, calcolo della disponibilità — è tutta codice custom. Sono le parti dell'applicazione più specifiche per il dominio, più soggette ad aggiustamenti man mano che il prodotto evolve, e più importanti da comprendere completamente. Aggiungere una libreria di scheduling mi farebbe risparmiare una settimana inizialmente e mi costerebbe ogni volta che il prodotto deve divergere da ciò che la libreria si aspetta.

Le dipendenze che uso sono quelle in cui l'alternativa è genuinamente irragionevole: il framework, il driver del database, il processore di pagamento, l'SDK per le email. Tutto il resto lo scrivo.

---

Le dipendenze sono strumenti, non scorciatoie. Ogni pacchetto che aggiungi è una piccola scommessa che il codice di qualcun altro continuerà a funzionare, continuerà a essere mantenuto e continuerà a essere compatibile con tutto il resto nel tuo stack. Queste scommesse di solito vanno bene. Vale la pena farle consapevolmente.