Webpack — Cheat Sheet

Tag: webpack, bundler, javascript, build-tools, frontend, performance

Livello: intermedio

TL;DR: Modulo bundler per generare dependency graph ed emettere asset statici ottimizzati. Gestisce trasformazione, code splitting e caching tramite loader e plugin.

Concetti chiave

Webpack crea a partire da entry point un dependency graph completo dell'applicazione.

L'entry definisce i moduli iniziali da cui tracciare le dipendenze dirette e indirette.

L'output stabilisce percorso e schema di naming dei bundle finali generati.

I loader trasformano i file non-JavaScript prima dell'inclusione nel dependency graph.

I plugin intercettano l'intero ciclo di vita della compilazione tramite hook dedicati.

Il mode attiva ottimizzazioni predefinite per production o development.

Il code splitting suddivide il codice in chunk caricabili on-demand o in parallelo.

Tree shaking rimuove l'export inutilizzato sfruttando la sintassi statica ES modules.

Content hashing genera hash basati sul contenuto dei file per ottimizzare il caching.

Domande tipiche e risposte pronte

Q: Qual e' la differenza tra un loader e un plugin in Webpack?R: Un loader trasforma singoli file all'importazione agendo a livello di modulo. Un plugin interviene sull'intero ciclo di vita della build modificando o ottimizzando i bundle.

Q: Come si implementa il code splitting in Webpack?R: Uso import dinamici per il lazy loading dei moduli e configuro optimization.splitChunks per estrarre le librerie vendor condivise.

Q: In cosa differiscono hash, chunkhash e contenthash?R: hash cambia ad ogni build dell'intero progetto, chunkhash dipende dall'intero chunk, mentre contenthash cambia solo quando il contenuto effettivo del file subisce modifiche.

Q: Perche' il Tree Shaking potrebbe non eliminare tutto il codice morto?R: Richiede ES modules statici e package.json configurato con sideEffects: false. Codice CommonJS o espressioni con effetti collaterali a livello root impediscono l'eliminazione.

Insidie e errori comuni

Ordine errato dei loader in use: vengono eseguiti da destra a sinistra (dal basso verso l'alto).

Mancanza dell'esclusione di node_modules nei loader con conseguente rallentamento critico della build.

Utilizzo di eval-cheap-source-map in ambiente di produzione anziche' source-map.

Import con CommonJS (require) che disabilita il tree shaking del modulo importato.

Moduli con side effects non dichiarati che causano bug a runtime se eliminati dal bundler.

Snippet e comandiJavaScript

// webpack.config.js
const path = require('path');
const MiniCssExtractPlugin = require('mini-css-extract-plugin');

module.exports = {
  mode: 'production',
  entry: './src/index.js',
  output: {
    path: path.resolve(__dirname, 'dist'),
    filename: '[name].[contenthash].js',
    clean: true,
  },
  module: {
    rules: [
      {
        test: /\.js$/,
        exclude: /node_modules/,
        use: { loader: 'babel-loader' },
      },
      {
        test: /\.css$/,
        use: [MiniCssExtractPlugin.loader, 'css-loader'],
      },
    ],
  },
  plugins: [
    new MiniCssExtractPlugin({ filename: '[name].[contenthash].css' }),
  ],
  optimization: {
    splitChunks: {
      chunks: 'all',
    },
  },
};

Bash

# Esecuzione build produzione
npx webpack --mode=production

# Avvio dev server con hot module replacement
npx webpack serve --mode=development

Da ripassare

[ ] Regola di precedenza ed esecuzione inversa della lista loader in rules.

[ ] Configurazione di optimization.splitChunks con cache groups dedicati.

[ ] Flag sideEffects in package.json per massimizzare il tree shaking.

[ ] Differenze di comportamento tra HMR (Hot Module Replacement) e Live Reloading.