Prima di iniziare, ti ricordiamo che puoi trovare la repository di quanto sviluppato al seguente link. Inoltre, i branch saranno numerati in base alla lezione. Il branch relativo a quest’articolo è il seguente: webpack_course_005.
Nota importante: In questo branch abbimo aggiunto del codice e un file js chiamato logger.js, in cui andremo a definire una funzione per testare gli argomenti dell’articolo. Quindi, prima di partire, se vi trovate in un branch diverso per poter testare gli argomenti spiegati in quest’articolo, fai: git checkout webpack_course_005 e digita npm install, in modo da partire dal branch corrente con le dipendenze aggiornate e ritrovarvi tutti i file.
Cosa sono le build di Webpack
Le build di Webpack sono ottimizzate in quanto comprimono il codice, rendendolo, difatti, illeggibile; questo modus operandi può rendere difficile il processo di debugging. Infatti, a volte, individuare l’origine di un bug diventa molto più tortuoso del previsto.
Uno dei primi metodi out-of-the-box di Webpack per facilitare il Debug di un’applicazione, è utilizzare la modalità development settata nel webpack.config.
module.exports = {
mode: 'development',
Questa modalità ci consente di trovare il codice errato cliccando nello specifico log in console. Ad esempio, guardando l’immagine qui sotto:
export default function logger() {
consolessssss.log('Hello World from logger);
}
ovviamente deduciamo che il metodo consolessssss.log non esiste. Quindi, una volta andati nel browser, cliccando sul bottone che invoca quel metodo, avremo il seguente errore:
> Uncaught ReferenceError: consolessssss is not defined at HTMLButtonElement.logger (logger.js:6)
Cliccando sul link presente tra le parentesi, il browser ci porterà all’origine dell’errore. Come mostrato nell’immagine seguente:
Tuttavia, eliminando la modalità development dal webpack.config, i messaggi di errore cambiano decisamente. Innanzitutto, al click sul bottone l’errore indicato sarà il seguente:
> Uncaught ReferenceError: consolessssss is not defined at HTMLButtonElement.v (bundle.js:1)
Cliccando sul link tra le parentesi, il browser ci indirizzerà al bundle, ormai reso illeggibile e compresso.
Impostare la modalità "development"
Conoscere questa differenza tra impostare la mode 'development' nel webpack.config e non impostarla, ci servirà per creare più configurazioni del nostro progetto. Ad esempio, potremmo creare un webpack.config.prod per targettizzare una build esclusivamente ai fini di produzione e, quindi, di delivery finale (qui ovviamente non useremo la mode development). Infatti, se ben ricordi, con il comando webpack –config webpack.config.js è possibile puntare a differenti file di configurazione e quindi nel package.json si creano due o più comandi di build nella sezione scripts, ognuno dei quali punta a un file di configurazione diverso.
La modalità development è già ottima ai fini di debugging, tuttavia ci limita sotto altri punti di vista, come ad esempio l’utilizzo di breakpoints.
Per potenziare ulteriormente le modalità di debugging del codice, webpack offre out-of-the -box le source maps, le source maps o mappe del codice sorgente, che mettono, appunto, in relazione il codice compilato con quello sorgente, mostrando in maniera totalmente trasparente il punto esatto in cui si è generato l’errore.
Abilitarle è semplicissimo: basta inserire all’interno del webpack.config questa proprietà:
},
devtool: 'inline-source-map',
plugins: [
Puoi trovare la lista completa dei diversi tipi di mappe a questo link: DEVTOOL.
Una volta aggiunta, bisognerà generare una build per testare il risultato; generata una nuova build e cliccato nuovamente sul bottone, l’errore sarà mostrato in questo modo:
> Uncaught ReferenceError: consolessssss is not defined at HTMLButtonElement.logger (logger.js:2)
Cliccando nuovamente sul link tra parentesi verremo reindirizzati al file in chiaro:
Il giro completo è mostrato qui di seguito:
A differenza di quello che accade con la semplice modalità di development, questa volta riusciamo a visualizzare il codice così com’è senza utilizzare Webpack e, inoltre, vediamo la riga esatta che genera l’eccezione!
In ottica di sviluppo, sapere che esiste questa possibilità facilita tantissimo l’individuazione di errori e di imperfezioni nel codice.
Tecniche di debugging
Queste tecniche di debugging vanno bene durante lo sviluppo ma sono estremamente pericolose se lasciate attive in una build di produzione, in quanto il codice sorgente resterà totalmente in chiaro e potrebbe facilitare di tanto il lavoro di possibili malintenzionati.
Nel prossimo articolo vedremo come creare un watch e un web server locale reattivo che reagisce ad ogni modifica del file sorgente, in modo da non dover generare ogni volta una nuova build per poter testare gli aggiornamenti.
Stay Tuned e alla prossima lezione!
