juin 4, 2021

Premiers pas avec Webpack —

À propos de l'auteur

Nwani Victory travaille à distance en tant que développeur Fullstack de Lagos, au Nigeria. Après les heures de bureau, il sert également d'ingénieur Cloud à la recherche de moyens de rendre Cloud …
En savoir plus sur
Nwani
↬

Les navigateurs modernes fournissent un bon support pour les modules JavaScript, mais les bundlers de modules tels que webpack restent un élément essentiel de la chaîne d'outils JavaScript. Examinons en profondeur ce qu'est le webpack et comment l'utiliser dans votre flux de travail de développement.

Au début de l'introduction de la modularité dans JavaScript, il n'y avait pas de support natif pour l'exécution de modules dans le navigateur. . La prise en charge de la programmation modulaire était implémentée dans Node.js à l'aide du CommonJS blueprint et elle était adoptée par ceux qui utilisaient JavaScript pour créer des applications côté serveur.[19659006] Il avait également des perspectives pour de grandes applications Web car les développeurs pouvaient éviter les collisions d'espaces de noms et créer des bases de code plus maintenables en écrivant du code dans un modèle plus modulaire. Mais il restait un défi : les modules ne pouvaient pas être utilisés dans les navigateurs Web, où JavaScript était généralement exécuté.

Pour résoudre ce problème, les bundlers de modules tels que webpack Parcel Rollup ainsi que le compilateur de fermeture de Google ont été écrits pour créer des ensembles optimisés de votre code pour le téléchargement et l'exécution du navigateur de votre utilisateur final.

Que fait Cela signifie-t-il « regrouper » votre code ?

Le code de regroupement fait référence à la combinaison et à l'optimisation de plusieurs modules en un ou plusieurs ensembles prêts à la production. Le bundle mentionné ici peut être mieux compris comme le produit final de l'ensemble du processus de regroupement.

Dans cet article, nous nous concentrerons sur webpackun outil écrit par Tobias Koppers , qui au fil du temps est devenu un outil majeur au sein de la chaîne d'outils JavaScript, souvent utilisé dans les grands et les petits projets.

Remarque : Pour bénéficier de cet article, il est judicieux de se familiariser avec JavaScript. modules. Vous aurez également besoin de Node installé sur votre machine locale, afin que vous puissiez installer et utiliser webpack localement.

Qu'est-ce que webpack?

webpack est un hautement extensible et configurable bundle de modules statiques pour les applications JavaScript. Grâce à sa nature extensible, vous pouvez brancher des chargeurs et des plug-ins externes pour atteindre votre objectif final.

Comme le montre l'illustration ci-dessous, webpack parcourt votre application à partir d'un point d'entrée racineconstruit un graphe de dépendances comprenant des dépendances qui agissent directement ou indirectement sur le fichier racine et produisent des bundles optimisés des modules combinés. ( Grand aperçu)

Pour comprendre le fonctionnement de webpack, nous devons comprendre certaines terminologies qu'il utilise (consultez webpack Glossary. Cette terminologie est souvent utilisée dans cet article, et c'est également fréquemment référencé dans la documentation de webpack.

Chunk
Un chunk fait référence au code extrait des modules.Ce code sera stocké dans un chunk file.Les morceaux sont couramment utilisés lorsque vous effectuez une division de code avec webpack.
Modules
Modules sont des parties décomposées de votre application que vous importez pour effectuer une tâche ou une fonction spécifique. Webpack prend en charge les modules créés à l'aide de Syntaxe ES6 CommonJS et AMD.
Assets
Le terme assets est fréquemment utilisé dans webpack et d'autres bundlers en général. fait référence aux fichiers statiques regroupés lors de la construction traiter. Ces fichiers peuvent être n'importe quoi, des images aux polices ou même des fichiers vidéo. En poursuivant votre lecture de l'article, vous verrez comment nous utilisons les chargeurs pour travailler avec différents types d'actifs.

Lecture recommandée : Webpack – Une introduction détaillée

Une fois que nous 'ai compris ce qu'est le webpack et quelle terminologie il utilise, voyons comment ils s'appliquent à la création d'un fichier de configuration pour un projet de démonstration.

Remarque : Vous aurez également besoin de webpack -cli installé pour utiliser webpack sur votre machine. S'il n'est pas installé, vous serez invité à partir de votre terminal à l'installer.

fichiers de configuration webpack

Alternativement à l'utilisation de webpack-cli à partir d'un terminal, vous pouvez utiliser webpack dans votre projet via un fichier de configuration. Mais avec les versions récentes de webpack, nous pouvons utiliser webpack dans notre projet sans un fichier de configuration. Nous utilisons ensuite webpack comme valeur de l'une des commandes de notre fichier package.jsonsans aucun indicateur. De cette façon, webpack supposera que le fichier de point d'entrée de votre projet réside dans le répertoire src. Il regroupera le fichier d'entrée et le sortira dans le répertoire dist.

Un exemple est un exemple de fichier package.json ci-dessous. Nous utilisons webpack pour regrouper l'application sans fichier de configuration :

{
  "nom" : "Magazine Smashing",
  "main": "index.js",
  "scripts": {
      "construire" : "webpack"
  },
  "dépendances" : {
    "webpack": "^5.24.1"
  }
}

Lors de l'exécution de la commande build dans le fichier ci-dessus, webpack regroupera le fichier dans le répertoire src/index.js et le sortira dans un fichier main.js dans un répertoire dist. webpack est cependant beaucoup plus flexible que cela. Nous pouvons modifier le point d'entréeajuster le point de sortie et affiner de nombreux autres comportements par défaut en éditant un fichier de configuration avec le drapeau -- config.

Un exemple est la version modifiée. commande du fichier package.json ci-dessus :

"build" : "webpack --config webpack.config.js"

Ci-dessus, nous avons ajouté le --config flag et spécifié un webpack.config.js comme fichier ayant la nouvelle configuration webpack.

Le fichier webpack.config.js n'existe pas encore cependant. Nous devons donc le créer dans notre répertoire d'application et coller le code suivant ci-dessous dans le fichier.

# webpack.config.js

const chemin = require("chemin")

module.exports = {
  entrée : "./src/entrée",
  production : {
    chemin : chemin.resolve(__dirname, "dist"),
    nom de fichier : "output.js"
  }
}

Le fichier ci-dessus configure toujours webpack pour regrouper votre fichier JavaScript, mais nous pouvons maintenant définir une entrée personnalisée et des chemins de fichier de sortie plutôt que le chemin par défaut utilisé par webpack.

Quelques points à noter à propos d'un fichier de configuration webpack :

Un fichier de configuration webpack est un fichier JavaScript, écrit comme un module JavaScript CommonJS.
Un fichier de configuration webpack exporte un objet avec plusieurs propriétés . Chacune de ces propriétés est utilisée comme option pour configurer webpack lors du regroupement de votre code. Un exemple est l'option mode :
- mode
  En configuration, cette option est utilisée pour définir la valeur NODE_ENV lors du regroupement. Il peut avoir une valeur production ou développement. Lorsqu'il n'est pas spécifié, il sera par défaut à aucun. Il est également important de noter que webpack regroupe vos ressources différemment en fonction de la valeur mode. Par exemple, webpack met automatiquement en cache vos bundles en mode développement pour optimiser et réduire le temps de bundle. Reportez-vous à la section mode de la documentation webpack pour voir un journal des modifications des options appliquées automatiquement dans chaque mode.

CLI ou via un fichier de configuration, il existe quatre concepts principaux qui sont appliqués comme options. La section suivante de cet article se concentre sur ces concepts et les applique lors de la création de la configuration d'une application Web de démonstration.

Il convient de noter que les concepts expliqués ci-dessous partagent certaines similitudes avec d'autres bundlers de modules. Par exemple, lorsque vous utilisez Rollup avec un fichier de configurationvous pouvez définir un champ input pour spécifier le point d'entrée du graphe de dépendance, un output Objet configurant comment et où sont placés les morceaux produits, ainsi qu'un objet plugins pour ajouter des plugins externes.

Entry

Le champ entry dans votre fichier de configuration contient le chemin d'accès au fichier à partir duquel webpack commence à créer un graphe de dépendance. A partir de ce fichier d'entrée, webpack passera à d'autres modules qui dépendent directement ou indirectement du point d'entrée.

Le point d'entrée de votre configuration peut être de type Single Entry avec un single fichier value, similaire à l'exemple ci-dessous :

# webpack.configuration.js

module.exports = {
  mode : "développement",
  entrée : "./src/entrée"
}

Le point d'entrée peut également être un type d'entrée multi-main ayant un tableau contenant le chemin de plusieurs fichiers d'entrée, similaire à l'exemple ci-dessous :

# webpack.configuration.js

const webpack = require("webpack")

module.exports = {
  mode : "développement",
  entrée : [ './src/entry', './src/entry2' ],
}

Output

Comme son nom l'indique, le champ output d'une configuration est l'endroit où le bundle créé vivra. Ce champ est pratique lorsque vous avez plusieurs modules en place. Plutôt que d'utiliser le nom généré par webpack, vous pouvez spécifier votre propre nom de fichier.

# webpack.configuration.js

const webpack = require("webpack");
const chemin = require("chemin");

module.exports = {
  mode : "développement",
  entrée : './src/entry',
  production: {
    nom de fichier : "webpack-output.js",
    chemin : chemin.resolve(__dirname, "dist"),
  }
}

Loaders

Par défaut, webpack ne comprend que les fichiers JavaScript de votre application. Cependant, webpack traite chaque fichier importé en tant que module comme une dépendance et l'ajoute au graphe de dépendance. Pour traiter des ressources statiques telles que des images, des fichiers CSS, des fichiers JSON ou même vos données stockées au format CSV, webpack utilise des loaders pour « charger » ces fichiers dans le bundle.

Les chargeurs sont suffisamment flexibles pour être utilisés. pour beaucoup de choses, de la transpilation de votre code ES à la gestion des styles de votre application ou même au linting de votre code avec ESLint.

Il existe trois façons d'utiliser les chargeurs dans votre application. L'une d'entre elles passe par la méthode inline en l'important directement dans le fichier. Par exemple, pour minimiser la taille de l'image, nous pouvons utiliser le chargeur image-loader dans le fichier directement comme indiqué ci-dessous :

// main.js

importer ImageLoader depuis 'image-loader'

Une autre option préférée pour utiliser les chargeurs est via votre fichier de configuration webpack. De cette façon, vous pouvez faire plus avec les chargeurs, tels que spécifier les types de fichiers auxquels vous souhaitez appliquer les chargeurs. Pour ce faire, nous créons un tableau rules et spécifions les chargeurs dans un objet, chacun ayant un champ de test avec une expression regex correspondant aux actifs auxquels nous voulons appliquer les chargeurs.

Par exemple, avec image-loader importé directement dans l'exemple précédent, nous pouvons l'utiliser dans le fichier de configuration webpack avec les options les plus basiques de la documentation. Cela ressemblera à ceci :

# webpack.config.js

const webpack = require("webpack")
const chemin = require("chemin")
const merge = require("webpack-merge")

module.exports = {
  mode : "développement",
  entrée : './src/entry',
  production: {
    nom de fichier : "webpack-output.js",
    chemin : chemin.resolve(__dirname, "dist"),
  },
  module : {
    règles : [
    {
      test: /.(jpe?g|png|gif|svg)$/i,
      use: [
        'img-loader'
        ]
    }
   ]
  }
}

Regardez de plus près le champ test dans l'objet qui contient le image-loader ci-dessus. Nous pouvons repérer l'expression regex qui correspond à tous les fichiers image : soit au format jp(e)gpnggif et svg.

La dernière méthode d'utilisation des chargeurs est via la CLI avec le drapeau --module-bind.

Le awesome-webpack readme contient une liste exhaustive de loaders que vous pouvez utiliser avec webpack, chacun étant regroupé en catégories d'opérations qu'ils effectuent. Vous trouverez ci-dessous quelques chargeurs que vous pourriez trouver utiles dans votre application :

Responsive-loader
Vous trouverez ce chargeur très utile lors de l'ajout d'images pour s'adapter à votre site ou application réactif. Il crée plusieurs images de différentes tailles à partir d'une seule image et renvoie un srcset correspondant aux images pour une utilisation aux tailles d'écran d'affichage appropriées.
Babel-loader
Ceci est utilisé. pour transpiler votre code JavaScript de la syntaxe ECMA moderne vers ES5.
GraphQL-Loader
Si vous êtes un passionné de GraphQL, vous trouverez ce chargeur très utile car il charge votre . graphql contenant votre schéma GraphQL, vos requêtes et vos mutations, ainsi que l'option permettant d'activer la validation.

Plugins

L'utilisation de plugins permet au compilateur webpack d'effectuer des tâches sur morceaux produits à partir des modules groupés. Bien que webpack ne soit pas un exécuteur de tâches, avec des plugins, nous pouvons effectuer certaines actions personnalisées que les chargeurs ne pouvaient pas effectuer lorsque le code était groupé.

Un exemple de plugin webpack est le ProgressPlugin intégré. dans le pack Web. Il fournit un moyen de personnaliser la progression qui est imprimée dans la console lors de la compilation.

# webpack.config.js

const webpack = require("webpack")
const chemin = require("chemin")
const merge = require("webpack-merge")

configuration const = {
  mode : "développement",
  entrée : './src/entry',
  production: {
    nom de fichier : "webpack-output.js",
    chemin : chemin.resolve(__dirname, "dist"),
  },
  module : {
    règles : [
    {
      test: /.(jpe?g|png|gif|svg)$/i,
      use: [
        'img-loader'
        ]
    }
   ]
  },
  plug-ins : [ 
        new webpack.ProgressPlugin({
          handler: (percentage, message ) => {
            console.info(percentage, message);
          },
        })
    ]
}

module.exports = configuration

Avec le plug-in Progress dans la configuration ci-dessus, nous avons fourni une fonction de gestionnaire qui imprimera le pourcentage de compilation et un message à la console pendant le processus de compilation.

Une sortie shell affichant les messages du plugin de progression webpack. ( Grand aperçu)

Vous trouverez ci-dessous quelques plugins du awesome-webpack readme que vous trouverez utile dans votre application webpack.

Hors ligne -plugin
Ce plugin utilise d'abord service workers ou AppCache lorsqu'il est disponible pour fournir une expérience hors ligne pour les projets gérés par webpack.
Purgecss-webpack. -plugin
Ce plugin est pratique lorsque vous essayez d'optimiser votre projet de pack Web car il supprime les CSS inutilisés de votre application lors de la compilation.

À ce stade, nous avons notre première configuration de pack Web pour une application relativement petite entièrement configurée. Examinons en outre comment nous pouvons faire certaines choses avec webpack dans notre application.

Gestion de plusieurs environnements

Dans votre application, vous devrez peut-être configurer webpack différemment pour un environnement de développement ou de production. Par exemple, vous ne souhaitez peut-être pas que webpack génère des journaux d'avertissement mineurs à chaque fois qu'un nouveau déploiement est effectué sur votre pipeline d'intégration continue dans votre environnement de production.

Il existe plusieurs façons d'y parvenir, comme recommandé par webpack et la communauté. Une façon consiste à convertir votre fichier de configuration pour exporter une fonction qui renvoie un objet. De cette façon, l'environnement actuel sera transmis à la fonction par le compilateur webpack en tant que premier paramètre et une autre option en tant que deuxième paramètre.

Cette méthode de gestion de votre environnement webpack sera utile s'il y a quelques opérations que vous ' J'aimerais fonctionner différemment en fonction de l'environnement actuel. Cependant, pour les applications plus volumineuses avec des configurations plus complexes, vous pourriez vous retrouver avec une configuration contenant de nombreuses instructions conditionnelles.

L'extrait de code ci-dessous montre un exemple de la façon de gérer une production et environnement de développement dans le même fichier en utilisant la méthode functions.

// webpack.config.js

module.exports = fonction (env, args) {
  revenir {
   mode : env.production ? 'production' : 'développement',
  entrée : './src/entrée',
  production: {
    nom de fichier : "webpack-output.js",
    chemin : chemin.resolve(__dirname, "dist"),
  },
  plug-ins : [ 
       env.development && ( 
          new webpack.ProgressPlugin({
            handler: (percentage, message ) => {
                console.info(percentage, message);
            },
        })
      )
    ]
  }
}

En parcourant la fonction exportée dans l'extrait de code ci-dessus, vous verrez comment le paramètre env transmis à la fonction est utilisé avec un opérateur ternaire pour changer de valeur. Il est d'abord utilisé pour définir le mode webpack, puis il est également utilisé pour activer le ProgressPlugin uniquement en mode développement.

Une autre façon plus élégante de gérer votre production et développement consiste à créer des fichiers de configuration différents pour les deux environnements. Une fois cela fait, nous pouvons les utiliser avec différentes commandes dans les scripts package.json lors du regroupement de l'application. Jetez un œil à l'extrait ci-dessous :

{
  "nom" : "magazine fracassant",
  "principal" : "index.js"
  "scénarios" : {
    "bundle:dev": "webpack --config webpack.dev.config.js",
    "bundle:prod" : "webpack --config webpack.prod.config.js"
  },
  "dépendances" : {
    "webpack": "^5.24.1"
  }
}

Dans le package.json ci-dessus, nous avons deux commandes de scriptchacune utilisant un fichier de configuration différent écrit pour gérer un environnement spécifique lors du regroupement des actifs de l'application. Vous pouvez désormais regrouper votre application en utilisant npm run bundle:dev en mode développement, ou npm run bundle:prod lors de la création d'un bundle prêt pour la production.

En utilisant la deuxième approche, vous évitez les instructions conditionnelles introduites lors du retour de votre objet de configuration à partir d'une fonction. Cependant, maintenant, vous devez également gérer plusieurs fichiers de configuration.

Diviser le fichier de configuration

À ce stade, notre fichier de configuration Webpack contient 38 lignes de code (LOC). C'est tout à fait correct pour une application de démonstration avec un seul chargeur et un seul plug-in.

Pour une application plus importante, notre fichier de configuration Webpack sera certainement beaucoup plus long, ayant plusieurs chargeurs et plug-ins avec leur options chacun. Pour que le fichier de configuration reste propre et lisible, nous pouvons diviser la configuration en objets plus petits sur plusieurs fichiers, puis utiliser le package webpack-merge pour fusionner les objets de configuration en un seul fichier de base.[19659006] Pour l'appliquer à notre projet webpack, nous pouvons diviser le fichier de configuration unique en trois fichiers plus petits : un pour les chargeurs, un pour les plug-ins et le dernier fichier en tant que fichier de configuration de base où nous mettons les deux autres fichiers ensemble.[19659006]Créez un fichier webpack.plugin.config.js et collez-y le code ci-dessous pour utiliser les plugins avec des options supplémentaires.

// webpack.plugin.config.js
const webpack = require('webpack')
 
plugin const = [
  new webpack.ProgressPlugin({
          handler: (percentage, message ) => {
            console.info(percentage, message);
          },
  })
]

module.exports = plugin

Ci-dessus, nous avons un seul plugin que nous avons extrait du fichier webpack.configuration.js.

Ensuite, créez un webpack.loader.config.js avec le code ci-dessous pour les chargeurs de webpack.

// webpack.loader.config.js

chargeur const = {
 module : {
    règles : [
    {
      test: /.(jpe?g|png|gif|svg)$/i,
      use: [
        'img-loader'
        ]
    }
  ]
  }
}

Dans le bloc de code ci-dessus, nous avons déplacé le webpack img-loader dans un fichier séparé.

Enfin, créez un fichier webpack.base.config.js où la configuration d'entrée et de sortie de base de l'application webpack sera conservée avec les deux fichiers créés ci-dessus.

// webpack.base.config.js
const chemin = require("chemin")
const merge = require("webpack-merge")

const plugins = require('./webpack.plugin.config')
const loaders = require('./webpack.loader.config')

const config = merge(loaders, plugins, {
  mode : "développement",
  entrée : './src/entry',
  production: {
    nom de fichier : "webpack-output.js",
    chemin : chemin.resolve(__dirname, "dist"),
  }
});

module.exports = configuration

En jetant un coup d'œil au fichier webpack ci-dessus, vous pouvez observer à quel point il est compact par rapport au fichier d'origine webpack.config.js. Maintenant, les trois parties principales de la configuration ont été divisées en fichiers plus petits et peuvent être utilisées individuellement.

Optimisation des grandes versions

Au fur et à mesure que vous continuez à travailler sur votre application sur une période de temps, votre application va certainement augmenter en fonctionnalités. et la taille. Au fur et à mesure que cela se produit, de nouveaux fichiers seront créés, les anciens fichiers seront modifiés ou refactorisés et de nouveaux packages externes seront installés, ce qui entraînera une augmentation de la taille du bundle émis par webpack.

Par défaut. , webpack essaie automatiquement d'optimiser les offres groupées en votre nom si votre mode de configuration est défini sur production. Par exemple, une technique que webpack applique par défaut (à partir de webpack 4+) pour optimiser et réduire la taille de votre bundle est Tree-Shaking. Il s'agit essentiellement d'une technique d'optimisation utilisée pour supprimer le code inutilisé. À un niveau simple lors du regroupement, les instructions d'importation et d'exportation sont utilisées pour détecter les modules inutilisés avant de les supprimer des regroupements émis.

Vous pouvez également optimiser manuellement votre regroupement d'applications en en ajoutant un objet optimisation avec certains champs dans votre fichier de configuration. La section optimization de la documentation webpack contient une liste complète des champs que vous pouvez utiliser dans l'objet optimization pour optimiser votre application. Considérons un des 20 champs documentés.

minimize
Ce champ booléen est utilisé pour indiquer à webpack de minimiser la taille du paquet. Par défaut, webpack essaiera d'y parvenir en utilisant TerserPluginun package de minimisation de code livré avec webpack.

« La minimisation s'applique à la minimisation de votre code en supprimant les données inutiles du code, ce qui réduit à son tour la taille du code. produit après le processus. »

Nous pouvons également utiliser d'autres minificateurs préférés en ajoutant un champ de tableau minimizer dans l'objet optimization. Un exemple est l'utilisation de Uglifyjs-webpack-plugin ci-dessous.

// webpack.config.js
const Uglify = require("uglifyjs-webpack-plugin")

module.exports = {
    optimisation {
      minimiser : vrai,
      minimiseur : [
        new Uglify({
          cache : true,
          test: /.js(?.*)?$/i,
       })
    ]
  }
 }

Ci-dessus, uglifyjs-webpack-plugin est utilisé comme un minificateur avec deux options assez importantes. Tout d'abord, l'activation de cache signifie qu'Uglify ne minimisera les fichiers existants que lorsqu'il s'agit de nouvelles modifications, et l'option test spécifie les types de fichiers spécifiques que nous souhaitons minimiser.

Remarque : Le uglifyjs-webpack-plugin donne une liste complète des options disponibles à utiliser lors de la minification de votre code avec.

Une petite démo d'optimisation

Essayons manuellement d'optimiser un application de démonstration en appliquant certains champs dans un projet plus vaste pour voir la différence. Bien que nous ne nous attardions pas sur l'optimisation de l'application, nous verrons la différence de taille des bundles entre l'exécution de webpack en mode développement et en mode production.

Pour cette démo, nous utiliserons une application de bureau construite avec Electron qui utilise également React.js pour son interface utilisateur — le tout regroupé avec webpack. Electron et React.js ressemblent à une combinaison assez lourde et pourraient probablement générer un paquet plus important.

Remarque : Si vous découvrez Electron pour la première fois, cet article donne un bon aperçu de ce qu'est Electron et comment vous pouvez l'utiliser pour créer des applications de bureau multiplateformes.

Pour essayer la démo localement, clonez l'application à partir du référentiel GitHub et installez les dépendances à l'aide des commandes ci-dessous.

# clone repository
git clone https://github.com/vickywane/webpack-react-demo.git

# changer de répertoire
cd demo-electron-react-webpack

# installer des dépendances
npm install

L'application de bureau est assez simple avec une seule page stylisée à l'aide de styled-components. Lorsque l'application de bureau est lancée avec la commande yarn startla page unique affiche une liste d'images extraites d'un CDN, comme illustré ci-dessous.

Aperçu sur le bureau des images dans l'application Electron avec l'interface React.js. ( Grand aperçu)

Créons d'abord un bundle de développement de cette application sans aucune optimisation manuelle pour analyser la taille finale du bundle.

En cours d'exécution yarn build:dev à partir d'un terminal dans le répertoire du projet créera le bundle de développement. De plus, il imprimera les statistiques suivantes sur votre terminal :

journaux du terminal du compilateur webpack lorsqu'il est exécuté en mode développement sans optimisations manuelles. ( Grand aperçu)

La commande nous montrera les statistiques de l'ensemble de la compilation et des bundles émis.

Prenez note du chunk mainRenderer.js est à 1,11 Mebibyte (environ 1,16 Mo). Le mainRenderer est le point d'entrée de l'application Electron.

Ensuite, ajoutons uglifyjs-webpack-plugin en tant que plug-in installé dans webpack.base.config. js pour la minification du code.

// webpack.base.config.js
const Uglifyjs = require("uglifyjs-webpack-plugin")

module.exports = {
  plugins : [
    new Uglifyjs({
      cache : true
    })
  ]
}

Enfin, exécutons l'application avec webpack en mode production. L'exécution de la commande yarn build:prod à partir de votre terminal affichera les données ci-dessous sur votre terminal.

Les journaux du compilateur webpack lorsque l'application est regroupée en mode production avec le code minification. ( Grand aperçu)

Prenez note du morceau mainRenderer cette fois. Il est tombé à un énorme 182 Kibioctets (environ 186 Ko), et c'est plus de 80% de la taille du morceau mainRenderer émis précédemment ! bundler-analyseur. Installez le plugin à l'aide de la commande yarn add webpack-bundle-analyzer et modifiez le fichier webpack.base.config.js pour contenir le code ci-dessous qui ajoute le plugin.

/ / webpack.base.config.js
const Uglifyjs = require("uglifyjs-webpack-plugin");
const BundleAnalyzerPlugin = require("webpack-bundle-analyzer");
  .BundleAnalyzerPlugin;

configuration const = {
  plug-ins : [
    new Uglifyjs({
      cache : true
    }),
    new BundleAnalyzerPlugin(),
  ]
} ;

module.exports = config;

Exécutez yarn build:prod depuis votre terminal pour que l'application soit regroupée. Par défaut, webpack-bundle-analyzer démarrera un serveur HTTP qui servira l'aperçu visualisé des bundles dans votre navigateur.

analyseur de bundle webpack affichant un visuel représentation du paquet émis et des fichiers à l'intérieur. ( Grand aperçu)

À partir de l'image ci-dessus, nous pouvons voir une représentation visuelle du bundle émis et des tailles de fichiers au sein du bundle. Dans le visuel, on peut observer que dans le dossier node_modulesle plus gros fichier est le react-dom.production.min.jssuivi de stylis.min.js .

En utilisant les tailles de fichier visualisées par l'analyseur, nous aurons une meilleure idée du package installé qui contribue à la majeure partie du bundle. On peut alors chercher des moyens de l'optimiser ou de le remplacer par un package plus léger.

Remarque : La documentation webpack-analyzer-plugin liste d'autres moyens disponibles pour afficher l'analyse créée à partir de vos bundles émis.

L'une des forces de webpack a été la grande communauté de développeurs derrière lui et cela a été d'une grande utilité pour les développeurs qui essaient webpack pour la première fois. Tout comme cet article, il existe plusieurs articles, guides et ressources avec la documentation qui constitue un excellent guide lors de l'utilisation de webpack.

Par exemple, Build Performance guide from webpack's blog contient des conseils sur l'optimisation de votre webpack. builds et L'étude de cas de Slack (bien qu'un peu ancienne) explique comment webpack a été optimisé sur Slack.

Plusieurs ressources de la communauté expliquent certaines parties de la documentation de webpack, vous fournissant des exemples de projets de démonstration pour montrer comment les fonctionnalités de webpack sont utilisées. Un exemple est un article sur Webpack 5 Module Federation qui explique comment la nouvelle fonctionnalité Module Federation de webpack est utilisée dans une application React.

Résumé

Après sept ans d'existence. , webpack s'est vraiment avéré être une partie importante de la chaîne d'outils JavaScript utilisée par un grand nombre de projets. This article only gives a glimpse into the things one can achieve with webpack’s flexible and extensible nature.

The next time you need to choose a module bundler for your application, hopefully you will better understand some core concepts of Webpack, the problem it solves, and also the steps of setting up your configuration files.

Blog ARC Optimizer