Webpack “OTS parsing error” lädt Schriften

Meine Webpack-Konfiguration gibt an, dass fonts mithilfe von ” url-loader geladen werden sollen. Wenn ich versuche, die Seite mithilfe von Chrome anzuzeigen, erhalte ich folgende Fehlermeldung:

 OTS parsing error: invalid version tag Failed to decode downloaded font: [My local URL] 

Die relevanten Teile meiner Konfiguration sehen so aus:

 { module: { loaders: [ // ... { test: /\.scss$/, loaders: ['style', 'css?sourceMap', 'autoprefixer', 'sass?sourceMap'], }, { test: /images\/.*\.(png|jpg|svg|gif)$/, loader: 'url-loader?limit=10000&name="[name]-[hash].[ext]"', }, { test: /fonts\/.*\.(woff|woff2|eot|ttf|svg)$/, loader: 'file-loader?name="[name]-[hash].[ext]"', } ], }, } 

Es passiert nicht in Safari, und ich habe Firefox nicht ausprobiert.

In der Entwicklung webpack-dev-server ich Dateien über webpack-dev-server , in der Produktion werden sie auf Platte geschrieben und nach S3 kopiert; In beiden Fällen bekomme ich das gleiche Verhalten in Chrome.

Dies passiert auch bei größeren Bildern (größer als die 10-KB-Grenze in der Image Loader-Konfiguration).

TL; DR Verwenden Sie absolute Pfade zu Ihren Assets (einschließlich Ihres vollständigen Hostnamens), indem Sie Ihren output.publicPath zB auf ” http://example.com/assets/ ” setzen.

Das Problem

Das Problem besteht darin, dass URLs in Chrome aufgetriggers werden, wenn sie von einem dynamisch geladenen CSS-Blob analysiert werden.

Wenn Sie die Seite laden, lädt der Browser Ihre Webpack-Paket-JavaScript-Datei, die (wenn Sie den style-loader ) auch eine Base64-codierte Kopie Ihres CSS enthält, die in die Seite geladen wird.

Screenshot des eingebetteten CSS in Chrome DevTools So sieht es in Chrome DevTools aus

Das ist gut für alle Bilder oder Fonts, die als Daten-URIs in das CSS codiert sind (dh der Inhalt der Datei ist in das CSS eingebettet), aber für Assets, die von URL referenziert werden, muss der Browser die Datei finden und abrufen.

Standardmäßig verwendet der file-loader (an den url-loader für große Dateien delegiert) relative URLs für Referenz-Assets – und das ist das Problem!

Von Webpack generierte relative URLs Dies sind die URLs, die standardmäßig vom file-loader generiert werden – relative URLs

Wenn Sie relative URLs verwenden, triggers Chrome sie relativ zur enthaltenen CSS-Datei auf. Normalerweise ist das in Ordnung, aber in diesem Fall lautet die enthaltene Datei blob://... und alle relativen URLs werden auf die gleiche Weise referenziert. Das Endergebnis ist, dass Chrome versucht, sie aus der übergeordneten HTML-Datei zu laden, und am Ende versucht, die HTML-Datei als Inhalt der Schriftart zu analysieren, was offensichtlich nicht funktioniert.

Die Lösung

Erzwinge, dass der file-loader absolute Pfade einschließlich des Protokolls (“http” oder “https”) verwendet.

Ändern Sie Ihre Webpack-Konfiguration so, dass sie Folgendes enthält:

 { output: { publicPath: "http://localhost:8080/", // Development Server // publicPath: "http://example.com/", // Production Server } } 

Jetzt werden die URLs, die es generiert, wie folgt aussehen:

Bildbeschreibung hier eingeben Absolute URLs!

Diese URLs werden von Chrome und allen anderen Browsern korrekt analysiert.

Verwenden von extract-text-webpack-plugin

Es ist erwähnenswert, dass Sie dieses Problem nicht haben, wenn Sie Ihr CSS in eine separate Datei extrahieren, da sich Ihr CSS in einer korrekten Datei befindet und URLs korrekt aufgetriggers werden.

Wie hier von @mcortesi angenommen, wenn Sie die sourceMaps aus der css loader Abfrage löschen, wird die CSS ohne Verwendung von Blobs erstellt und die Daten URLs werden geparst

Für mich war das Problem mein Regex-Ausdruck. Das Folgende hat den Trick gemacht, Bootstrap funktionieren zu lassen

  { test: /\.(woff|ttf|eot|svg)(\?v=[a-z0-9]\.[a-z0-9]\.[a-z0-9])?$/, loader: 'url-loader?limit=100000' }, 

Wie bei @ user3006381 oben war mein Problem nicht nur relative URLs, sondern das Webpack platzierte die Dateien so, als wären sie Javascript-Dateien. Ihr Inhalt war im Grunde alles:

 module.exports = __webpack_public_path__ + "7410dd7fd1616d9a61625679285ff5d4.eot"; 

im Fonts-Verzeichnis anstelle der echten Fonts und die Font-Dateien befanden sich im Ausgabeordner unter Hash-Codes. Um dies zu beheben, musste ich den Test auf meinem Url-Loader (in meinem Fall mein Bildprozessor) ändern, um den fontsordner nicht zu laden. Ich musste output.publicPath in webpack.config.js als @ will-madden notes in seiner ausgezeichneten Antwort setzen.

Ich habe das gleiche Problem erlebt, aber aus verschiedenen Gründen.

Nachdem Will Maddens Lösung nicht weiterhelfen konnte, versuchte ich jede alternative Lösung, die ich über die Intertubes finden konnte – auch vergebens. Als ich weiter nachforschte, öffnete ich zufällig eine der fraglichen Font-Dateien. Der ursprüngliche Inhalt der Datei wurde irgendwie von Webpack überschrieben, um eine Art Konfigurationsinformation aufzunehmen, wahrscheinlich aus dem vorherigen Basteln mit dem Datei-Loader. Ich ersetzte die beschädigten Dateien durch die Originale, und voilà, die Fehler verschwanden (für Chrome und Firefox).

Ich weiß, dass dies nicht die exakte Frage von OPs beantwortet, aber ich kam hier mit dem gleichen Symptom, aber einer anderen Ursache:

Ich hatte die .scss-Dateien von Slick Slider wie folgt enthalten:

 @import "../../../node_modules/slick-carousel/slick/slick.scss"; 

Bei näherer Betrachtung stellte sich heraus, dass es versuchte, die Schriftart von einem ungültigen Ort ( /assets/css/fonts/slick.woff ) zu /assets/css/fonts/slick.woff , so wie es vom Stylesheet referenziert wurde.

Am Ende habe ich einfach die Datei /font/ in meine assets/css/ kopiert und das Problem wurde für mich getriggers.

Da du url-loader :

Der URL-Loader funktioniert wie der Datei-Loader, kann jedoch eine DataURL zurückgeben, wenn die Datei kleiner als ein Byte-Limit ist.

Eine andere Lösung für dieses Problem wäre, das Limit so hoch zu setzen, dass die Font-Dateien als DataURL enthalten sind, zum Beispiel auf 100000 was mehr oder weniger 100Kb :

 { module: { loaders: [ // ... { test: /\.scss$/, loaders: ['style', 'css?sourceMap', 'autoprefixer', 'sass?sourceMap'], }, { test: /images\/.*\.(png|jpg|svg|gif)$/, loader: 'url-loader?limit=10000&name="[name]-[hash].[ext]"', }, { test: /\.woff(\?v=\d+\.\d+\.\d+)?$/, use: 'url-loader?limit=100000&mimetype=application/font-woff', }, { test: /\.woff2(\?v=\d+\.\d+\.\d+)?$/, use: 'url-loader?limit=100000&mimetype=application/font-woff', }, { test: /\.ttf(\?v=\d+\.\d+\.\d+)?$/, use: 'url-loader?limit=100000&mimetype=application/octet-stream', }, { test: /\.eot(\?v=\d+\.\d+\.\d+)?$/, use: 'file-loader', }, { test: /\.svg(\?v=\d+\.\d+\.\d+)?$/, use: 'url-loader?limit=100000&mimetype=image/svg+xml', }, ], }, } 

Immer berücksichtigen, auf was die Grenzwertnummer steht:

Byte-Limit für Inline-Dateien als Daten-URL

Auf diese Weise müssen Sie nicht die gesamte URL der Assets angeben. Das kann schwierig sein, wenn Sie möchten, dass Webpack nicht nur von localhost aus antwortet.

Nur eine letzte Überlegung, diese Konfiguration wird nicht für die Produktion empfohlen. Dies ist nur für die Entwicklungs-Leichtigkeit.

Wenn Sie Angular verwenden , müssen Sie überprüfen, ob Sie sicher sind

  

Tag kommt vor Ihrem Stylesheet-Bundle. Ich habe meinen Code von diesem geändert:

    

zu diesem:

    

und das Problem wurde behoben. Danke an diesen Beitrag zum Öffnen meiner Augen.

Ab 2018

use MiniCssExtractPlugin

für Webpack (> 4.0) wird dieses Problem lösen.

https://github.com/webpack-contrib/mini-css-extract-plugin

Die Verwendung von extract-text-webpack-plugin in der akzeptierten Antwort wird NICHT für Webpack 4.0 empfohlen.