Detaillierte Erläuterung der zugehörigen Pfadkonfiguration in Webpack

Dieser Artikel führt Sie hauptsächlich in die relevanten Informationen zur Pfadkonfiguration in Webpack2 ein. Die Einführung im Artikel ist sehr detailliert und bietet einen gewissen Referenz- und Lernwert für alle Freunde, die sie unten lesen möchten.

Vorwort

Es gibt viele Pfadparameterkonfigurationen in Webpack2. Wenn Sie nicht wissen, warum, kann es leicht zu Verwirrung kommen Fehler machen. Dieser Artikel sammelt so viel wie möglich die Konfiguration der in Webpack2 beteiligten Pfade und versucht, sie in einfachen Worten zu erklären.

Kontext

Kontext ist das Basisverzeichnis beim Kompilieren des Webpacks, und der Einstiegspunkt (Eintrag) wird relativ zu diesem Verzeichnis gesucht.

Der Standardwert ist das aktuelle Verzeichnis. Der Standardwertcode für die Webpack-Einstellung kann lokal heruntergeladen werden:

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

process.cwd() ist das Verzeichnis wo Webpack ausgeführt wird (entspricht dem Verzeichnis, in dem sich package.json befindet).

Kontext sollte als absoluter Pfad konfiguriert werden. Wenn der Startpunkt des Eintrags src/main.js ist, können Sie Folgendes konfigurieren:

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

At Dieses Mal kann der Eintrag nicht mehr als „./src/main.js“ konfiguriert werden, da das Webpack den Startpunkt des Eintrags (main.js) relativ zum src-Verzeichnisbereich der Kontextkonfiguration und zu main.js findet befindet sich in diesem Verzeichnis, daher sollte der Eintrag als aktuelles Verzeichnis (./) konfiguriert werden.

Was macht Kontext eigentlich? Im offiziellen Dokument heißt es: „Dadurch wird Ihre Konfiguration unabhängig von CWD (aktuelles Arbeitsverzeichnis)“. Wie ist das zu verstehen? Wenn Sie beispielsweise Konfigurationsdateien separat entwickeln und erstellen, wird webpack.config im Allgemeinen im Build-Ordner abgelegt. Zu diesem Zeitpunkt muss der Eintrag nicht relativ zum Build-Verzeichnis konfiguriert werden, muss aber dennoch konfiguriert werden relativ zum Kontext konfiguriert werden, der sozusagen unabhängig vom Projektverzeichnis ist.

Es ist zu beachten, dass die Ausgabekonfigurationselemente nichts mit dem Kontext zu tun haben, einige Plug-In-Konfigurationselemente jedoch mit dem Kontext zusammenhängen, was später erläutert wird.

output

output.path

Das Verzeichnis für die Ausgabe der Paketdatei wird empfohlen Um es als absoluten Pfad zu konfigurieren (relative Pfade melden keine Fehler), ist der Standardwert derselbe wie der Standardwert des Kontexts, beide sind process.cwd().

Zusätzlich zur herkömmlichen Konfigurationsmethode können Sie auch die [Hash]-Vorlage im Pfad verwenden. Beispiel: Konfiguration:

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

Das gepackte Verzeichnis lautet wie folgt:

Der Hashwert hier ist der Hash des Kompilierungsprozesses. Wenn sich der gepackte Inhalt ändert, ändert sich auch der Hashwert. Dies kann für ein Versions-Rollback verwendet werden. Sie können es auch auf path.resolve(`./dist/${Date.now()}/`) konfigurieren, um eine kontinuierliche Integration usw. zu ermöglichen.

ouput.publicPath

Ich erinnere mich, als ich Webpack zum ersten Mal lernte, verstand ich publicPath nie ganz und dachte sogar fälschlicherweise, dass es mit output.path zusammenhängt. Dieses Konfigurationselement ist in vielen Szenarien sehr wichtig. Wenn Sie es nicht genau verstehen, können Sie es nicht flexibel verwenden.

Wie man publicPath schnell und genau versteht, lässt sich meiner Meinung nach durch die folgende Formel ausdrücken:

Endgültiger Zugriffspfad statischer Ressourcen = output.publicPath + Konfigurationspfad wie Ressourcenlader oder Plug -in

Beispiel:

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'

Der Standardwert von publicPath ist leerString, schauen wir uns andere an common Die eigentliche Bedeutung der publicPath-Konfiguration.

publicPath ist auf einen relativen Pfad eingestellt, der sich auf index.html bezieht. Beispielsweise lautet publicPath:"./dist/" der JS-Dateiname bundle.js. Gemäß der obigen Formel lautet der endgültige Pfad für den Zugriff auf JS ./dist/bundle.js. Dieser Pfad ist auch der Pfad für index.html zum Referenzieren von Bundle. js. Da sich index.html über einen relativen Pfad auf bundle.js beziehen muss, bestimmt der Speicherort von index.html die Konfiguration von publicPath. Beispielsweise befindet sich index.html im Ordner A und der veröffentlichte Pfad möchte nicht im A-Ordner abgelegt werden, sondern mit A konsistent sein. Wenn sich der Ordner auf derselben Ebene befindet, sollte er als publicPath :"../dist/" konfiguriert werden. Dies ist relativ zum Pfad von index.html, Bundle. js befindet sich im dist-Ordner der oberen Ebene. Der Vorteil relativer Pfade besteht darin, dass lokal auf sie zugegriffen werden kann. Beispielsweise funktioniert das von einigen Hybrid-APPs verwendete Dateiprotokoll definitiv nicht mit absoluten Pfaden.

publicPath wird relativ zur Protokoll-URL (//) oder http-Adresse (http://) festgelegt, z. B. publicPath:'http://wwww.qinshenxue.com/static/' Dies ist in der Entwicklungsumgebung, in der dies der Fall ist, natürlich nicht möglich wird zum Hosten von Ressourcen auf einem CDN verwendet, beispielsweise dem statischen Ressourcenserver des Unternehmens usw.

Außerdem sollte publicPath mit „/“ enden und die Konfiguration anderer Loader oder Plug-Ins sollte nicht mit „/“ beginnen.

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 采用默认值。

总结

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

Das obige ist der detaillierte Inhalt vonDetaillierte Erläuterung der zugehörigen Pfadkonfiguration in Webpack. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!