Responsible disclosure: esposizione della cartella .git su di un sito di comparazione prezzi

responsible disclosure

Era un normalissimo Lunedì mattina. Come sempre, prima di iniziare a lavorare, stavo facendo una navigata sul web. Ero appena entrato sul sito di una compagnia di comparazione prezzi quando una notifica del browser cattura la mia attenzione: Found an exposed .git.

L’estensione del browser che utilizzo per verificare automaticamente se un sito web ha la cartella /.git esposta ne aveva appena beccato uno.

Ops, ho appena trovato una cartella .git pubblicamente accessibile

Se non sei uno sviluppatore ti starai chiedendo: “è quindi”? Se invece conosci Git sai già quanto possa essere potenzialmente grave avere la cartella .git pubblicamente accessibile.

Infatti attraverso l’accesso a quella cartella sono riuscito ad estrapolare le chiavi di accesso al database!

A livello puramente teorico, in assenza di ulteriori meccanismi di protezione, ottenere credenziali del genere potrebbe garantire ad un malintenzionato l’accesso in lettura e scrittura ai dati di tutti gli utenti della piattaforma (username, hash di password, ecc…).

Ma prima di vedere nel dettaglio che strumenti ho usato per accorgermi della vulnerabilità e come è andata a finire la storia lasciami presentare. Io sono Lorenzo Millucci e sono un ingegnere del software che ama lavorare con Symfony e a cui piace condividere in questo blog le cose che impara. Iscriviti al mio canale Telegram per non perderti nessuna notizia!

Cos’è Git?

Andiamo con ordine. La prima cosa che ti serve sapere per capire quale sia stato il problema di sicurezza è capire cosa sia Git e perché avere accesso a quella cartella è un problema di sicurezza.

Git è un popolarissimo software utilizzato dagli sviluppatori per tracciare le modifiche del codice sorgente (versionamento) creato da Linus Torvalds (il creatore di Linux) nel 2003.

Per tracciare tutti i cambiamenti all’interno di una codbase, Git mantiene tutti i (meta-)dati necessari all’interno di una cartella nascosta chiamata .git.

Normalmente Git è uno strumento utilizzato esclusivamente internamente ai team di sviluppo e i meta-dati che produce non sono accessibili pubblicamente. Può però capitare che a causa di una dimenticanza o di una cattiva configurazione del server questa cartella non venga opportunamente protetta e che sia quindi leggibile da chiunque.

Avendo accesso alla cartella .git è possibile estrapolare diverse informazioni sensibili sul sito web semplicemente guardando i file in essa contenuti:

  • .git/config: è il file di testo utilizzato da git per tracciare le informazioni generali sul repository (es. l’URL del server con il repository, l’username, le branch attive… )
  • .git/index: è il file contente l’indice di tutti i file presenti nel repository e di tutte le modifiche fatte. Il file è in formato binario ma esistono dei tool appositi in grado di leggerne il contenuto.
  • .git/objects: è la cartella che contiene tutte i file del progetto. Tutti i file sono salvati senza estensione e utilizzando l’hash SHA1 come file name. E’ da questa cartella che è possibile estrapolare dati sensibili del sito web.

Come mi accorgo di una cartella .git esposta pubblicamente?

Ora che hai capito cos’è Git ti chiederai come si fa a verificare se la cartella .git è pubblicamente accessibile su una web-app.

Il metodo più semplice (e più macchinoso) per verificare se una cartella .git è esposta pubblicamente è quello di provare a modificare l’URL della pagina aggiungendo di volta in volta il percorso alla cartella .git nel seguente modo:

  • https://example.com/.git/config
  • https://example.com/.git/HEAD
  • https://example.com/.git/logs/HEAD
  • https://example.com/.git/index

Siccome farlo manualmente è una scocciatura è possibile scaricare un estensione del browser (per Firefox e Chrome) chiamata DotGit che permette di effettuare la verifica automaticamente. Nel caso in cui i file sono pubblicamente accessibili l’estensione lo farà presente immediatamente con una notifica.

Che ci faccio con la cartella .git?

Ora arriva la parte divertente. Una volta che ho trovato una cartella Git esposta tutto quello che devo fare è utilizzare un software chiamato GitTools per scaricare ed estrarre automaticamente tutto il codice lasciato incustodito.

Per scaricare il contenuto della cartella .git basta dare il comando:

./Dumper/gitdumper.sh https://example.com/.git/ /output-directory/

Siccome spesso i repository vengono compressi può succedere che i dati scaricati non siano immediatamente leggibili. Proprio per questa evenienza i GitTools mettono a disposizione un altro strumento che permette di carpire quanta più informazione possibile dal repository scaricato.
Per usare questo strumento il comando da utilizzare è:

 ./Extractor/extractor.sh /output-directory/ /output-directory-extracted/

Una volta che il tool avrà finito di estrarre il contenuto della cartella sarà possibile esplorare il codice sorgente. A seconda dell’applicazione web è possibile cercare all’interno del codice chiavi di accesso, credenziali hardcodate, nuovi endpoint segreti, ecc…

Disclosure

Ma ritorniamo a Lunedì mattina. Avevo appena ricevuto la notifica da parte di DotGit. Ero abbastanza stupito che un sito così famoso avesse potuto commettere un errore tanto banale senza che nessuno se ne accorgesse.

Così ho provato a vedere cosa ci fosse all’interno del repository utilizzando i GitTools e mi sono accorto che tra i file c’era il file di configurazione .env contenete le chiavi di accesso ai vari database del sito.

Uno dei “pericolosi” file che contengono le chiavi di accesso ai database. Naturalmente ho oscurato i dati sensibili

Io non ho provato a connettermi ai vari database del sito visto che il mio interesse era puramente “accademico” e visto che molto probabilmente sono protetti da ulteriori meccanismi di protezione. Tutto quello che ho fatto è stato segnalare la vulnerabilità al supporto tecnico del sito che si è rivelato svelto a rispondermi e a risolvere il problema.

Timeline

  • Lunedì 22/06/2020 navigando prima di attaccare al lavoro mi accorgo della vulnerabilità;
  • Lunedì 22/06/2020 11:24 contatto il supporto del sito per segnalare la vulnerabilità;
  • Lunedì 22/06/2020 13:05 mi risponde il responsabile tecnico del sito;
  • Lunedì 22/06/2020 13:17 segnalo il problema al responsabile;
  • Lunedì 22/06/2020 15:21 il supporto mi segnala che il problema è stato risolto.

Conclusioni

Alla fine tutto bene quel che finisce bene. Sfortunatamente il problema di lasciare cartelle .git esposte è più comune di quanto si pensi. Tanto è vero che anche OWASP (il progetto che ha come scopo la sicurezza delle applicazioni web) lo inserisce tra i requisiti da verificare per garantire la protezione da accessi indesiderati ai siti web.

In ogni caso l’assistenza si è dimostrata rapida ed efficace nel risolvere il problema e mi piace pensare che ora il web sia diventato un po’ più sicuro anche per merito mio.

Nonostante il problema sia stato gestito e risolto in maniera impeccabile l’azienda in questione mi ha chiesto di non divulgare il suo nome e di conseguenza non è riportato da nessuna parte nell’articolo.


Se questo post ti è stato utile puoi farmelo sapere lasciando un commento qui sotto oppure scrivendomi direttamente a t.me/lorenzomillucci.
Inoltre ti invito ad iscriverti al mio canale Telegram e a seguirmi su Twitter per non perderti nemmeno un post del mio blog. A presto!

Cos’è il debito tecnico?

Debito tecnico

Fin da quando ho iniziato a lavorare ho sentito parlare di “debito tecnico”. Al lavoro recentemente abbiamo anche creato una board dedicata esclusivamente al tracciamento del debito tecnico.

Ma che cos’è il debito tecnico? Pur non avendo mai approfondito il concetto è facile capire a grandi linee di cosa si tratta: sono tutte quelle cose che uno lascia indietro oggi per poter rilasciare prima il software sapendo che prima o poi sarà necessario ritornarci sopra.

In realtà la metafora del debito tecnico è un po’ più articolata di così e oggi ho approfittato di un giorno di ferie per studiare meglio la questione analizzando le parole del leggendario Martin Fowler.

Prima di cominciare mi presento, sono Lorenzo Millucci e sono un ingegnere del software che ama lavorare con Symfony e a cui piace condividere in questo blog le cose che impara. Iscriviti al mio canale Telegram per non perderti nessuna notizia!

Definizione

Il debito tecnico è una metafora concepita da Ward Cunningham che assimila la complessità di un software ad un debito finanziario e lo sforzo necessario ad aggiungere una nuova funzionalità all’interesse pagato sul debito.

Ogni riga di codice scritta, ogni libreria installata nel progetto incrementa il livello di complessità generale al progetto andando ad incrementare il debito tecnico.

Esattamente come accade per i debiti finanziari, la scelta migliore è pagare gradualmente in “comode” rate mensili.

La forza di questa metafora consiste nel rendere evidente anche a chi non è un ingegnere del software come anche le attività di refactoring del codice, pur non portando nuove funzionalità al progetto, sono necessarie a “ripagare” la quota del debito.

Ogni volta che è necessario aggiungere una nuova funzionalità al progetto sarebbe buona norma investire del tempo per ristrutturare il codice esistente. Chiaramente in questo modo si otterrebbero dei cicli di sviluppo più lunghi. Tuttavia, qualora dovesse capitare di lavorare nuovamente sulla stessa porzione di codice il lavoro potrebbe procedere in modo molto più spedito avendo già pagato la quota di debito.

Se invece si decidesse di non pagare periodicamente le quote di debito tecnico si finirebbe per avere cicli di sviluppo molto rapidi all’inizio ma, mano a mano che il debito si accumula, i tempi di sviluppo si estenderebbero sempre di più fino ad arrivare al fatidico momento in cui la complessità del software è così alta che non è più possibile sviluppare nuove funzioni in tempi ragionevoli. Quando si arriva in questa situazione, quello che accade solitamente è che si getta la spugna ed è necessario riscrivere da capo il software.

Posso pagare il debito tecnico in stelline?

Una delle principali differenze con i debiti finanziari invece è che, contrariamente ai debiti finanziari in cui l’interesse da pagare è sul totale, sui debiti tecnici il costo da pagare è dipendente dalla porzione di codice. In un software possono esistere parti di codice da incubo con un debito tecnico altissimo ma che non tocca nessuno e quindi un interesse bassissimo e parti di codice che invece sono modificate frequentemente e che quindi pur avendo dei piccoli debiti hanno degli interessi stellari.

TIPOLOGIE DI DEBITO

A seconda di come si affronta il debito tecnico è possibile individuare due classificazioni del debito. Una basata sul rischio (prudente/imprudente) e una basata sulla coscienziosità con cui si protrae il debito (volontario/involontario). Vediamo di seguito come si combinano le due classi:

  • DEBITO VOLONTARIO E PRUDENTE: nello sviluppo di un progetto è ammissibile accettare di fare del debito per concentrarsi sulle cose urgenti. L’importante è sapere che il debito fatto oggi tornerà a chiederci gli interessi domani.
  • DEBITO VOLONTARIO E IMPRUDENTE: questo forse è il caso peggiore. So di indebitarmi pur di consegnare il software ma faccio finta che stia andando tutto bene trascurando completamente le conseguenze di tale indebitamento.
  • DEBITO INVOLONTARIO E IMPRUDENTE: questo in genere accade agli sviluppatori alle prime armi che non conoscono il concetto di debito tecnico e non si rendono conto che cattive scelte fatte in fase di progetto li perseguiteranno in futuro.
  • DEBITO INVOLONTARIO E PRUDENTE: Molto spesso accade che nonostante si abbiano seguito perfettamente le migliori best-practices ci si rende conto che se si fosse utilizzato quel design pattern o quell’altra architettura il codice sarebbe stato sicuramente migliore (in termini di complessità).

Queste combinazioni possono essere riportate in un grafico fatto nel seguente modo:

Il quadrante del debito tecnico

Il fatto che ogni progetto finisca per avere del debito tecnico però non deve essere preso come scusa per trascurare la qualità del codice. Aggiungere codice di scarsa qualità ad un progetto già indebitato fino al collo o scordarsi di pagare le rate degli interessi non può che peggiorare la situazione arrivando a rendere impossibile lo sviluppo di nuove funzionalità.

D’altro canto, un debito ben ragionato con piccole quote di interesse pagate regolarmente può permettere di accelerare il rilascio di nuove funzionalità.

Conclusioni

Ogni volta che adottiamo una soluzione “quick and dirty” per risolvere un problema stiamo facendo debito. Ogni volta che trascuriamo di aggiornare le libreria del progetto stiamo facendo debito. Ogni volta che ci rendiamo conto che avremmo potuto semplificare il codice e non lo facciamo stiamo facendo debito.

Il debito tecnico quindi è un’ombra che che incombe su ogni sviluppatore. Può sembrare minacciosa ma il solo sapere che esiste può essere sufficiente per tenerla a bada. 

Il debito tecnico di per sé non è malvagio. Avere un debito è normale per qualunque azienda si occupi di software. La cosa fondamentale da fare però è fare in modo che non raggiunga mai soglie troppo elevate e che le quote di interesse non schizzino alle stelle paralizzando completamente il progetto. 

Come per i debiti finanziari la bravura sta nel ripagare il debito in piccole rate includendo sempre nella roadmap dei progetti del tempo da dedicare al refactoring del codice.


Se questo post ti è stato utile puoi farmelo sapere lasciando un commento qui sotto oppure scrivendomi direttamente a t.me/lorenzomillucci.
Inoltre ti invito ad iscriverti al mio canale Telegram e a seguirmi su Twitter per non perderti nemmeno un post del mio blog. A presto!

Fonte
Fonte

Firefox disattivare la comparsa della barra dei menù quando si preme alt

Io sono un’amante delle scorciatoie da tastiera, quando posso cerco sempre di utilizzarle al posto del mouse. Utilizzando Firefox su Ubuntu però mi sono accorto di un fastidioso effetto collaterale quando premo il tasto alt (ad esempio quando premo alt + tab per cambiare applicazione aperta).

In pratica quello che succede è che nel momento in cui si preme il tasto alt della tastiera Firefox mostra la barra dei menù (che di solito è nascosta) facendo scorrere di qualche pixel la pagina. Questo, oltre ad essere fastidioso e brutto a vedersi, a volte cattura combinazioni di tasti non desiderate abilitando comportamenti “strani” del browser.

Il fastidioso “balletto” della pagina quando si preme il tasto alt

Intanto mi presento, io sono Lorenzo Millucci e sono un software engineer che ama lavorare con Symfony e a cui piace condividere in questo blog le cose che impara. Iscriviti al mio canale Telegram per non perderti nessuna notizia!

Ma ora torniamo sul pezzo e vediamo subito come risolvere il problema utilizzando due differenti modi.

Modifica della configurazione di Firefox (migliore)

Questo, secondo me, è il metodo migliore da seguire per risolvere il problema alla radice andando a modificare la configurazione interna di Firefox.

La prima cosa da fare è digitare about:config nella barra degli indirizzi di Firefox. Si aprirà una pagina in cui Firefox ti avverte dei rischi collegati alle modifiche che è possibile fare dal pannello delle impostazioni avanzate. Per proseguire bisogna premere il pulsante Accetta il rischio e continua.

A questo punto nella barra in alto bisogna inserire la chiave di ricerca ui.key.menuAccessKeyFocuses e cambiare l’impostazione da true a false.

E il gioco è fatto, d’ora in poi non sarà più visualizzata la barra dei menù quando viene premuto il tasto alt.

Modifica al registro di Firefox per modificare il comportamento del tasto alt
Modifica alla configurazione di Firefox

Rendere sempre visibile la barra dei menù

Questo metodo non richiede di entrare nel pannello delle configurazioni avanzate del browser ma si basa sul rendere sempre visibile la barra dei menù grazie alle infinite possibilità di personalizzazione di Firefox. Tuttavia a parer mio, mostrare sempre una barra che occupa spazio verticale su un monitor 16:9 è proprio uno spreco di spazio per cui preferisco il metodo descritto prima.

Per rendere sempre visibile la barra dei menù devi:

  • premere il bottone con l’icona a forma di hamburger (sarebbe quello con le tre linee orizzontali in alto a destra),
  • clickare sulla voce personalizza
  • selezionare barre degli strumenti e mettere la spunta a barre dei menù
Visualizzare sempre la barra dei menù

Se questo post ti è stato utile puoi farmelo sapere lasciando un commento qui sotto oppure scrivendomi direttamente a t.me/lorenzomillucci.
Inoltre ti invito ad iscriverti al mio canale Telegram e a seguirmi su Twitter per non perderti nemmeno un post del mio blog. A presto!

FONTE

Aggiungere un podcast a Google Podcast Manager

Google podcast in esecuzione

Informazioni strategiche per far crescere il tuo podcast

Google Podcast Manager

Qualche tempo fa avevo parlato di come fare per indicizzare un podcast su Google, oggi invece ti voglio spiegare come visualizzare ed analizzare le statistiche degli ascoltatori del podcast provenienti da Google.

I principali dati che Google Podcast Manager raccoglie sono:

  • il numero di ascolti per programma e puntata,
  • il numero di ascolti per segmento di puntata,
  • la percentuale di ascolto per ogni puntata.

Per iniziare a raccogliere questi dati la prima cosa da fare è collegarsi al sito https://podcastsmanager.google.com e rivendicare il possesso del nostro podcast attraverso i 4 passaggi che Google mette a disposizione.

Passaggio 1 – inserire il feed RSS

Come primo passaggio ci viene chiesto l’indirizzo del feed RSS del podcast che vogliamo monitorare.

Ad esempio, se utilizzi Spreaker, per trovare l’indirizzo del feed RSS ti basta aprire la pagina del podcast e copiare l’indirizzo indicato tramite l’icona arancione vicino a quella dei social.

Esempio: ottenere l’indirizzo del feed RSS di un podcast su Spreaker trmite l’icona arancione

Una volta copiato l’indirizzo puoi tornare su Podcast Manager ed inserirlo.

Inserimento del feed RSS su Google Podcast Manager

NOTA: se nel momento in cui invii il feed ricevi il messaggio d’errore Questo programma non è al momento disponibile su Google significa che il tuo podcast non è stato ancora aggiunto a Google Podcast, per farlo ti rimando a questa guida.

Passaggio 2 – Verifica dei dati

Anteprima del feed appena inserito

Passaggio 3 – Verifica della proprietà

Per verificare la proprietà del podcast Google invierà una mail con un codice

Passaggio 4 – Proprietà verificata

Proprietà verificata con successo

Perché questi dati sono importanti?

Il mondo del podcasting sta esplodendo è sempre più content-creator annunciano la pubblicazione di un podcast. In un contesto del genere è fondamentale catturare e mantenere l’attenzione del pubblico e per farlo è necessario capire esattamente chi ti ascolta, quando ti ascolta e con quale dispositivo.

Proprio per questo Google ha lanciato Podcast Manager che permette di raccogliere in un unico punto le statistiche sulla fidelizzazione del pubblico tramite il numero di puntate riprodotte, il tempo cumulativo di riproduzione e la percentuale di completamento di ogni singolo episodio. Con questi dati capire in quali punti gli ascoltatori interrompono l’ascolto o quali sono le parti maggiormente apprezzate non sarà un problema.

Inoltre grazie al grafico con il numero di ascolti per giorno ti sarà facile capire qual è il momento migliore per pubblicare l’ultimo episodio del podcast.

Infine, grazie al report che mostra su quale dispositivo il tuo podcast viene riprodotto, potrai individuare subito se ti stai rivolgendo ad un pubblico che ascolta le tue puntate in mobilità utilizzando uno smartphone o se invece i tuoi ascoltatori preferiscono la comodità della casa ascoltandoti da uno smart-speaker.


Se questo post ti è stato utile puoi farmelo sapere lasciando un commento qui sotto oppure scrivendomi direttamente a t.me/lorenzomillucci.
Inoltre ti invito ad iscriverti al mio canale Telegram e a seguirmi su Twitter per non perderti nemmeno un post del mio blog. A presto!

Analisi delle performance di Webpack

Tempo di bundling di webpack

Non c’è niente di più noioso che dover aspettare che il compilatore termini il proprio lavoro.

Chiunque programmi per applicazioni per il web con buona probabilità avrà avuto il piacere di imbattersi in Webpack. Webpack, grazie alla sua flessibilità e all’enorme quantità di loader e plugin disponibili, è diventato lo standard per la creazione di bundle di asset JS e CSS.

La creazione dei bundle tipicamente non richiede più di qualche secondo per essere completata ma al crescere del numero di asset il tempo necessario a terminare il processo può crescere notevolmente. Ad esempio, nel caso del backoffice di Slope, la creazione dei bundle era arrivata a superare il minuto. Decisamente troppo.

In questo articolo voglio raccontarti come ho migliorato le performance di Webpack utilizzando vari accorgimenti.

Source: https://xkcd.com/303

Ottimizzazione

Per ottimizzare i tempi di build, la documentazione di Webpack, riporta:

Use the latest webpack version. We are always making performance improvements.  […] Staying up-to-date with Node.js can also help with performance. On top of this, keeping your package manager (e.g. npm or yarn) up-to-date can also help. Newer versions create more efficient module trees and increase resolving speed.

documentazione di Webpack

Sulla base di quanto suggerito dalla documentazione ho deciso di provare, utilizzando il backoffice di Slope come benchmark, quale fosse l’impatto dovuto a:

  • Aggiornamento di Webpack dalla versione 3 alla versione 4
  • Avanzamento di Yarn dalla versione 1.19.0 alla versione 1.22.0
  • Avanzamento della versione di Node dalla 8.16.0 alla 12.11.1

Metodo di prova

La prova è stata eseguita su di un PC con le seguenti caratteristiche tecniche:

ProcessoreIntel(R) Core(TM) i5-7600 CPU @ 3.50GHz × 4
Memoria16384 MB (DDR4)
DiscoSamsung SSD 850 (250GB)
Scheda graficaRadeon RX 580 Series (POLARIS10, DRM 3.33.0, 5.3.0-40-generic, LLVM 9.0.0)
OSUbuntu 18.04.4
Kernel5.3.0-40-generic (x86_64)

Le performance sono state misurate utilizzando il BackOffice di Slope. Il progetto è basato su Symfony 4.2.8 e contiene al suo interno circa 190 file Javascript/TypeScript e circa 60 file CSS/SCSS.

Per verificare le performance è stato misurato il tempo necessario alla creazione dei bundle nelle seguenti condizioni:

  • configurazione con Webpack 3, Yarn 1.19.0, Node 8.16.0
  • configurazione con Webpack 4 , Yarn 1.19.0, Node 8.16.0
  • configurazione con Webpack 4 , Yarn 1.22.0, Node 8.16.0
  • configurazione con Webpack 4 , Yarn 1.19.0, Node 12.11.1
  • configurazione con Webpack 4 , Yarn 1.22.0, Node 12.11.1

Per ogni configurazione è stata eseguita una prima prova per fare il warm-up della cache (prova 0) e una serie di 10 build consecutive.

Build di development

Come prima prova ho analizzato il tempo necessario ad eseguire la build di development. Nella configurazione di Webpack di sviluppo è abilitata la creazione delle sourcemaps e il linting del codice JS/TS mentre è disattivata la minificazione del codice.

Webpack 3Webpack 4Yarn 1.22.0Node 12.11.1Node 12.11.1 + Yarn 1.22.0
Prova 050,1421,7221,8219,5119,35
Prova 150,4418,4618,8015,9715,82
Prova 250,7018,3915,5615,7615,78
Prova 350,1718,9718,7515,8515,68
Prova 449,1218,6817,7815,9515,63
Prova 550,2818,5718,7815,8915,81
Prova 650,5618,4118,4915,7815,70
Prova 749,3719,0619,9515,9515,86
Prova 849,4219,9518,8815,9415,76
Prova 950,3516,6218,8816,0315,95
Prova 1050,5018,6718,8015,8715,68
Esecuzione delle prove di compilazione nelle varie configurazioni. Tempi in secondi.
Tempo di build nelle varie configurazioni (minore è meglio)
Webpack 3Webpack 4Yarn 1.22.0Node 12.11.1Node 12.11.1 + Yarn 1.22.0
Media50,0618,7819,0716,2316,09
Media (esclusa prova 0)50,0918,4818,7715,9015,77
*Tempi in secondi

Dall’analisi dei risultati si nota chiaramente come il solo passaggio da Webpack 3 a Webpack 4 riduca notevolmente il tempo di creazione della build (circa il 60% in meno!).
Analizzando le performance con Webpack 4 invece è possibile notare come l’effetto del singolo avanzamento di versione di Yarn introduca un trascurabile peggioramento delle performance mentre l’effetto dell’aggiornamento di Node da solo introduca una riduzione dei tempi di build di circa il 10%.

Trovo molto interessante notare anche il fatto che, mentre il singolo aggiornamento di Yarn sembri peggiorare le performance, l’utilizzo congiunto delle ultime versioni di Node e Yarn faccia perdere alla build qualche frazione di secondo sul tempo di esecuzione.

Build di produzione

Nella seconda configurazione di prova ho utilizzato la build di produzione di Webpack. In questa configurazione sono disattivati i processi di linting del codice JS/TS e la creazione delle sourcemaps mentre invece risulta attiva la fase di minificazione del codice.

Webpack 3Webpack 4Yarn 1.22.0Node 12.11.1Node 12.11.1 + Yarn 1.22.0
Prova 076,3537,5336,5632,5632,73
Prova 174,6920,8220,7718,3618,21
Prova 275,7820,7820,8618,3618,12
Prova 373,5320,7720,7918,2818,15
Prova 473,6320,6320,5618,1918,08
Prova 572,0020,8420,9118,3018,13
Prova 672,3721,0720,8318,5118,17
Prova 773,4020,9720,8018,2518,15
Prova 874,2321,0220,9618,6918,16
Prova 973,9520,8720,8218,8018,12
Prova 1073,0821,0921,0018,3718,14
Esecuzione delle prove di compilazione nelle varie configurazioni. Tempi in secondi.
Tempo di build nelle varie configurazioni (minore è meglio)
Webpack 3Webpack 4Yarn 1.22.0Node 12.11.1Node 12.11.1 + Yarn 1.22.0
Media73,9922,5322,3919,7119,47
Media (esclusa prova 0)73,6720,8920,8318,4118,14
*Tempi in secondi

Anche in questo caso il passaggio da Webpack 3 a Webpack 4 si conferma come il miglior investimento per abbattere i tempi di esecuzione della build (circa il 70% in meno).
Contrariamente alla build di development l’accoppiata Webpack 4 + Yarn 1.22.0 non peggiora le performance ma il guadagno di tempo risulta essere praticamente trascurabile (-0,27% escludendo la prova 0). Anche in questo caso l’avanzamento di versione di Node invece permette di migliorare le performance di un ulteriore 10% rispetto ai tempi di Webpack 4.

Anche in questo caso l’aggiornamento combinato di Webpack 4, Node 12.11.1 e Yarn 1.22.0 permette di guadagnare una manciata di secondi sul tempo di build.

Conclusioni

Le prove eseguite sembrano confermare esattamente quanto riportato dalla guida di Webpack. Il miglior investimento possibile per migliorare le performance della build di Webpack è quello di utilizzare sempre la versione più recente del tool.

Una volta aggiornato Webpack all’ultima versione, dovendo scegliere se aggiornare Node o Yarn non c’è dubbio che la scelta migliore sia quella di investire tempo nell’aggiornamento di Node (guadagnando circa un 10% di tempo in meno).

Solo in ultima istanza conviene aggiornare Yarn il cui effetto sui tempi di build risulta essere praticamente trascurabile.

Come ultima nota c’è da considerare che lo sforzo necessario ad ogni aggiornamento è direttamente proporzionale al guadagno ottenuto. Mentre aggiornare Yarn non richiede più di qualche minuto, aggiornare Node e soprattutto Webpack può richiedere più di qualche ora.


Se questo post ti è stato utile puoi farmelo sapere lasciando un commento qui sotto oppure scrivendomi direttamente a t.me/lorenzomillucci.
Inoltre ti invito ad iscriverti al mio canale Telegram e a seguirmi su Twitter per non perderti nemmeno un post del mio blog. A presto!