Why differentiation packaging

In some projects, this requirement may exist only in development mode, but not in production mode. In fact, this logic is easy to implement, we can do a lot of things based on the environment variable parameters. For example, you want to display different images in different modes on the page

const imgSrc = ' '
if(process.env.NODE_ENV === 'development') {// Development mode
 imgSrc = require('logoenv.png')}else{
 // Production mode
 imgSrc = require('logopro.png')}Copy the code

In development mode and production mode, though, code logic distinguishes different logic directions. PNG and Logopro. PNG file resources in the code actually exist in the package of the project after the project build is packaged and built (see this article for specific reasons), but we clearly only need logopro.png

It’s not reasonable to have unneeded resources in packages in production, but if you don’t care about performance tuning, it’s not a problem and can be ignored

Differentiated packaging

NPM run dev, NPM run serve, even in development mode, the framework actually packages the project, but we do not manually package the NPM run build. The dist folder is also not generated in the project root directory.

Second, the root of the problem is packaging. We need a way for packers (such as WebPack, Rollup, etc.) to differentiate between the dependencies or resources we specify when packaging in development mode and when manual NPM run build packaging.

solution

Vue or React projects, when our page component is referenced in the routing table, will load the other resources that it references internally. Then we can start with the route registration. We only need to register the routes that we need during local development to accomplish this purpose

The specific practices

Define two different routing profiles to import different routing profiles when packaging in different environments

1.webpack

I’m using vue3.x+@vue/ CLI here

Mainly use webpack NormalModuleReplacementPlugin this plug-in, can be intercepted when packaging reference resource file, and then meet the specified file in judgment when do special processing (replace filename) specific API documentation at tencent cloud this explanation

1.vue.config.js

const webpack = require('webpack')
module.exports = {
  configureWebpack: config= > {
    const appTarget = process.env.NODE_ENV === 'development' ? 'env' : 'pro'
    // Replace all APP_TARGET keywords in the code with appTarget variable values
    config.plugins.push(new webpack.NormalModuleReplacementPlugin(/(.*)APP_TARGET(\.*)/.function(resourse) {
        resourse.request = resourse.request.replace(/APP_TARGET/.`${appTarget}`)}))}}Copy the code

2.. env.development

NODE_ENV=development
Copy the code

3.. env.production

NODE_ENV=production
Copy the code

4. Define routers_env.js and Routers_pro. js routing configuration files 5. Introduce it where it is introduced

import routers from './routers_APP_TARGET.js'
Copy the code

2.rollup

The idea is the same as Webpack, but the implementation is slightly different, I use vue3+vite here

The main advantage is the Rollup replace plugin. Click here to see additional rollup plug-ins and documentation for vite integration

1.vite.config.js

import { defineConfig } from 'vite'
import vue from '@vitejs/plugin-vue'
import replace from "@rollup/plugin-replace"

export default defineConfig(({ command, mode }) = > {
  const config = {
    plugins: [
      vue()
    ]
  }
  if( command === 'serve'){
    config.plugins.push(replace({
      'APP_TARGET':'env'.delimiters: [' '.' ']}}))else {
    config.plugins.push(replace({
      'APP_TARGET':'pro'.delimiters: [' '.' ']}}))return config
})
Copy the code

2. Define routers_env.js and Routers_pro. js route configuration files 3. At the point of introduction

import routers from './routers_APP_TARGET.js'
Copy the code

conclusion

Other aspects can also be used flexibly, such as distinguishing between local and online third-party plug-in installations

The reason why there will be this post, mainly in the recent development of a local project document system when this demand, if the project document specification has a certain pursuit or persistent friends welcome to see my article