Riflettendo sui gestori di pacchetti moderni
Di recente stavo parlando con un amico di tutti gli strumenti disponibili che sono oggi sul mercato per noi (alcuni gratuiti, altri open source) che ci aiutano con le nostre esigenze di sviluppo.
Questi includono cose come:
- Grugnito
- Sorso
- Filato
- CodeKit
- Compositore
- e così via.
Ovviamente, ciascuno dei precedenti non è necessariamente confrontabile perché alcuni sono strumenti front-end, altri sono strumenti back-end e ce ne sono alcuni che offrono una sorta di ibrido.
Inoltre, alcuni sono premium, alcuni sono open source, alcuni sembrano essere abbandonati e alcuni hanno persino portato a processi di compilazione interrotti.
Questo porta a una serie di domande molte delle quali vorrei coprire. Quindi qui, se non altro che riflessioni sui moderni gestori di pacchetti, ci sono le cose a cui ho pensato.
Gestori di pacchetti moderni
Le domande che mi sono venute in mente (e di cui stavo discutendo con detto amico) sono le seguenti:
- come dovremmo sapere quale usare,
- quando usarli,
- e se vale la pena restare con loro?
E quindi ho pensato di condividere qui i miei pensieri attuali su detti strumenti e sulla loro applicabilità.
Quali usiamo?
È facile evitare questa risposta e dire "qualunque tu voglia", ma penso che la risposta sia un po’ più sfumata di così.
Ad esempio, ci sono curve di apprendimento, pacchetti, manutenzione e così via che vengono forniti con ciascuno di essi. Questa non è una cosa buona o cattiva – è il naturale di quello che sono.
La domanda che mi interessa di più è "quale è quello che serve meglio il mio team, il mio progetto e i miei clienti?" Ed ecco perché:
- Se il team può adottare facilmente l’utilità, allora non c’è quasi zero attrito per iniziare a utilizzarla per il proprio lavoro.
- Se funziona bene con il progetto fin dall’inizio, dovrebbe facilitare la manutenzione man mano che il progetto cresce e matura. Questo è importante perché altrimenti rischiamo di sprecare tempo e fatica preziosi per mettere le cose al passo quando l’utilità cambia (se cambia) e questo può essere dannoso per la pianificazione di un progetto.
- Ciò che serve meglio al cliente, credo, è una di quelle situazioni in cui "il diavolo è nei dettagli". Questo è così che se i primi due sono soddisfatti, il cliente non sarà più saggio. In secondo luogo, costerebbe meno tempo, fornirebbe più valore e li farebbe investire nell’usarti come fornitore per il loro servizio.
Detto questo, non credo che ci sia un solo caso "Questa è l’utilità che dovresti usare" perché, ancora una volta, non conosco i dettagli di un determinato progetto. Quindi, non voglio prescrivere una soluzione quando un’altra potrebbe adattarsi al caso.
Ed ecco un esempio:
Ho usato Gulp, CodeKit e Yarn in diversi progetti. Sarebbe bello avere un unico strumento da usare? Sicuro! E ognuno può fare relativamente le stesse cose degli altri.
Ma la velocità con cui si avvia qualcosa, la portabilità e i pacchetti disponibili differiscono leggermente e se sto lavorando a qualcosa per me stesso, per un cliente, con un team o da solo sono tutti fattori che entrano nell’equazione .
Nel tempo, credo che sviluppiamo un’intuizione su quale sia il migliore, dati i requisiti di un progetto e data l’esperienza con ciascuno degli strumenti di cui sopra.
Quindi, certo, c’è un investimento in anticipo che è necessario per familiarizzare con tutti quelli che ritieni opportuno per essere vantaggioso per il tuo team e per i tuoi sforzi, ma può servirti bene mentre continui ad andare avanti come sviluppatore.
Quando li usiamo?
Non penso che questa sia una domanda così difficile a cui rispondere se hai fatto la dovuta diligenza nel provarli. Sempre con l’intuizione, giusto?
Ma ecco il mio approccio generale:
- Se lavoro da solo o devo concentrarmi su qualcosa rapidamente, CodeKit è una buona soluzione.
- Se lavoro con un team e ho bisogno di qualcosa di veloce, scalabile e ben definito, Yarn è una buona scelta.
Penso ancora che valga la pena dare un’occhiata a Gulp, ma lo sviluppo e i pacchetti sembrano aver rallentato. Grunt non sembra essere in fase di sviluppo al momento, ma se funziona per te e per i pacchetti di cui hai bisogno, potrebbe non valere la pena cambiarlo in questo momento.
In effetti, direi che a meno che tu non possa fornire una solida ragione per cambiare, allora perché preoccuparsi? La praticità conta.
Vale la pena restare con loro?
Non lo so. Voglio dire, la tecnologia si muove così velocemente e arrivano nuovi strumenti (che non penso necessariamente dovremmo adottare sempre), e poi rimangono per un po’.
Forse ristagnano. Forse non raggiungono un’adozione diffusa. Forse sono in pensione.
Forse la risposta più ottimale a questa domanda è scoprire cosa ti aiuterà a risolvere il problema nel modo più efficiente possibile, che è anche supportato da una comunità attiva di sviluppatori e che tu e il tuo team potete adottare più facilmente?
La linea di fondo?
Semmai, questo post non è altro che riflessioni personali su come affrontare il panorama in continua evoluzione degli strumenti di compilazione e dei gestori di pacchetti. Ed è come ragionare su quando a quale dato un certo tipo di problema.
Non voglio necessariamente un’unica soluzione perché penso che le opzioni che abbiamo promuovano una maggiore innovazione. Allo stesso tempo, può introdurre un livello di affaticamento quando devi tenere il passo.
Quindi, se non altro, esamina un sottoinsieme degli strumenti più popolari (forse contrassegnati su GitHub come metrica utile) e poi vai da lì.