Ce que fait ng build

Objectifs

À la fin de cette leçon, vous saurez :

• décrire la chaîne de build d'une application Angular ;
• définir bundling, minification et tree shaking ;
• servir le dossier dist à la main.

🔗 Pour vous rafraîchir la mémoire : modules : import/export

De TypeScript aux fichiers statiques

Le navigateur ne sait exécuter ni TypeScript ni templates Angular. Le build traduit tout :

Code source (.ts, .html, .css)
        ↓ ng build
compilation TS → bundling → minification → tree shaking
        ↓
dist/
├── index.html
├── main-HASH.js        ← tout le JS applicatif
├── styles-HASH.css
└── assets/

Les quatre transformations

Étape	Rôle
Compilation TS	types vérifiés puis effacés (chapitre 32)
Bundling	des centaines de modules → quelques fichiers
Minification	noms raccourcis, espaces supprimés
Tree shaking	code non importé éliminé

Tree shaking : ne payer que l'importé

// utils.js exporte 20 fonctions ; vous n'importez qu'une :
import { formaterDate } from './utils.js';

Les imports statiques permettent au bundler d'exclure les 19 autres du bundle final. Conditions : importer par noms précis (pas de import *), éviter les effets de bord au chargement des modules.

Les hashes : cache maîtrisé

main-3f9a2c.js : le hash change dès que le contenu change. Le serveur peut donc déclarer :

Cache-Control: max-age=31536000, immutable

Cache d'un an sans risque : un déploiement produit un nouveau nom de fichier, donc un nouveau téléchargement. C'est l'optimisation de cache la plus rentable du web — vos reverse proxy et CDN en dépendront directement.

Servir dist à la main

Déployer = mettre ces fichiers statiques derrière un serveur web. Pour le comprendre, faites-le vous-même :

ng build
cd dist/mon-app/browser
python3 -m http.server 8080     # ou npx serve .

Ouvrez http://localhost:8080 : votre application tourne sans Angular CLI, sans Node applicatif — juste des fichiers servis. Le schéma essentiel du chapitre :

Code Angular → build → HTML + CSS + JS → serveur web → navigateur

Deux détails du build : résolution des imports et assets

La résolution des imports. Pour bundler, l'outillage part du point d'entrée et suit chaque import. Chemin relatif (./tache.service) → fichier du projet ; nom nu (@angular/core) → recherché dans node_modules, exactement comme la résolution de Node vue au chapitre 26. Chaque module trouvé rejoint le graphe, qui devient l'ordre et le contenu des bundles. Comprendre cela explique les erreurs de build les plus courantes : un chemin mal orthographié, un package absent, un import mort que le tree shaking élimine.

Les assets. Images, favicon, polices et autres fichiers statiques ne passent pas par le compilateur : ils sont copiés tels quels depuis public/ (ou src/assets) vers dist/. Aucune transformation, aucune minification — juste un déplacement, avec parfois un renommage par hash comme le JS/CSS. D'où la règle : ce que le navigateur doit lire brut (image, PDF) va dans assets ; ce qui doit être transformé (TypeScript, SCSS) passe par le pipeline.

Exercice

1. Buildez, comparez la taille de src/ vs dist/.
2. Servez dist manuellement ; testez une navigation complète.
3. Modifiez un composant, rebuildez : le hash a-t-il changé ? Seulement lui ?
4. Que perdrait-on sans minification ?

Résumé

• Build = traduction vers ce que le navigateur sait exécuter.
• Bundle/minify/tree-shake : moins de requêtes, moins d'octets, que l'utilisé.
• Hashes + immutable = cache long et sûr.