Detailed explanation of how to automatically add prefix plugin after CSS3 packaging: autoprefixer

The project scaffolding built with vue-cli has already configured autoprefixer for you, and prefixes will be added automatically without any changes:

Let's take a look at some configurations involving the autoprefixer plug-in:

1. Postcss configuration is written in .postcssrc.js,

2. Browser rules are written in package.json.

3. Development environment (build/webpack.dev.conf.js) style related loaders

4. Production environment (build/webpack.prod.conf.js) style related loaders

The above configuration settings do not need to be configured by yourself, as they have been configured when the cli scaffolding environment was built.

Both the development environment and production environment of vue-cli use postcss, and the configuration is the same

There is a problem here. Some bloggers on the Internet said that the CSS prefixes before and after the project is packaged are inconsistent:

--Add style to img under app.vue

img{
 display: flex;
 transform: translateX(200px)
}

--The style of img before packaging (i.e. development environment)

--The style of img after packaging (i.e. production environment)

From the above, it can be seen that the CSS prefixes of the elements before and after packaging are inconsistent.

Then the solution given:

As can be seen from the above, both the development environment and the production environment of vue-cli use postcss, and the configuration is the same, so why are the CSS prefixes of the elements before and after packaging inconsistent?

Locking Issues

We can analyze and compare the two files build/webpack.dev.conf.js and build/webpack.prod.conf.js. The only things that affect CSS are the loader that handles the style in the module and the plug-in that handles CSS. From the above, we can see that the loader of postcss that affects the prefix is ​​consistent in the two links, so we can know that the problem lies in the plug-in that handles CSS.

After investigation, it was found that there were two more css processing plug-ins in the webpack.prod.conf.js configuration, as follows

ExtractTextPlugin is used to extract and separate CSS files. It will not affect the CSS prefix. If it is excluded, the problem will be locked on the OptimizeCSSPlugin plugin. Going a step further, when we commented out the OptimizeCSSPlugin plug-in and then packaged and tested it, we found that the CSS prefixes of the development environment and the production environment were the same. That's it! ! !

Let's go to the npm official website and search for this guy

https://www.npmjs.com/package/optimize-css-assets-webpack-plugin

This is a plugin for optimizing and compressing CSS code, but it is disappointing that there is very little documentation.

But we noticed one key sentence:

This product relies on cssnano, which is also used to optimize the processing of CSS formats, prefixes, etc. There is also an autoprefixer configuration parameter, go to its official website https://cssnano.co/ to find autoprefixer:

The translation here is: Remove unnecessary prefixes according to browsers options. Note that by default it does not add new prefixes to CSS files, which clears up our problem. It turns out that the plugin's autoprefixer (which should be true by default) removes prefixes it deems unnecessary, while postcss's autoprefixer adds the browser-wide prefix we set, thus perfectly solving the conflict.

Solving the problem

Add autoprefixer: false to the cssProcessorOptions property of the OptimizeCSSPlugin plugin in the build/webpack.prod.conf.js file to disable it and avoid conflicts

Above code:

new OptimizeCSSPlugin({
  cssProcessorOptions: config.build.productionSourceMap
   ? { safe: true, map: false, autoprefixer: false }
   : { safe: true, autoprefixer: false}
 }),

in conclusion

Finally, let’s look at the css prefixes from our dev and build, which should be consistent:

The cause of the problem is: OptimizeCSSPlugin depends on cssnano, and cssnano also has an autoprefixer configuration parameter, which is used to delete unnecessary prefixes (it will mistakenly delete necessary prefixes in some browsers), which conflicts with the autoprefixer effect of postcss, so it is disabled. The packaged one now matches the prefix of the browser range we set.

According to the configuration of the blogger on the Internet, the prefixes of the development environment and the test environment can indeed be made exactly the same, but after checking, I found that it is not necessary. The premise of the problem is not inconsistent prefixes. That configuration only prevents the prefixes that do not match the current browser from being displayed. The styles are still in effect. I personally think that if it is not a particularly big problem, there is no need to change the configuration.

The above is the full content of this article. I hope it will be helpful for everyone’s study. I also hope that everyone will support 123WORDPRESS.COM.