1.
L'entrée demande à Webpack d'utiliser quel fichier comme point de départ pour commencer à empaqueter, analyser et créer le graphe de dépendances interne.
2.
Output indique à Webpack où sortir les ensembles de ressources packagés et comment les nommer.
3. Le webpack Loader
ne peut comprendre que les fichiers JavaScript et JSON, qui constituent la fonctionnalité intégrée du webpack disponible immédiatement. Les chargeurs permettent à Webpack de traiter d'autres types de fichiers et de les convertir en modules valides pouvant être utilisés par les applications et ajoutés au graphe de dépendances.
4.
PluginsLes plugins peuvent être utilisés pour effectuer un plus large éventail de tâches. Les plug-ins vont de l'optimisation et de la compression du packaging à la redéfinition des variables dans l'environnement.
5.
Mode mode (Mode) demande à webpack d'utiliser la configuration du mode correspondant.
Donnons une introduction détaillée aux cinq concepts fondamentaux du webpack.
L'objet d'entrée est utilisé par webpack pour rechercher, démarrer et créer le bundle. L'entrée est le point de départ de l'application. À partir de ce point de départ, l'application démarre l'exécution. Si vous transmettez un tableau, chaque élément du tableau sera exécuté. Le point d'entrée indique quel module webpack doit utiliser pour commencer à créer son graphe de dépendances interne. Après avoir entré le point d'entrée, webpack découvrira de quels modules et bibliothèques dépend le point d'entrée (directement et indirectement).
Règle simple : chaque page HTML a un point de départ. Application monopage (SPA) : un point d'entrée, application multipage (MPA) : plusieurs points d'entrée.
La valeur par défaut est ./src/index.js , mais vous pouvez spécifier un ou plusieurs points d'entrée différents en configurant l'attribut entry dans la configuration du webpack. Par exemple :
//Entrée unique--string module.exports = {
entrée : './path/to/my/entry/file.js',
} ;
//Entrées multiples--array module.exports = {
entrée : ['./src/index.js', './src/add.js']
} ;
//Entrées multiples--objet module.exports = {
entrée : {
maison : './home.js',
à propos de : './à propos.js',
contact : './contact.js'
}
}; Type de valeur d'entrée :
chaîne : entrée unique, emballée pour former un morceau, et un seul fichier bundle sera généré à la fin. Le nom par défaut du morceau est le
tableau principal : plusieurs entrées, tous les fichiers d'entrée seront uniquement. formez un morceau à la fin. Générez un fichier bundle et le nom du morceau est par défaut principal. Généralement utilisé uniquement dans la fonction HMR pour créer
un objet efficace de mise à jour à chaud HTML : plusieurs entrées, autant de morceaux qu'il y a de clés, et autant de fichiers de bundle sont générés, et chaque clé (clé) sera le nom du morceau. Dans le type d'objet, la valeur de chaque clé peut également être un tableau, pas seulement une chaîne
output à Webpack comment et où afficher votre bundle, votre actif et les autres packages que vous emballez ou tout ce qui est chargé à l'aide de Webpack. . La valeur par défaut du bundle de sortie est ./dist/main.js , et les autres fichiers générés sont placés par défaut dans le dossier ./dist .
Vous pouvez configurer ces processus en spécifiant un champ output dans la configuration :
//webpack.config.js
const chemin = require('chemin');
module.exports = {
entrée : './path/to/my/entry/file.js',
sortir: {
chemin : chemin.resolve(__dirname, 'dist'),
nom de fichier : 'mon-premier-webpack.bundle.js',
},
}; Nous pouvons indiquer à webpack le nom du bundle et où le bundle est généré via output.filename et output.path .
2.1.output.filename (nom de fichier et répertoire)
Cette option détermine le répertoire et le nom de chaque bundle de sortie. Ces bundles seront écrits dans le répertoire spécifié par l'option output.path .
Pour un seul point入口, le nom de fichier sera un nom statique. Cependant, lors de la création de plusieurs bundles via plusieurs points d'entrée, le fractionnement de code ou divers plug-ins, d'autres méthodes doivent être utilisées pour donner à chaque bundle un nom unique.
//Entrée unique :
module.exports = {
//...
sortir: {
nom de fichier : 'js/bundle.js'
}
} ;
//Plusieurs entrées - utilisez le nom de l'entrée :
module.exports = {
//...
sortir: {
nom de fichier : '[nom].bundle.js'
}
} ;
// Entrées multiples - utilisez un hachage unique pour générer module.exports = { dans chaque processus de construction
//...
sortir: {
nom de fichier : '[nom].[hash].bundle.js'
}
} ;
... 2.2.output.path (répertoire de fichiers)
output.path spécifie le répertoire de tous les fichiers de sortie, qui est le répertoire commun pour toutes les futures sorties de ressources. le chemin doit être un chemin absolu.
module.exports = {
//...
sortir: {
chemin : chemin.resolve(__dirname, 'dist/assets')
}
}; 2.3. output.publicPath (préfixe de chemin des ressources référencées)
publicPath spécifie le préfixe de chemin public introduit par toutes les ressources dans le fichier html. Cela n'affecte pas le chemin du fichier généré. Au lieu de cela, lorsque le fichier HTML introduit diverses ressources, publicPath est ajouté comme préfixe au chemin des ressources importées.
Exemple :
dans la configuration du webpack générée par vue-cli, la valeur de publicPath dans l'environnement de production est par défaut "/", qui est le répertoire racine du répertoire actuel.
Après packaging, nous ouvrons le fichier html et nous pouvons voir que le chemin de ressource introduit dans le fichier html est :
Comme vous pouvez le voir, le symbole / est ajouté devant le chemin. Lorsque nous ouvrons le navigateur pour accéder au fichier html généré, nous trouverons une erreur La ressource n'est pas accessible et un rapport 404 est signalé. À ce moment, l'accès à la ressource est similaire au suivant :
Cela peut être comme suit sur le serveur, mais il peut y avoir des problèmes pour y accéder.
Nous pouvons remplacer publicPath par un chemin relatif ou le commenter directement.
2.3.1. La différence entre path et publicPath.
打包后文件在硬盘中的存储位置，是webpack所有文件的输出的路径，必须是绝对路径。比如：输出的js、图片，HtmlWebpackPlugin生成的html文件等，都会存放在以path为基础的目录下。2.4.output.chunkFilename (nom du fragment de non-entrée)
output.chunkFilename détermine le nom du fichier de fragment de non-entrée. Autrement dit, en plus des fragments générés par le fichier d'entrée, les fichiers de fragments générés par d'autres fichiers sont nommés.
module.exports = {
//...
sortir: {
chunkFilename : 'js/[name]_chunk.js' //Le nom du chunk sans entrée}
}; webpack lui-même ne peut empaqueter que des fichiers JavaScript et JSON ( webpack3+和webpack2+ ont un traitement intégré des fichiers JSON, mais webpack1+并不支持， doit introduire json-loader ). webpack disponible prêt à l'emploi. Webpack lui-même ne prend pas en charge le packaging d'autres types de fichiers, tels que CSS, Vue, etc., mais nous pouvons utiliser divers chargeurs pour permettre à Webpack de traiter ces types de fichiers. Le chargeur peut convertir des fichiers de différents langages (tels que TypeScript) en JavaScript ou convertir des images en ligne en URL de données. Le chargeur vous permet même import des fichiers CSS directement dans les modules JavaScript !
En utilisant différents loader , webpack a la capacité d'appeler des scripts ou des outils externes pour traiter des fichiers dans différents formats, comme l'analyse et la conversion de scss en css, ou la conversion de fichiers JS de nouvelle génération (ES6, ES7) en fichiers JS compatibles avec les navigateurs modernes. Pour le développement de React, les chargeurs appropriés peuvent convertir les fichiers JSX utilisés dans React en fichiers JS.
Dans la configuration du webpack, le chargeur a deux attributs :
l'attribut test , qui identifie les fichiers qui seront convertis.
L'attribut use définit quel chargeur doit être utilisé lors de la conversion.
include/exclude（可选）： ajouter manuellement des fichiers (dossiers) qui doivent être traités ou bloquer des fichiers (dossiers) qui n'ont pas besoin d'être traités.
query（可选） : fournir des options de configuration supplémentaires pour les chargeurs
// Exemple : webpack.config.
const chemin = require('chemin');
module.exports = {
sortir: {
nom de fichier : 'mon-premier-webpack.bundle.js',
},
module : {
règles: [
{ test : /.txt$/, chargeur : 'raw-loader' },
{ test : /.css$/, use : ['style-loader', 'css-loader'] } //Si vous utilisez plusieurs chargeurs, vous devez utiliser use
],
},
}; Dans la configuration ci-dessus, l'attribut rules est défini pour un objet module distinct, qui contient deux attributs obligatoires : test et use . Cela équivaut à dire au compilateur Webpack que lorsqu'il rencontre un chemin analysé comme « .txt » dans l'instruction require() / import , utilisez raw-loader pour le convertir avant de l'empaqueter.
Si vous utilisez plusieurs chargeurs, vous devez utiliser use. Les chargeurs du tableau use sont exécutés dans l'ordre : de droite à gauche, dans l'ordre. Par exemple, dans le fichier CSS ci-dessus, css-loader compilera d'abord le fichier CSS dans JS et le chargera dans le fichier JS. Ensuite, style-loader créera une balise de style et insérera les ressources de style dans JS dans la balise head.
3.1. CSS-loader
Webpack fournit deux outils pour traiter les feuilles de style, css-loader et style-loader . css-loader vous permet d'introduire des fichiers CSS en utilisant une méthode similaire à import . style-loader ajoute tous les styles calculés à la page. La combinaison des deux vous permet d'intégrer des feuilles de style dans des fichiers JS emballés par webpack. Le fichier peut être introduit dans le fichier JS.
//Installez npm install --save-dev style-loader css-loader //Si la version de css-loader est trop élevée, la compilation peut mal se passer. Il est recommandé de réduire la version telle que [email protected] disponible.
//Utilisez module.exports = {
...
module : {
règles: [
{
tester : /(.jsx|.js)$/,
utiliser: {
chargeur : "babel-loader"
},
exclure : /node_modules/
},
{
test : /.css$/, //Comment introduire plusieurs chargeurs dans le même fichier. L'ordre d'action des chargeurs est que les chargeurs ultérieurs commencent à agir en premier : [
{
chargeur : "chargeur de style"
}, {
chargeur : "css-loader"
}
]
}
]
}
}; Supposons qu'il existe un fichier main.css :
body {
fond : vert ;
} Pour que webpack trouve le fichier "main.css", nous l'importons dans "main.js", comme suit :
//main.js
importer React depuis « react » ;
importer {render} depuis 'react-dom' ;
importer Greeter depuis './Greeter' ;
import './main.css';//Utiliser require pour importer le fichier css render(<Greeter />, document.getElementById('root')); Normalement, css sera empaqueté dans le même fichier que js, pas Will être emballé dans un fichier CSS distinct. Cependant, avec une configuration appropriée, Webpack peut également regrouper les CSS dans des fichiers séparés.
sont utilisés pour convertir certains types de modules, tandis que les plug-ins peuvent être utilisés pour effectuer un plus large éventail de tâches, notamment : l'optimisation du packaging, la compression, la gestion des ressources, l'injection de variables d'environnement, etc. Le but du plug-in est de résoudre d'autres problèmes que le chargeur ne peut pas réaliser.
Pour utiliser un plugin, nous devons l'installer via npm puis ajouter une instance du plugin sous la propriété plugins. Étant donné que les plugins peuvent transporter des paramètres/options, vous devez transmettre la new instance à plugins dans la configuration du webpack. La plupart des plug-ins peuvent être personnalisés via des options et vous pouvez utiliser le même plug-in plusieurs fois à des fins différentes dans un fichier de configuration.
//webpack.config.js
const HtmlWebpackPlugin = require('html-webpack-plugin'); // Installer via npm const webpack = require('webpack'); // Utilisé pour accéder aux plug-ins intégrés module.exports = {
module : {
règles : [{ test : /.txt$/, use : 'raw-loader' }],
},
plugins : [nouveau HtmlWebpackPlugin({ modèle : './src/index.html' })],
}; Dans l'exemple ci-dessus, html-webpack-plugin génère un fichier HTML pour l'application et injecte automatiquement tous les bundles générés.
4.1. Plug-in BannerPlugin (ajout d'une déclaration de copyright)
Ci-dessous, nous avons ajouté un plug-in qui ajoute une déclaration de copyright au code packagé. Ce plug-in est un plug-in intégré au webpack et n'a pas besoin d'être installé.
const webpack = require('webpack');
module.exports = {
...
module : {
règles: [
{
tester : /(.jsx|.js)$/,
utiliser: {
chargeur : "babel-loader"
},
exclure : /node_modules/
},
{
tester : /.css$/,
utiliser: [
{
chargeur : "chargeur de style"
}, {
chargeur : "css-loader",
options : {
modules : vrai
}
}, {
chargeur : "postcss-loader"
}
]
}
]
},
plugins : [
new webpack.BannerPlugin('Wenxuehai Tous droits réservés, toute reproduction fera l'objet d'une enquête')
],
}; 4.2. Plug-in Hot Module Remplacement (chargement à chaud)
Hot Module Replacement (HMR) est un plug-in très utile dans le webpack. Il vous permet d'actualiser et de prévisualiser automatiquement l'effet modifié en temps réel après avoir modifié le code du composant. Le chargement à chaud est différent de webpack-dev-server Lorsque l'application est en cours d'exécution, le remplacement à chaud peut visualiser l'effet des mises à jour de code sans actualiser la page, tout comme la modification du style dom directement sur le navigateur, tandis que webpack-dev-server nécessite une actualisation. la page.
(1) Ajoutez le plug-in HMR au fichier de configuration du webpack ;
(2) Ajoutez le paramètre "hot" au serveur de développement Webpack ;
4.2.1. React implémente le chargement à chaud
. Les modules React peuvent utiliser Babel pour implémenter le chargement à chaud des fonctions. .
Babel dispose d'un plug-in appelé react-react-transform-hmr
à
react-transform-hrm de fonctionner correctement sans configuration supplémentaire du module React ;
-hmr
const webpack = require('webpack');
module.exports = {
entrée : __dirname + "/app/main.js",//Le seul fichier d'entrée qui a été mentionné plusieurs fois affiche : {
chemin : __dirname + "/public",
nom de fichier : "bundle.js"
},
outil de développement : 'eval-source-map',
serveur de développement : {
contentBase : "./public",//Le répertoire où se trouve la page chargée par le serveur local historyApiFallback : true,//Ne pas sauter en ligne : true,
chaud : vrai
},
module : {
règles: [
{
tester : /(.jsx|.js)$/,
utiliser: {
chargeur : "babel-loader"
},
exclure : /node_modules/
},
{
tester : /.css$/,
utiliser: [
{
chargeur : "chargeur de style"
}, {
chargeur : "css-loader",
options : {
modules : vrai
}
}, {
chargeur : "postcss-loader"
}
]
}
]
},
plugins : [
new webpack.BannerPlugin('Copyright, toute reproduction fera l'objet d'une enquête'),
new webpack.HotModuleReplacementPlugin() //Plug-in de rechargement à chaud],
} ; Configurer Babel
// .babelrc
{
"presets": ["react", "env"],
"env": {
"développement": {
"plugins": [["réagir-transformer", {
"transformes": [{
"transform": "réagir-transformer-hmr",
"imports": ["réagir"],
"locales": ["module"]
}]
}]]
}
}
} //Accueil,js
importer React, {
Composant
} de 'réagir'
importer des styles depuis './main.css'
la classe Greeter étend le composant {
rendre() {
retour (
<div>
<h1>
aaaf
</h1>
</div>
);
}
}
exporter le Greeter par défaut //main.js
importer React depuis « react » ;
importer {
rendre
} de 'réagir-dom';
importer Greeter depuis './greeter.js' ;
render( < Greeter /> , document.getElementById('root')); Maintenant, si nous pouvons implémenter le module de chargement à chaud, nous pouvons voir le contenu mis à jour directement sur le navigateur à chaque fois que nous enregistrons, et le navigateur n'a pas besoin d'être actualisé. Actualiser automatiquement.
(Parfois il n'y a aucun effet, cela peut être un problème de version)
4.3. Plug-in ExtractTextWebpackPlugin (extraction du CSS
Par défaut, webpack ne traitera pas le style CSS comme un fichier indépendant, mais regroupera également le CSS dans un fichier js)
.et emballez le généré. Lorsque le fichier js est rendu, le style sera inséré dans la page sous la forme d'une balise de style via la syntaxe js. Mais dans ce cas, le fichier bundle packagé peut être trop volumineux. Pour le moment, nous pouvons utiliser le plug-in ExtractTextWebpackPlugin pour séparer le style CSS dans un fichier CSS.
Le plug-in ExtractTextWebpackPlugin déplacera le *.css référencé dans le bloc d'entrée (y compris le fichier CSS importé et le style écrit dans le fichier vue) vers un fichier CSS indépendant et séparé. ExtractTextPlugin générera un fichier CSS correspondant pour chaque bloc d'entrée, ce qui signifie qu'une entrée correspond à un fichier CSS. S'il y a plusieurs entrées, plusieurs fichiers CSS correspondants seront générés respectivement.
Avec le plug-in ExtractTextWebpackPlugin, vos styles ne seront plus intégrés dans le bundle JS, mais seront placés dans un fichier CSS séparé (c'est-à-dire styles.css ). Si vos fichiers de style sont plus volumineux, cela accélérera le chargement anticipé car le bundle CSS sera chargé en parallèle avec le bundle JS.
const ExtractTextPlugin = require("extract-text-webpack-plugin");
module.exports = {
module : {
règles: [
{
tester : /.css$/,
utiliser : ExtractTextPlugin.extract({
solution de secours : "style-loader",
utilisez : "css-loader"
})
}
]
},
plugins : [
nouveau ExtractTextPlugin({
filename : utils.assetsPath('css/[name].[contenthash].css'), //ExtractTextPlugin génère un fichier correspondant pour chaque morceau d'entrée, donc lorsque vous configurez plusieurs morceaux d'entrée, vous devez utiliser [ nom], [id ] ou [contenthash]
// allChunks : true, // Lors de l'utilisation de `CommonsChunkPlugin` et qu'il y a des morceaux extraits (de `ExtractTextPlugin.extract`) dans le morceau commun, `allChunks` ** doit être défini sur `true`.
}),
]
} 4.3.1. Option allChunks (si l'on doit également extraire ensemble les styles chargés de manière asynchrone)
La valeur par défaut de l'option allChunks du plug-in ExtractTextWebpackPlugin est false.
L'option allChunks indique si les styles chargés de manière asynchrone doivent être extraits ensemble. Car par défaut, même si le plug-in ExtractTextWebpackPlugin est utilisé, si le style ou le fichier de style est chargé de manière asynchrone, ces styles ne seront pas extraits dans des fichiers css indépendants, mais seront quand même packagés dans des fichiers js.
Par conséquent, allChunks:false est la valeur par défaut. La valeur par défaut consiste à extraire le code de l'entrée, mais le code chargé de manière asynchrone ne sera pas extrait ; allChunks:true consiste à extraire le code de tous les modules (y compris les modules chargés de manière asynchrone) dans. un fichier. Si le chargement asynchrone des styles est utilisé, mais que allChunks est défini sur false, nous devons alors définir la solution de secours de ExtractTextPlugin.extract. fallback consiste à utiliser style-loader pour charger de manière asynchrone lorsque le code CSS chargé par le code asynchrone ne l'est pas. extrait. Le style du composant.
Veuillez vous référer à :
https://github.com/sevenCon/blog-github/blob/master/articles/webpack Study Notes (2) -Utilisation de ExtractTextWebpackPlugin.md
https://blog.csdn.net/weixin_41134409/article/ détails /88416356
En sélectionnant l'un des development , production ou none pour définir mode , vous pouvez activer l'optimisation intégrée de webpack dans l'environnement correspondant. Sa valeur par défaut est production .
module.exports = {
mode : 'production',
}; La configuration de l'option mode directement dans le fichier de configuration indiquera à webpack d'utiliser l'optimisation intégrée du mode correspondant. Les options de mode incluent le développement, la production et aucune.
développement : mode développement, le code packagé ne sera pas compressé et le débogage du code est activé.
production : mode de production, tout le contraire.
Définissez le mode sur développement ou production, et webpack définira automatiquement la valeur de process.env.NODE_ENV. Nous pouvons obtenir cette valeur directement dans n'importe quel dossier. Mais si vous définissez uniquement NODE_ENV , mode ne sera pas défini automatiquement. (Dans le nœud, la variable globale process représente le processus de nœud actuel. L'attribut process.env contient des informations sur l'environnement utilisateur. L'attribut NODE_ENV n'existe pas dans process.env lui-même. Nous définissons généralement nous-mêmes l'attribut NODE_ENV et l'utilisons pour déterminer s'il est un environnement de production ou un environnement de développement)
(Attention : l'option mode est nouvelle dans webpack4. Avant la version 4, elle était définie avec le plug-in DefinePlugin. Webpack4 a supprimé le DefinePlugin)
5.1 La configuration du mode du projet vue-cli. est expliqué en détail
dans webpack. Généralement, la valeur de NODE_ENV sera configurée dans le fichier de configuration. Dans le projet vue généré par défaut à l'aide de vue-cli, la configuration NODE_ENV est la suivante :
//Sous le fichier webpack.dev.conf.js, le fichier dev.env.js est introduit nouveau webpack.DefinePlugin({
'processus.env' : require('../config/dev.env')
}), //module.exports = merge(prodEnv, { dans le fichier dev.env.js
NODE_ENV : '"développement"'
}) // Sous le fichier webpack.prod.conf.js, le fichier prod.env.js est introduit const env = require('../config/prod.env')
nouveau webpack.DefinePlugin({
'processus.env' : env
}), //module.exports = { dans le fichier prod.env.js
NODE_ENV : '"production"'
} Comme vous pouvez le voir ci-dessus, dans l'environnement de développement, le fichier de configuration configure NODE_ENV sur « développement » ; dans l'environnement de production, le fichier de configuration configure NODE_ENV sur « production ».
Lorsque nous exécuterons le projet, nous exécuterons npm run dev ou npm run build Ces deux commandes utiliseront le fichier de configuration de l'environnement de développement ou de l'environnement de production pour générer le projet en cours, et configurerons en conséquence la valeur NODE_ENV correspondante. la valeur NODE_ENV correspondante peut être obtenue dans n'importe quel fichier du projet (pas nécessairement le fichier de configuration, car cela dépend si le fichier de configuration configuré avec la valeur NODE_ENV a pris effet).
5.2.
Le processus de configuration Process.env.NODE_ENV est une variable globale du nœud et le processus a l'attribut env, mais n'a pas l'attribut NODE_ENV. La variable NODE_ENV n'est pas directement disponible dans process.env, mais est obtenue en la définissant. Cependant, NODE_ENV est généralement utilisée pour définir le type d'environnement. La fonction de cette variable est la suivante : on peut distinguer l'environnement de développement ou l'environnement de production en jugeant cette variable.
(1) Les valeurs des variables globales peuvent être définies via le plugin DefinePlugin intégré de webpack :
new webpack.DefinePlugin({
'process.env.NODE_ENV' : JSON.stringify('production')
}), après paramétrage, vous pouvez obtenir cette valeur dans le script d'exécution, par exemple :
// main.js console.log(process.env.NODE_ENV); //production
mais cette valeur ne peut pas être obtenue dans le fichier de configuration webpack.config.js.
(2) Téléchargez d'abord le package cross-env via le
paramètre du package cross-env :
cnpm i cross-env -D
Définissez le fichier package.json :
"build": "cross-env NODE_ENV=test webpack --config webpack.config .js"
À l'heure actuelle, la valeur (process.env.NODE_ENV) peut être obtenue dans le fichier de configuration, mais ne peut pas être obtenue dans le script exécutable. Elle doit être utilisée avec le plug-in DefinePlugin.