Cette fois, je vais vous montrer comment packager les projets Vue par environnement. Quelles sont les précautions pour packager les projets Vue par environnement. Voici des cas pratiques, jetons un coup d'oeil.
Étape 1 : Installer cross-env
Exécutez la commande suivante dans le répertoire du projet pour installer cross-env. Mon IDE est webstorm. Vous pouvez l'exécuter directement dans la fenêtre Terminal de l'EDI. Vous pouvez également accéder au répertoire racine du projet via Windows CMD ou Linux Terminal. commande suivante.
npm i --save-dev cross-env
Étape 2 : Modifier les paramètres dans chaque environnement
Ajoutez test.env.js et pre.env.js dans le répertoire config/. Modifier le contenu dans prod.env.js Le contenu modifié est le suivant :
'use strict' module.exports = { NODE_ENV: '"production"', EVN_CONFIG:'"prod"', API_ROOT:'"/apis/v1"' }
Étudiez et modifiez respectivement le contenu des fichiers test.env.js et pre.env.js. Le contenu modifié est le suivant :
'use strict' module.exports = { NODE_ENV: '"testing"', EVN_CONFIG:'"test"', API_ROOT:'"/test/apis/train"' } 'use strict' module.exports = { NODE_ENV: '"presentation"', EVN_CONFIG:'"pre"', API_ROOT:'"/pre/apis/train"' }
Modifiez le contenu du fichier dev.env.js Le contenu modifié est le suivant. Le proxy de service est configuré dans l'environnement de développement et l'API avant API_ROOT est l'adresse du proxy configurée.
module.exports = merge(prodEnv, { NODE_ENV: '"development"', VN_CONFIG: '"dev"', API_ROOT: '"api/apis/v1"' })
Étape 3 : Modifier le fichier package.json du projet
Personnalisez le contenu des scripts dans le fichier package.json et ajoutez plusieurs processus d'empaquetage nouvellement définis pour l'environnement. Les paramètres qu'ils contiennent sont cohérents avec les ajustements précédents.
"scripts": { "dev": "webpack-dev-server --inline --progress --config build/webpack.dev.conf.js", "start": "npm run dev", "build": "node build/build.js", "build:test": "cross-env NODE_ENV=production env_config=test node build/build.js", "build:pre": "cross-env NODE_ENV=production env_config=pre node build/build.js", "build:prod": "cross-env NODE_ENV=production env_config=prod node build/build.js" },
Ici, il est préférable de définir NODE_ENV sur production, car un seul jugement de production est effectué dans utils.js et les tests personnels n'affecteront pas les paramètres API de chaque environnement. ##Étape 4 : Modifier config/index.js
Modifiez les paramètres de build dans le fichier config/index.js. Les paramètres ici seront utilisés dans build/webpackage.prod.conf.js
build:{ // Template for index.html // 添加test pre prod 三处环境的配制 prodEnv: require('./prod.env'), preEnv: require('./pre.env'), testEnv: require('./test.env'), //下面为原本的内容,不需要做任何个性 index:path.resolve(dirname,'../dist/index.html'),
. Étape 5 : Utiliser les paramètres de l'environnement de construction dans webpackage.prod.conf.js
Modifiez le fichier build/webpackage.prod.conf.js et ajustez la méthode de génération des constantes env.
// 个性env常量的定义 // const env = require('../config/prod.env') const env = config.build[process.env.env_config+'Env']
Étape 6 : Ajuster build/build.js
Supprimez l'affectation de process.env.NODE_ENV et modifiez la définition de spinner Le contenu ajusté est le suivant :
'use strict' require('./check-versions')() // 注释掉的代码 // process.env.NODE_ENV = 'production' const ora = require('ora') const rm = require('rimraf') const path = require('path') const chalk = require('chalk') const webpack = require('webpack') const config = require('../config') const webpackConfig = require('./webpack.prod.conf') // 修改spinner的定义 // const spinner = ora('building for production...') var spinner = ora('building for ' + process.env.NODE_ENV + ' of ' + process.env.env_config+ ' mode...' ) spinner.start() //更多的其它内容,不需要做任何调整的内容 ...
. Ajouté :
Comment empaqueter vue2+webpack par environnement
Cette année, j'ai eu l'opportunité de travailler sur un projet d'application monopage vue2, et j'ai traversé deux environnements du développement au lancement. J'exécute npm run à la fois dans l'environnement de test et dans l'environnement officiel. construire. Les variables de ces deux environnements sont actuellement différentes. Il semble un peu gênant de changer les variables à chaque fois lors du packaging. Plus tard, j'ai fait référence à mes collègues. Dans leurs projets, ils exécutaient différentes commandes selon l'environnement et obtenaient différents packages. Par exemple, testez l'environnement npm exécuter le test, environnement formel npm run build.
Doit être configuré dans le fichier config/prod.env.js
const target = process.env.npm_lifecycle_event; if (target == 'test') { //测试 var obj = { NODE_ENV: '"production"', //post用当前域名 API_ROOT: '""', //数据字典 API_ROOT_DICT:'"http://test.gw.fdc.com.cn"', } }else { //线上 var obj = { NODE_ENV: '"production"', //post用当前域名 API_ROOT: '""', //数据字典 API_ROOT_DICT:'"http://gw.fdc.com.cn"', } } module.exports = obj;
npm fournit une variable npm_lifecycle_event, qui renvoie le nom du script en cours d'exécution, tel que prétest, test, posttest, etc. Par conséquent, vous pouvez utiliser cette variable pour écrire du code pour différentes commandes de scripts npm dans le même fichier de script.
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 de la méthode automatisée de build mobile rem de webpack
Détails de l'utilisation des modules angulaires2 et des modules partagés Introduction
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!