Explication détaillée de la configuration associée des chemins dans Webpack

Cet article vous présente principalement les informations pertinentes sur la configuration du chemin dans Webpack2. L'introduction dans l'article est très détaillée et a une certaine valeur de référence et d'apprentissage pour tous les amis qui en ont besoin peuvent y jeter un œil ci-dessous.

Préface

Il existe de nombreuses configurations de paramètres de chemin impliquées dans Webpack2. Si vous ne savez pas pourquoi, il est facile de se tromper et de se tromper. faire des erreurs. Cet article rassemble autant que possible la configuration des chemins impliqués dans Webpack2, et s'efforce de l'expliquer en termes simples.

context

context est le répertoire de base lorsque webpack est compilé, et le point d'entrée (entrée) sera recherché par rapport à ce répertoire.

La valeur par défaut est le répertoire actuel. Le code de valeur par défaut du contexte de configuration du webpack peut être téléchargé localement :

this.set("context", process.cwd());

process.cwd() est le répertoire. où webpack est en cours d'exécution (équivalent au répertoire où se trouve package.json).

le contexte doit être configuré comme un chemin absolu. Si le point de départ de l'entrée est src/main.js, vous pouvez configurer :

{
 context: path.resolve('./src'),
 entry: './main.js'
}

At cette fois, l'entrée ne peut plus être utilisée. Configurée comme './src/main.js', car webpack trouvera le point de départ de l'entrée (main.js) par rapport à la zone du répertoire src de la configuration du contexte, et main.js se trouve dans ce répertoire, l'entrée doit donc être configurée comme répertoire actuel (./).

Que fait réellement le contexte ? Le document officiel explique que "Cela rend votre configuration indépendante de CWD (répertoire de travail actuel)". Comment comprendre ? Par exemple, lors du développement et de la production de fichiers de configuration séparément, webpack.config est généralement placé dans le dossier build À ce stade, l'entrée n'a pas besoin d'être configurée par rapport au répertoire de construction, mais doit quand même le faire. être configuré par rapport au contexte, qui est dit indépendant du répertoire du projet.

Il convient de noter que les éléments de configuration de sortie n'ont rien à voir avec le contexte, mais certains éléments de configuration du plug-in sont liés au contexte, qui sera expliqué plus tard.

output

output.path

Le répertoire de sortie du fichier d'empaquetage, il est recommandé pour le configurer comme chemin absolu (les chemins relatifs ne signaleront pas d'erreurs), la valeur par défaut est la même que la valeur par défaut du contexte, les deux sont process.cwd().

En plus de la méthode de configuration conventionnelle, vous pouvez également utiliser le modèle [hash] dans le chemin. Par exemple, configuration :

output: {
 path: path.resolve('./dist/[hash:8]/'),
 filename: '[name].js'
}

. Le répertoire empaqueté est le suivant :

La valeur de hachage ici est le hachage du processus de compilation. Si le contenu empaqueté change, la valeur de hachage changera également. Cela peut être utilisé pour la restauration de version. Vous pouvez également le configurer sur path.resolve(`./dist/${Date.now()}/`) pour faciliter l'intégration continue, etc.

ouput.publicPath

Je me souviens que lorsque j'ai appris Webpack pour la première fois, je n'ai jamais complètement compris publicPath, et j'ai même pensé à tort que c'était lié à output.path . Cet élément de configuration est très important dans de nombreux scénarios. Si vous ne le comprenez pas en profondeur, vous ne pouvez pas l'utiliser de manière flexible.

Comment comprendre publicPath de manière rapide et précise, je pense que cela peut être exprimé par la formule suivante :

Chemin d'accès final aux ressources statiques = output.publicPath + Chemin de configuration tel que le chargeur de ressources ou le plug -in

Exemple :

output.publicPath = '/static/'

// 图片 url-loader 配置
{
 name: 'img/[name].[ext]'
}
// 那么图片最终的访问路径为
output.publicPath + 'img/[name].[ext]' = '/static/img/[name].[ext]'

// JS output.filename 配置
{
 filename: 'js/[name].js'
}
// 那么JS最终访问路径为 
output.publicPath + 'js/[name].js' = '/static/js/[name].js'

// CSS 
new ExtractTextPlugin("css/style.css")
// 那么最终CSS的访问路径为
output.publicPath + 'css/style.css' = '/static/css/style.css'

La valeur par défaut de publicPath est videString, regardons d'autres les plus courants La signification réelle de la configuration de publicPath.

publicPath est défini sur un chemin relatif. Le chemin relatif est en fait le chemin relatif à index.html. Pourquoi dites-vous cela ? Par exemple publicPath:"./dist/", le nom du fichier JS est bundle.js. Selon la formule ci-dessus, le chemin final pour accéder à JS est ./dist/bundle.js. Ce chemin est également le chemin pour index.html pour référencer le bundle. js. Puisqu'il doit être dans l'index, .html fait référence à bundle.js via un chemin relatif, alors l'emplacement de index.html détermine la configuration de publicPath. Par exemple, index.html se trouve dans le dossier A et le chemin publié. ne veut pas être placé dans le dossier A, mais veut être cohérent avec A. Si le dossier est au même niveau, il doit être configuré comme publicPath :"../dist/" Ceci est relatif au chemin d'index.html, bundle. js se trouve dans le dossier dist de la couche supérieure. L'avantage des chemins relatifs est qu'ils sont accessibles localement. Par exemple, le protocole de fichier utilisé par certaines applications hybrides ne fonctionnera certainement pas avec les chemins absolus.

publicPath est défini par rapport à l'URL du protocole (//) ou à l'adresse http (http://), comme publicPath:'http://wwww.qinshenxue.com/static/' Bien sûr, cela ne peut pas être fait dans l'environnement de développement. il s'agit d'héberger des ressources sur un CDN, comme le serveur de ressources statiques de l'entreprise, etc.

De plus, publicPath doit se terminer par '/', et la configuration d'autres chargeurs ou plug-ins ne doit pas commencer par '/'.

webpack-dev-server

publicPath

上面讲过 webpack 的 publicPath，那么这里的 publicPath 和 上面的publicPath是不是一回事呢？答案是两者区别很大，首先这里的publicPath用于开发环境的，因此不会出现配置 http 地址的情况，那这两者到底有啥区别呢？

我们知道 webpack-dev-server 打包的内容是放在内存中，通过express匹配请求路径，然后读取对应的资源输出。这些资源对外的根目录就是publicPath，可以理解为和 outpu.path 的功能一样，将所有资源放在此目录下，在浏览器可以直接访问此目录下的资源。

但是这个路径仅仅只是为了提供浏览器访问打包资源的功能，webpack中的loader和插件仍然是取ouput.publicPath，比如CSS里面的图片最终的路径仍是"/static/img/xxxx.png"，这也是为什么官方推荐 publicPath 和 webpack 配置的保持一致（除了http地址），配置一致才能正常访问其他静态资源。

上面的解释可能还是比较生硬，还是举几个例子来说明：

本例将两处 publicPath 配置成不一样的，这样更容易对比理解。

// webpack.config.js
output: {
 path: path.resolve(`./dist/`),
 filename: 'js/[name].js',
 publicPath: '/static/'
}

// api 调用 webpack-dev-server
var webpack = require('webpack');
var webpackDevServer = require('webpack-dev-server');
var config = require("./webpack.config");
var compiler = webpack(config);
var server = new webpackDevServer(compiler, {
 hot: true,
 publicPath: '/web/'
});
server.listen(8282, "0.0.0.0")

如何查看 webpack-dev-server 所有启动后的资源访问路径呢？有个简单的方法，就是访问/webpack-dev-server，本例访问截图如下：

上面的资源可以点击查看，你会发现，资源的路径都是/web/*****，所以在index.html中引入JS的路径应为/web/js/main.js，同时也能看到，style.css中的图片路径仍然为/static/img/****.png，而不是/web/。

html-webpack-plugin

这个插件的几处配置受路径配置影响，因此需要专门说明下。

template

template的路径是相对于 output.context，源码如下：

this.options.template = this.getFullTemplatePath(this.options.template, compiler.context);

因此 template 对应的文件需要放在 ouput.context 配置的目录下才能被识别。

filename

filename的路径是相对于 output.path，源码如下：

this.options.filename = path.relative(compiler.options.output.path, filename);

在 webpack-dev-server 中，则相对于 webpack-dev-server 配置的 publicPath。

若 webpack-dev-server 中的 publicPath 和 ouput.publicPath 不一致，在这种配置下使用html-webpack-plugin是有如下问题：

• 自动引用的路径仍然以 ouput.publicPath 为准，和 webpack-dev-server 提供的资源访问路径不一致，从而不能正常访问；

• 浏览 index.html 需要加上 webpack-dev-server 配置的 publicPath 才能访问（http://localhost:8282/web/）。
  

这两个问题也反推出了最方便的配置为：

• ouput.publicPath 和 webpack-dev-server 的publicPath 均配置为'/'，vue-cli 就是这种配置

• template 放在根目录，html-webpack-plugin 不用修改参数的路径，filename 采用默认值。

总结

目前就针对上面基础路径做了简单的解释说明，如有错误，请不吝指出，后续若发现其他相关路径配置，再作补充。

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!