Webpack «Erreur d’parsing OTS» chargement des fonts

Mon webpack config spécifie que les fonts doivent être chargées avec url-loader , et lorsque j’essaie d’afficher la page avec Chrome, j’obtiens l’erreur suivante:

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

Les parties pertinentes de ma configuration ressemblent à ceci:

 { 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]"', } ], }, } 

Cela ne se produit pas dans Safari et je n’ai pas essayé Firefox.

En développement, je sers des fichiers via webpack-dev-server , en production ils sont écrits sur disque et copiés sur S3; Dans les deux cas, j’obtiens le même comportement dans Chrome.

Cela se produit également pour les images plus grandes (supérieure à la limite de 10 Ko dans la configuration du chargeur d’images).

    TL; DR Utilisez des chemins d’access absolus à vos actifs (y compris votre nom d’hôte complet) en définissant votre output.publicPath sur ” http://example.com/assets/ ” par exemple.

    Le problème

    Le problème est la façon dont les URL sont résolues par Chrome lorsqu’elles sont analysées à partir d’un blob CSS chargé dynamicment.

    Lorsque vous chargez la page, le navigateur charge le fichier JavaScript de l’entrée de l’ensemble Webpack, qui (lorsque vous utilisez le style-loader ) contient également une copie codée en Base64 de votre CSS, qui est chargée dans la page.

    Capture d'écran de CSS intégré dans Chrome DevTools Voici à quoi cela ressemble dans Chrome DevTools

    C’est bien pour toutes les images ou les fonts qui sont encodées dans le CSS en tant qu’URI de données (le contenu du fichier est incorporé dans le CSS), mais pour les ressources référencées par URL , le navigateur doit rechercher et récupérer le fichier.

    Désormais, par défaut, le file-loader (auquel les delegates de l’ url-loader délèguent les fichiers volumineux) utilisera les URL relatives pour référencer les ressources – et c’est le problème!

    URL relatives générées par Webpack Ce sont les URL générées par file-loader par défaut – URL relatives

    Lorsque vous utilisez des URL relatives, Chrome les résoudra par rapport au fichier CSS contenant. Normalement, c’est bien, mais dans ce cas le fichier contenant est à blob://... et toutes les URL relatives sont référencées de la même manière. Le résultat final est que Chrome tente de les charger à partir du fichier HTML parent et finit par essayer d’parsingr le fichier HTML en tant que contenu de la police, ce qui ne fonctionnera évidemment pas.

    La solution

    Force le file-loader de file-loader à utiliser des chemins absolus incluant le protocole (“http” ou “https”).

    Changez votre configuration webpack pour inclure quelque chose d’équivalent à:

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

    Maintenant, les URL générées ressembleront à ceci:

    entrer la description de l'image ici URL absolues!

    Ces URL seront correctement analysées par Chrome et tous les autres navigateurs.

    Utiliser extract-text-webpack-plugin

    Il est important de noter que si vous extrayez votre fichier CSS dans un fichier distinct, vous ne rencontrerez pas ce problème car votre fichier CSS se trouvera dans un fichier approprié et les URL seront correctement résolues.

    Comme indiqué ici par @mcortesi, si vous supprimez les sourcesMaps de la requête css loader, le css sera construit sans utiliser de blob et les URL de données seront analysées correctement.

    Pour moi, le problème était mon expression rationnelle. Le ci-dessous a fait le tour pour faire fonctionner bootstrap

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

    Comme avec @ user3006381 ci-dessus, mon problème n’était pas seulement les URL relatives, mais ce Webpack plaçait les fichiers comme s’ils étaient des fichiers javascript. Leurs contenus étaient tous fondamentalement:

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

    dans le répertoire des fonts au lieu des fonts réelles et les fichiers de fonts étaient dans le dossier de sortie sous les codes de hachage. Pour résoudre ce problème, j’ai dû modifier le test sur mon url-loader (dans mon cas, mon processeur d’image) pour ne pas charger le dossier des fonts. Je devais toujours définir output.publicPath dans webpack.config.js en tant que @ will-madden notes dans son excellente réponse.

    J’ai rencontré le même problème, mais pour des raisons différentes.

    Après que la solution de Will Madden n’a pas aidé, j’ai essayé toutes les solutions que j’avais pu trouver via les Intertubes, mais en vain. En explorant plus avant, il m’est arrivé d’ouvrir un des fichiers de fonts en question. Le contenu original du fichier avait en quelque sorte été écrasé par Webpack pour inclure des informations de configuration, probablement issues d’un bricolage préalable avec le chargeur de fichiers. J’ai remplacé les fichiers corrompus par les originaux, et voilà, les erreurs ont disparu (pour Chrome et Firefox).

    Je sais que cela ne répond pas à la question exacte des OP mais je suis venu ici avec le même symptôme mais une autre cause:

    J’ai eu les fichiers .scss de Slick Slider inclus comme ceci:

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

    En y /assets/css/fonts/slick.woff plus près, il s’est avéré qu’il essayait de charger la police à partir d’un emplacement non valide ( /assets/css/fonts/slick.woff ), comme il l’a été depuis la feuille de style.

    J’ai fini par copier le fichier /font/ vers mes assets/css/ et le problème a été résolu pour moi.

    Depuis que vous utilisez url-loader :

    Le chargeur d’URL fonctionne comme le chargeur de fichiers, mais peut renvoyer une DataURL si le fichier est plus petit qu’une limite d’octet.

    Donc, une autre solution à ce problème serait de rendre la limite suffisamment élevée pour que les fichiers de fonts soient inclus en tant que DataURL, par exemple à 100000 qui sont plus ou moins 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', }, ], }, } 

    Tout en tenant compte de ce que représente le nombre limite:

    Limite d’octet aux fichiers en ligne en tant qu’URL de données

    De cette façon, vous n’avez pas besoin de spécifier l’URL complète des ressources. Ce qui peut être difficile lorsque vous voulez que Webpack ne réponde pas uniquement à localhost.

    Une dernière considération, cette configuration n’est PAS RECOMMANDÉE pour la production. C’est juste pour la facilité de développement.

    Si vous utilisez Angular, vous devez vérifier que votre

      

    tag vient avant votre paquet de feuille de style. J’ai changé mon code de ceci:

        

    pour ça:

        

    et le problème a été résolu. Merci à ce post pour m’ouvrir les yeux.

    À partir de 2018,

    use MiniCssExtractPlugin

    pour Webpack (> 4.0) résoudra ce problème.

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

    Utiliser extract-text-webpack-plugin dans la réponse acceptée n’est PAS recommandé pour Webpack 4.0+.