Expliquez-moi votre configuration de build. Pourquoi bundler tout court alors que les navigateurs supportent nativement les modules ?

Les modules natifs fonctionnent, mais livrer des centaines de fichiers non bundlés veut dire des centaines de requêtes et une cascade de dépendances profonde, ce qui est lent même en HTTP/2. Le bundling vous donne le tree shaking, la minification, le découpage de code par route, des noms de fichiers hachés par contenu pour de longues durées de cache et un endroit où transformer TypeScript et JSX. Les serveurs de dev servent maintenant des modules natifs pour un démarrage instantané, puis bundlent pour la production, ce qui donne le meilleur des deux.

Les modules natifs sont vraiment utilisables aujourd'hui, mais dès que j'ai un vrai arbre de dépendances je demande au navigateur de découvrir et de récupérer des centaines de petits fichiers en cascade, et chaque niveau du graphe coûte un aller-retour de plus. Le bundling écrase ça. Ça me donne aussi le tree shaking, donc les exports inutilisés ne sont jamais livrés, la minification, des noms de fichiers hachés par contenu pour mettre les assets en cache un an, et un seul endroit où compiler TypeScript. En développement j'utilise un serveur qui sert des modules ES natifs et transforme à la demande, donc le démarrage est instantané quelle que soit la taille du projet, puis je produis un build assemblé pour la production. Pour le découpage, je découpe par route par défaut, plus des frontières lazy autour de tout ce qui est lourd et non nécessaire au premier rendu, comme un éditeur de texte riche ou une bibliothèque de graphiques. Et je garde un budget de taille dans la CI qui fait échouer le build au-delà d'un seuil, parce que la taille d'un bundle ne régresse jamais autrement qu'une petite dépendance à la fois, et quand ça devient évident c'est un projet et non plus un correctif.