Maison  >  Article  >  interface Web  >  Explication détaillée des étapes de packaging du projet Vue par environnement

Explication détaillée des étapes de packaging du projet Vue par environnement

php中世界最好的语言
php中世界最好的语言original
2018-04-20 14:03:401670parcourir

Cette fois, je vais vous apporter une explication détaillée des étapes de packaging du projet Vue par environnement. Quelles sont les précautions pour packaging le projet Vue par environnement. Ce qui suit est un cas pratique, prenons. un regard.

Dans le développement de projets, nos projets sont généralement divisés en version de développement, version de test, version pré et version Prod. Les environnements par défaut de Vue-cli sont uniquement dev et prod. Dans le passé, chaque fois que je voulais publier une version de test ou une version Pre, je devais modifier l'adresse API dans le code source puis la packager, ce qui était très gênant. . Ce serait parfait s'il pouvait être conditionné en fonction de différents environnements. J'ai collecté beaucoup d'informations sur Internet, et maintenant je peux packager le programme en fonction de l'environnement. Quant à savoir comment le faire, restons et voyons.

Étape 1 : Installercross-env

Exécutez la commande suivante dans le répertoire du projet pour installer cross-env , Mon IDE est webstorm. Il doit être exécuté directement dans la fenêtre Terminal de l'IDE. Il est également possible de localiser le répertoire racine du projet via le CMD de Windows ou le Terminal de Linux et d'exécuter la commande suivante.

npm i --save-dev cross-env

Étape 2 : Modifier les paramètres dans chaque environnement

Ajouter un test dans le répertoire config/ . env.js, pré.env.js. Modifiez 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"'
}

Modifiez le contenu des fichiers test.env.js et pre.env.js respectivement. suit :

'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 le Les paramètres du processus de conditionnement de plusieurs environnements nouvellement définis 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

Modifier 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 : Utilisez les paramètres de l'environnement de construction

dans webpackage.prod.conf.js pour construire/webpackage.prod.conf.js Modifier le fichier et ajustez la façon dont les constantes d'environnement sont générées.

// 个性env常量的定义
// const env = require('../config/prod.env')
const env = config.build[process.env.env_config+'Env']

Étape 6 : Ajuster build/build.js

Supprimer l'affectation de process.env.NODE_ENV et modifier 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()
//更多的其它内容,不需要做任何调整的内容 ...

Supplémentaire :

Comment vue2+webpack est empaqueté par environnement

Cette année, j'ai eu l'opportunité de travailler sur un projet d'application monopage vue2. J'ai traversé deux environnements du développement au lancement. J'exécute npm run build à la fois dans l'environnement de test et dans l'environnement officiel. 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, l'environnement de test npm run test, l'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 pour renvoyer le nom du script en cours d'exécution, tel que pretest, test, post-test, 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 :

Cas d'utilisation de Vuex dans React

Utilisation des instructions intégrées de Vue

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!

Déclaration:
Le contenu de cet article est volontairement contribué par les internautes et les droits d'auteur appartiennent à l'auteur original. Ce site n'assume aucune responsabilité légale correspondante. Si vous trouvez un contenu suspecté de plagiat ou de contrefaçon, veuillez contacter admin@php.cn