Webpack est un bundler de modules. Le but principal de Webpack est de regrouper les fichiers JavaScript à utiliser dans un navigateur, mais il est aussi capable de convertir, regrouper ou empaqueter à peu près n'importe quelle ressource ou asset. Webpack 5 a été publié ce 10 octobre et constitue une nouvelle version majeure du bundler avec des changements de rupture. À partir de cette version, tous les objets dépréciés depuis Webpack 4 ont été supprimés, mais d’autres éléments qui n’étaient pas dépréciés ont aussi été supprimés. Voici ci-dessous un aperçu de ce dont il s’agit dans cette version.Le remplissage automatique des polyfills pour Node.js supprimé
Selon l'équipe de Webpack, au début, le but de Webpack était de permettre l'exécution de la majorité des modules Node.js dans un navigateur, mais le paysage des modules a changé et de nombreuses utilisations des modules sont maintenant écrites principalement à des fins frontales. Webpack <= 4 est livré avec des polyfills pour de nombreux modules de base de Node.js, qui sont automatiquement appliqués une fois qu'un module utilise l'un des modules de base. Bien que cela facilite l'utilisation des modules écrits pour Node.js, cela ajoute ces énormes polyfills au paquet.
En outre, dans de nombreux cas, ces polyfills sont inutiles. Ainsi, Webpack 5 ne remplit plus automatiquement ces modules de base et se concentre désormais sur les modules compatibles avec le frontend. « Notre objectif est d'améliorer la compatibilité avec la plateforme Web, où les modules de base de Node.js ne sont pas disponibles », a annoncé l’équipe. Voici ce qu’il est désormais possible de faire :
- essayez d'utiliser des modules compatibles avec le frontend chaque fois que cela est possible ;
- il est possible d'ajouter manuellement un polyfill pour un module de base de Node.js. Un message d'erreur vous donnera un indice sur la façon d'y parvenir ;
- si vous êtes auteur de paquets, utilisez le champ du navigateur dans package.json pour rendre un paquet compatible avec le frontend.
Changement majeur : Mise en cache à long terme
Dans Webpack 5, de nouveaux algorithmes ont été ajoutés pour la mise en cache à long terme. Ils sont activés par défaut en mode production. Selon l’équipe, les algorithmes attribuent des ID numériques courts (allant de 3 à 5 chiffres) aux modules et des noms courts (2 caractères) aux exportations de manière déterministe. Il s'agit d'un compromis entre la taille du paquet et la mise en cache à long terme.
Le vrai hachage de contenu
Selon l’équipe, Webpack 5 utilise désormais un vrai hachage du contenu du fichier lors de l'utilisation de "contenthash". Avant, il utilisait seulement un hachage de la structure interne. Cela peut avoir un impact positif sur la mise en cache à long terme lorsque seuls les commentaires sont modifiés ou que les variables sont renommées. Ces changements ne sont pas visibles après la minimisation.
Changement majeur : Assistance au développement
ID de modules nommés
L’équipe a annoncé qu’à partir de Webpack 5, un nouvel algorithme pour identifier les modules nommés a été ajouté. Il est activé par défaut en mode de développement et donne des modules (et des noms de fichiers) dont les noms sont lisibles par l'homme. L'ID d'un module est déterminé par son chemin, en fonction du contexte. L'ID d'un module est déterminé par le contenu du module. Vous n'avez désormais plus besoin d'utiliser import(/* webpackChunkName: "nom"*/"module"
pour le débogage. Mais cela reste logique si vous voulez contrôler les noms de fichiers pour les environnements de production.Il est possible d'utiliser chunkIds: "named" en production, mais vous devez faire attention à ne pas exposer accidentellement des informations sensibles sur les noms de modules. En outre, si vous n'aimez pas que les noms de fichiers soient modifiés en cours de développement, vous pouvez passer par chunkIds: "natural" pour utiliser l'ancien mode numérique.
Fédération des modules
Webpack 5 ajoute aussi une nouvelle fonctionnalité appelée “Fédération de modules”, qui permet à de nombreux modules Webpack de fonctionner ensemble. Du point de vue de l'exécution, les modules de plusieurs builds se comporteront comme un énorme graphe de modules connectés. Du point de vue du développeur, les modules peuvent être importés de versions distantes spécifiques et utilisés avec un minimum de restrictions.
Changements majeurs : nouvelles fonctionnalités de la plateforme Web
Modules JSON
Les modules JSON s'alignent désormais sur la proposition et émettent un avertissement lorsqu'une exportation qui n’est pas définie par défaut est utilisée. Les modules JSON n'ont plus d'exportations nommées lors de l'importation à partir d'un module ECMAScript strict.
Progress
Quelques améliorations ont été apportées à ProgressPlugin qui est utilisé pour --progress par le CLI, mais peut également être utilisé manuellement comme plugin. Avant, il ne comptait que les modules traités. Maintenant, il peut compter les dépendances et les modules d'entrée. Tous ces éléments sont maintenant affichés par défaut. De même, il n’affichait que le module en cours de traitement, ce qui causait beaucoup de sortie stderr et entraînait un problème de performance sur certaines consoles. Il est maintenant désactivé par défaut.
Cela permet aussi de réduire la quantité de spams sur la console. L'écriture sur stderr pendant la construction des modules est maintenant limitée à 500 ms.
D’autres changements majeurs dans Webpack 5
- support natif des workers ;
- nouvelles caractéristiques de l'écosystème Node.js ;
- Webpack 5 dispose désormais d'un support natif pour les modules représentant les assets. Ces modules vont soit émettre un fichier dans le dossier de sortie, soit injecter un DataURI dans le paquet JavaScript. Dans les deux cas, ils donnent une URL avec laquelle travailler ;
- chemin public automatique : Webpack 5 détermine output.publicPath automatiquement lorsque cela sera possible ;
- TypeScript : Webpack 5 génère des séquences TypeScript à partir du code source et les expose via le paquet npm ;
- etc.
Source : Note de version de Webpack 5
Et vous ?
Qu'en pensez-vous ?Voir aussi
JavaScript : Webpack en version 4 est maintenant disponible et focus est fait sur le zéro configuration Node.js : eslint-scope, un paquet npm, a été infecté par un hacker pour lui permettre de voler des identifiants npm Un projet Node.js sur deux audité par les outils de npm aurait au moins une vulnérabilité, une sur dix d'entre elles est critique