Cette fois, je vous apporte une explication détaillée des étapes permettant à vue-cli+webpack de traiter les ressources statiques et l'empaquetage du webpack. Quelles sont les précautions pour que vue-cli+webpack traite les ressources statiques et le webpack. emballage. Voici des cas pratiques, jetons un coup d’œil.
Les pièges du packaging webpack via Vue-cli
L'échafaudage construit par Vue-cli pour le projet Vue est en effet très pratique, mais l'empaquetage est simple. Une page blanche apparaît ou la ressource statique correspondante ne peut pas être chargée.
Je l'ai résolu en changeant le AssetsPublicPath de index.js sous project/config en './' et en le transformant en chemin relatif.
cd vue demo npm run dev //运行程序 npm run bulid //webpack打包
Traitement des ressources statiques
Vous remarquerez peut-être que dans les projets qui combinent vue-cli avec webpack, nous avons généralement deux chemins de deux ressources statiques : src/assets et static/ Quelle est la différence entre elles ? Cet article présente principalement comment vue-cli et webpack sont combinés pour gérer les ressources statiques. L'éditeur pense que c'est plutôt bien, je vais donc le partager avec vous maintenant et le donner comme référence. Suivons l'éditeur et jetons un œil. J'espère que cela pourra aider tout le monde.
Ressources packagées
Afin de répondre à cette question, nous devons d'abord comprendre comment Webpack gère les ressources statiques. Dans le composant *.vue, tous les modèles et modules CSS sont analysés par vue-html-loader et css-loader pour trouver l'URL du chemin.
Par exemple, en <img src"./logo.png">
et en arrière-plan <a href="http://www.php.cn/wiki/892.html" target="_blank">arrière-plan<code><a href="http://www.php.cn/wiki/892.html" target="_blank">background</a>: url(./logo.png)
: url(./logo.png), "./logo.png" est un chemin relatif et sera chargé en tant que dépendance par Webpack.
Mais comme logo.png n'est pas JavaScript, donc s'il est considéré comme une fleur dépendante, nous devons l'analyser via le chargeur d'URL et le chargeur de fichiers. Ce modèle a déjà configuré le chargeur correspondant pour vous, vous n'avez donc généralement pas à vous soucier des problèmes de déploiement de chemin relatif.
Même si ces ressources peuvent être intégrées/copiées/renommées pendant le processus de construction, elles constituent toujours une partie importante du code source. C'est pourquoi nous vous recommandons de placer les ressources statiques dans un dossier /src séparé, comme les autres dossiers de ressources.
En fait, vous n'êtes pas obligé de tous les mettre dans /src/assets, vous pouvez les organiser et les utiliser en fonction de modules/composants. Par exemple, vous pouvez placer n'importe quel composant dans son propre répertoire et stocker des ressources statiques dans ce répertoire.
Règles d'introduction des ressources
Les chemins relatifs, tels que ./assets/logo.png seront analysés en dépendances de module. Ils seront remplacés par une URL générée automatiquement en fonction de la configuration de sortie de votre Webpack.
Un chemin sans préfixe, tel que assets/logo.png, est identique à un chemin relatif et est échappé vers ./assets/logo.png
Un chemin avec un préfixe ~ . ~ est considéré comme une demande de module, de la même manière que <a href="http://www.php.cn/wiki/136.html" target="_blank">require<code><a href="http://www.php.cn/wiki/136.html" target="_blank">require</a>('some-module/image.png')
('some-module/ image .png'). Chemin racine, tel que /assets/log.png
Obtenir le chemin de la ressource en JavaScript
computed: { background () { return require('./bgs/' + this.id + '.jpg') } }
Ce chemin de la ressource sera également fichier- Le chargeur traite et renvoie le chemin traité. Et Webpack chargera toutes les images du répertoire bgs en même temps.
Ressources statiques « réelles »
En revanche, aucun des fichiers en static/ ne sera traité par Webpack. Ils seront copiés directement dans le dossier cible et des chemins absolus doivent être utilisés pour référencer ces fichiers.
Je pense que vous maîtrisez la méthode après avoir lu le cas dans cet article. Pour des informations plus intéressantes, veuillez prêter attention aux autres articles connexes sur le site Web chinois de php !
Lecture recommandée :
Explication détaillée des étapes d'utilisation du traitement d'image PHPThumb
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!