Detaillierte Erklärung der Verwendung von publicPath in Webpack

Vor kurzem habe ich ein React-Projekt basierend auf Webpack erstellt und bin auf Probleme mit output.publicPath und publicPath im Webpack-Dev-Server gestoßen. In der offiziellen Dokumentation wurden sie nicht sehr klar beschrieben, also habe ich sie selbst studiert und diesen Artikel geschrieben, um sie aufzuzeichnen.

Ausgabe

Die Ausgabeoption gibt den Speicherort der Webpack-Ausgabe an. Die wichtigeren und am häufigsten verwendeten sind path und publicPath

Ausgabepfad

Standardwert: process.cwd()
output.path gibt lediglich das Ausgabeverzeichnis an, das einem absoluten Pfad entspricht. Beispielsweise wird im Projekt normalerweise die folgende Konfiguration vorgenommen:

Ausgabe: {
 Pfad: Pfad.auflösen(__dirname, '../dist'),
}

Ausgabe.öffentlicher Pfad

Standardwert: leere Zeichenfolge Die offizielle Dokumentation erklärt publicPath als

webpack bietet eine sehr nützliche Konfiguration, mit der Sie einen Basispfad für alle Assets in Ihrem Projekt angeben können. Dieser wird publicPath genannt.

Es ist nicht klar, wie dieser Pfad angewendet werden soll ...

Tatsächlich bezieht sich der Basispfad aller hier genannten Ressourcen auf den Basispfad, wenn auf CSS-, JS-, IMG- und andere Ressourcen im Projekt verwiesen wird. Dieser Basispfad sollte in Verbindung mit dem in den spezifischen Ressourcen angegebenen Pfad verwendet werden, sodass der Zugriffspfad der gepackten Ressourcen durch die folgende Formel ausgedrückt werden kann:

Der endgültige Zugriffspfad statischer Ressourcen = output.publicPath + Ressourcenlader oder Plug-In-Konfigurationspfad

Zum Beispiel

Ausgabe.öffentlicher Pfad = "/dist/"

//Bild
Optionen:
  Name: 'img/[Name].[Erw.]?[Hash]'
}

// Der endgültige Bildzugriffspfad ist output.publicPath + 'img/[name].[ext]?[hash]' = '/dist/img/[name].[ext]?[hash]'

//js Ausgabe.Dateiname
Ausgabe: {
 Dateiname: „[name].js“
}
// Der endgültige Zugriffspfad von js ist output.publicPath + '[name].js' = '/dist/[name].js'

// Text-Extrahieren-Webpack-Plugin CSS
neues ExtractTextPlugin({
 Dateiname: „style.[chunkhash].css“
})
// Der endgültige Zugriffspfad von CSS ist output.publicPath + 'style.[chunkhash].css' = '/dist/style.[chunkhash].css'

Dieser endgültige Zugriffspfad für statische Ressourcen ist im HTML zu sehen, das nach dem Verpacken mit dem HTML-Webpack-Plugin erhalten wird. Nachdem publicPath auf einen relativen Pfad gesetzt wurde, ist der relative Pfad nach dem Erstellen relativ zu index.html. Wenn publicPath beispielsweise auf „./dist/“ gesetzt ist, lautet der Referenzpfad des gepackten js ./dist/main.js. Doch hier gibt es ein Problem. Beim lokalen Zugriff kann der relative Pfad verwendet werden, doch wenn die statischen Ressourcen auf CDN gehostet werden, kann der Zugriffspfad offensichtlich kein relativer Pfad sein. Wenn publicPath jedoch auf / gesetzt ist, lautet der Zugriffspfad nach dem Packen localhost:8080/dist/main.js, worauf lokal nicht zugegriffen werden kann.

Hier müssen Sie also den öffentlichen Pfad beim Online-Gehen manuell ändern, was nicht sehr praktisch ist, aber ich weiß nicht, wie ich das lösen soll ...

Im Allgemeinen sollte publicPath mit '/' enden und andere Loader- oder Plugin-Konfigurationen sollten nicht mit '/' beginnen.

öffentlicher Pfad im Webpack-Dev-Server

Klicken Sie hier, um die Einführung zu devServer.publicPath in der offiziellen Dokumentation anzuzeigen

Während der Entwicklungsphase starten wir mit devServer einen Entwicklungsserver für die Entwicklung. Hier wird auch ein publicPath konfiguriert. Die gepackten Dateien unter dem publicPath-Pfad können im Browser aufgerufen werden. Statische Ressourcen verwenden weiterhin output.publicPath.

Die von webpack-dev-server gepackten Inhalte werden im Speicher abgelegt. Das Stammverzeichnis dieser gepackten Ressourcen ist publicPath. Mit anderen Worten, hier legen wir den Speicherort fest, an dem die gepackten Ressourcen gespeichert sind.

Zum Beispiel:

// Angenommen, der öffentliche Pfad des devServers lautet const publicPath = '/dist/'.
// Nach dem Starten von devServer ist der Speicherort von index.html const htmlPath = `${pablicPath}index.html`
// Paketspeicherort kostet mainJsPath = `${pablicPath}main.js`

Auf das Obige kann direkt über http://lcoalhost:8080/dist/main.js zugegriffen werden.

Wenn Sie http://localhost:8080/webpack-dev-server aufrufen, können Sie den Ressourcenzugriffspfad abrufen, nachdem devServer gestartet wurde. Klicken Sie wie in der Abbildung gezeigt auf Statische Ressourcen, um zu sehen, dass der Zugriffspfad für statische Ressourcen http://localhost:8080${publicPath}index.html lautet.

HTML-Webpack-Plugin

Dieses Plugin wird verwendet, um CSS und JS zur HTML-Vorlage hinzuzufügen, wobei Vorlage und Dateiname vom Pfad beeinflusst werden, wie aus dem Quellcode ersichtlich ist

Vorlage

Funktion: Wird verwendet, um den Pfad der Vorlagendatei zu definieren

Quellcode:

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

Daher wird die Vorlage nur erkannt, wenn sie im Webpack-Kontext definiert ist. Der Standardwert des Webpack-Kontexts ist process.cwd(), der absolute Pfad des Ordners, in dem der Knotenbefehl ausgeführt wird.

Dateiname

Funktion: Ausgabe des HTML-Dateinamens, Standard ist index.html, kann direkt mit Unterverzeichnissen konfiguriert werden

Quellcode:

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

Daher ist der Pfad des Dateinamens relativ zu output.path und in webpack-dev-server relativ zum von webpack-dev-server konfigurierten öffentlichen Pfad.

Wenn der öffentliche Pfad des Webpack-Dev-Servers nicht mit output.publicPath übereinstimmt, kann die Verwendung des HTML-Webpack-Plugins dazu führen, dass auf statische Ressourcen nicht verwiesen werden kann, weil auf die statischen Ressourcen im DevServer immer noch über output.publicPath verwiesen wird, was nicht mit dem vom Webpack-Dev-Server bereitgestellten Ressourcenzugriffspfad übereinstimmt, und daher nicht normal darauf zugegriffen werden kann.

Es gibt eine Ausnahme: output.publicPath ist ein relativer Pfad. Dann können Sie auf lokale Ressourcen zugreifen.

Daher muss im Allgemeinen sichergestellt werden, dass der publicPath im devServer mit output.publicPath übereinstimmt.

endlich

Das ist alles zum Pfad in Webpack. Beim Studium des Pfads von Webpack habe ich einige fragmentarische Erkenntnisse über den Pfad wie folgt gefunden:

Die Bedeutung von Schrägstrich /

In der Konfiguration stellt / den Stammpfad der URL dar, z. B. http://localhost:8080/ in http://localhost:8080/dist/js/test.js

devServer.publicPath und devServer.contentBase

• devServer.contentBase teilt dem Server mit, woher Inhalte bereitgestellt werden sollen. Nur erforderlich, wenn Sie statische Dateien bereitstellen möchten.
• devServer.publicPath wird verwendet, um zu bestimmen, von wo aus das Paket bereitgestellt werden soll, und diese Option hat Vorrang.

Pfad im Knoten

• __dirname: gibt immer den absoluten Pfad des Ordners zurück, in dem sich das ausgeführte js befindet
• __filename: gibt immer den absoluten Pfad des ausgeführten js zurück
• process.cwd(): gibt immer den absoluten Pfad des Ordners zurück, in dem der Knotenbefehl ausgeführt wird
  

siehe

Detaillierte Erklärung der Pfade von Webpack2

Eine kurze Analyse mehrerer Dateipfade in NodeJs

Probleme mit relativen und absoluten Pfaden in Projekten

Dies ist das Ende dieses Artikels über die detaillierte Verwendung von publicPath in Webpack. Weitere relevante Inhalte zu Webpack publicPath finden Sie in früheren Artikeln auf 123WORDPRESS.COM oder in den folgenden verwandten Artikeln. Ich hoffe, dass jeder 123WORDPRESS.COM in Zukunft unterstützen wird!