Minificazione e offuscamento: due operazioni con obiettivi opposti

1// Che cosa fa un minificatore, concretamente.2// Prima:3function calcolaTotaleCarrello(righeCarrello, aliquotaIva) {4  // Somma i prezzi tenendo conto della quantità5  let totaleImponibile = 0;6  for (const riga of righeCarrello) {7    totaleImponibile += riga.prezzoUnitario * riga.quantita;8  }9  return totaleImponibile * (1 + aliquotaIva);10}11​12// Dopo:13function calcolaTotaleCarrello(t,a){let e=0;for(const l of t)e+=l.prezzoUnitario*l.quantita;return e*(1+a)}14​15// Da notare: i nomi LOCALI sono accorciati, quelli esportati e le16// proprietà degli oggetti NO — rinominarli cambierebbe il comportamento17// osservabile (una proprietà si può leggere con obj['prezzoUnitario']).18// È il motivo per cui la minificazione è sicura per definizione: non19// applica nessuna trasformazione che possa cambiare il risultato.

1// Il guadagno che spesso supera quello della minificazione: rimuovere2// il codice che non viene mai raggiunto. Funziona SOLO con i moduli ES,3// perché la loro struttura è analizzabile staticamente.4​5// ✓ Analizzabile: il bundler sa esattamente cosa serve6import { formatta } from './utils.js';        // porta dentro solo formatta7​8// ✗ Non analizzabile: require è una chiamata di funzione, il cui9//   argomento potrebbe essere calcolato a runtime10const utils = require('./utils.js');          // porta dentro tutto11​12// ✗ Non analizzabile: l'import dinamico con percorso variabile13const m = await import('./' + nome + '.js');  // il bundler include TUTTO14                                              // ciò che potrebbe servire15​16// E l'effetto collaterale dichiarato: se un modulo fa qualcosa al solo17// essere importato (registra un polyfill, modifica un prototipo), il18// bundler non può rimuoverlo anche se non se ne usa nessun export.19// In package.json: "sideEffects": false  dice "non ne ho, rimuovi pure".

1// L'offuscamento va nella direzione opposta: aggiunge codice per2// rendere quello vero difficile da seguire.3{4  // Le stringhe non stanno più nel codice: vivono in un array5  // cifrato, e ogni uso passa da una funzione di lookup.6  stringArray: true,7  stringArrayEncoding: ['base64'],8  stringArrayThreshold: 0.75,9​10  // Il flusso lineare diventa una macchina a stati con un dispatcher.11  // È la trasformazione più efficace e la più costosa in esecuzione.12  controlFlowFlattening: true,13  controlFlowFlatteningThreshold: 0.5,14​15  // Blocchi di codice mai eseguiti, indistinguibili da quelli veri16  // senza analisi dinamica.17  deadCodeInjection: true,18  deadCodeInjectionThreshold: 0.3,19​20  // Il codice verifica di non essere stato riformattato: passarlo per21  // un abbellitore lo rompe.22  selfDefending: true23}

1// La domanda da porsi prima di attivarlo, in tre punti:2//3// 1. Che cosa sto proteggendo?4//    Se la risposta è "la logica di business" → quella non dovrebbe5//    stare nel browser. Va spostata sul server, e il problema sparisce.6//    Se è "l'implementazione di un'interfaccia curata" → l'offuscamento7//    ha senso come deterrente contro la copia opportunistica.8//9// 2. Da chi?10//    Da un curioso che apre DevTools → sì, funziona benissimo.11//    Da un concorrente determinato → alza il costo di qualche giorno.12//    Non lo impedisce, e va detto onestamente.13//14// 3. A che prezzo?15//    Byte, tempo di esecuzione, e stack trace di produzione illeggibili16//    — cioè la capacità di capire perché qualcosa si rompe sui browser17//    degli utenti. Quest'ultima è la voce che si sottovaluta di più.