The project of the company uses VUE. There are two vUE scaffolds, VUe-CLI and Vite. In order to explore whether vite can be put into production, it depends on whether vite can be compared to vue-CLI after development and packaging.

The development environment

startup

The first is startup speed. Vite prides itself on the lack of packaging in the development environment. Compared to the vue-CLI package in the development environment, this is definitely a blast.

Packaging configuration

For basic configuration items, see Yang Village Chief’s article: Article 1: Prepare for 2021: VITE Engineering Practices, recommended collection Article 2: Prepare for 2021: Vite2 Project best practices

A little bit about the alias configuration, it now looks like this:

import { resolve } from 'path'

export default defineConfig({
    resolve: {alias: {src: resolve(__dirname, 'src')}}})Copy the code

Configure the base

base: '/'
Copy the code

For the time being, I don’t know what the use of this base path is, but I tested whether the path of the resource referenced after packaging is an absolute path or not. Let me know if anyone knows how to match.

Package online

It’s been a lot of fun along the way, especially the update speed. Compared to the previous vue-CLI, which had to reload every file in 20 seconds, the vite experience is really good. And then the packing encountered a lot of pits…

Static resource merge packaging issues

After executing NPM run build, all static resources, such as JS, CSS, and img, are found in assets directory. Good fellow, do not speak of martial arts. I don’t know how this will affect the project, but IT always makes me uncomfortable. Why does vue-CLI get to pack separately?

After reviewing many methods, I finally decided on a split packaging configuration method:

export default defineConfig({
    build: {assetsDir: 'static/img/'.rollupOptions: {
            output: {
                chunkFileNames: 'static/js/[name]-[hash].js'.entryFileNames: 'static/js/[name]-[hash].js'.assetFileNames: 'static/[ext]/[name]-[hash].[ext]',},},}})Copy the code

All right, this is finally neat



Packing speed problem

Vite will calculate the package size in the package, but it will take a long time to calculate the package size, so you can add a configuration item in the build to turn off the package size.

brotliSize: false
Copy the code

Image resource path reference problem

However, I found another problem, my image path is stored in data, and vue still renders it as a string intact after packaging, which is inconsistent with the IMG path configured just now, and the image can not be imported.

My solution is to put all the images in the public directory.

Since the public directory was copied to the dist directory intact after vite was packaged, I created an images directory under the images directory, and that’s fine.

I don’t know what better way to do it. Anyone who knows can tell me about it.

Problem for Tree shaking

I found that Vite takes the Tree Shaking approach, not packaging resources that are not available for use. Does that mean that when importing other component libraries, such as the Element UI, you no longer need to import them on demand? However, after testing, I found that with respect to the UI component library, without using Tree Shaking, I packaged what I imported. And there’s a little bit of a problem in this section, whether to use destruct assignment to load on demand, or to go full import. To import on demand, refer to my other article configuration: juejin.cn/post/699213…

Gzip compression

import viteCompression from 'vite-plugin-compression'

export default defineConfig({
    plugins:[
        ...,
        viteCompression({
        // Generate the compressed package gz
        verbose: true.disable: false.threshold: 10240.algorithm: 'gzip'.ext: '.gz',})]})Copy the code

I did a little background run on the packaged project using Express and found that it was the same with and without Gzip in Express. Does vite start gZIP compression by default? Have understanding of the small partners can also say.

Vite – plugins plugin

For more information about vite plug-ins, see vite 2.0 Configuration Summary

Experience summary

At this point, the Vite project is perfectly live. In terms of development experience, Vite is superior to Vue-CLI. And with the addition of some configuration items, the packaged effect can be compared to vue-CLI. At present, the ecology of Vite is still improving, and I think it can be put into production.