Webpack 4 et division du fichier de configuration en modules

Bonjour, Habr! Aujourd'hui, je vais vous parler de Webpack 4 avec la séparation du code en modules séparés, ainsi que des solutions intéressantes qui vous aideront à construire votre assemblage Webpack 4. Plus vite, je fournirai à mon assemblage Webpack de base les outils les plus nécessaires, que vous pourrez plus tard pour étendre. Cet assemblage vous aidera à comprendre ce matériel, et il peut également vous aider à écrire votre implémentation plus rapidement et à résoudre plus rapidement les problèmes possibles.

L'idéologie principale de cet assemblage est la séparation correcte du code à l'intérieur du fichier de configuration pour la commodité d'utilisation, la lecture et la propreté de webpack.config.js. Les modules et plugins nécessaires pour les versions dev et prod (ainsi que pour la séparation des fonctionnalités dans le fichier principal) seront situés dans un dossier webpack séparé et importés depuis celui-ci pour se connecter à la configuration principale.

Pourquoi cette approche est-elle nécessaire?

Avec l'augmentation progressive du nombre de modules, plug-ins, etc., que votre assemblage construit sur le webpack, le fichier de configuration se développe à pas de géant. Au fil du temps, ce fichier devient difficile à lire et le changer en un projet spécifique, si certains modules n'y sont pas utilisés, cela devient plus difficile, mais vous voulez quelque chose d'universel. Par conséquent, une organisation claire du code est requise.

De quoi avons-nous besoin?

Nous utiliserons le plugin webpack-merge .

Nous créons le dossier webpack et retirons tous les modules individuels dans des fichiers séparés. Par exemple, webpack / pug.js, webpack / scss.js et exportez ces fonctions à partir d'eux.

Fichier Pug.js

module.exports = function() { return { module: { rules: [ { test: /\.pug$/, loader: 'pug-loader', options: { pretty: true, }, }, ], }, }; }; 

Le fichier webpack.config.js . Dans ce fichier, nous les connectons, et à l'aide de ce plugin, nous nous connectons facilement et rapidement.

 const merge = require('webpack-merge'); const pug = require('./webpack/pug'); const common = merge([ { entry: { 'index': PATHS.source + '/pages/index/index.js', 'blog': PATHS.source + '/pages/blog/blog.js', }, output: { path: PATHS.build, filename: './js/[name].js', }, plugins: […], optimization: { … }, }, pug(), ]); 

Maintenant, si nous avons une nouvelle tâche, pour laquelle nous avons besoin d'un nouveau module, plug-in, chargeur, nous le prenons dans le module hôtel (fichier) et le mettons dans le dossier webpack, puis le connectons au fichier de configuration principal, en gardant la configuration aussi propre que possible.

Paramètres de production et de développement

Maintenant, avec l'aide du banal if, nous terminerons notre séparation, vers laquelle nous visions, et configurerons notre webpack pour ces deux types de développement, ce qui rendra finalement pratique l'utilisation de cet outil, et à l'avenir, nous serons en mesure de le configurer de manière flexible et simple pour tout autre projet, ou développer dans l'actuel. Pour exporter vers un nœud (pour le webpack lui-même) dans webpack 4, nous utilisons la construction suivante:

 module.exports = function(env, argv) { if (argv.mode === 'production') { return merge([ common, extractCSS(), favicon(), ]); } if (argv.mode === 'development') { return merge([ common, devserver(), sass(), css(), sourceMap(), ]); } 

Dans l'objet commun, nous connectons ce qui est utilisé à la fois dans le prod et dans le développement, et dans les conditions, nous connectons uniquement les modules qui sont nécessaires dans ces cas.

Maintenant, je voudrais parler des principales fonctionnalités de webpack 4 concernant webpack 3

• Pour un démarrage rapide, webpack 4 n'a pas besoin de webpack.config.js, maintenant il n'a besoin que d'un point d'entrée (index.js)
• Dans la nouvelle version, l'interface de ligne de commande de webpack est dans un package séparé et vous devez installer webpack-cli.
• Pour exécuter webpack 4, vous devez (sinon ce sera un avertissement) dans les scripts spécifier le mode (mode de fonctionnement) - la production de mode ou - le développement de mode, selon la clé, le fonctionnement du webpack change. Le mode de développement vise à accélérer la construction. Dans la version de production, tout est destiné à la minification finale du code.
• Afin de créer des fichiers common.js et common.css, CommonsChunkPlugin n'est plus utilisé, les splitChunks en sont désormais responsables et la construction suivante est utilisée:
  
  

    optimization: { splitChunks: { cacheGroups: { 'common': { minChunks: 2, chunks: 'all', name: 'common', priority: 10, enforce: true, }, }, }, }, 

  
  Dans webpack 3 - ce serait le cas dans les plugins:
  
  

   new webpack.optimize.CommonsChunkPlugin({ name: 'common ', }) 

  
  En conséquence, dans les morceaux de HtmlWebpackPlugin, nous nous connectons (ici sans modifications).
  
  

   plugins: [ new HtmlWebpackPlugin({ filename: 'index.html', chunks: ['index', 'common'], template: PATHS.source + '/pages/index/index.pug', }), ], 

  
  
• Le prochain point important, afin de créer sourceMap, nous utilisons maintenant l'approche suivante - créer le fichier sourceMap.js dans le dossier webpack et le connecter dans la version dev par exemple (comme mentionné ci-dessus):
  
  

   module.exports = function() { return { devtool: 'eval-sourcemap', }; }; 

Maintenant, l'approche des plugins: [new webpack.optimize.UglifyJsPlugin ({})] ne fonctionne pas.

Avec cela, je voudrais terminer mon histoire et fournir mon assemblage de base - un lien vers webpack 4, qui vous aidera probablement dans votre travail et votre développement. Merci de votre attention!