This is the 22nd day of my participation in the August Wen Challenge.More challenges in August

At the end of the last article, we used a command-line tool to work with CSS, but if there are many places (files) in the project that use CSS, and those CSS need to be prefixed by the browser, then it is not practical to use the tool every time you go to the command line. In this case, we can use WebPack to make webPack use PostCSS to add browser prefixes to CSS styles that need to add browser prefixes when loading CSS files, and then let CSS-Loader process them after conversion.

It is important to note that styles in the current test.css file do not take effect in the project because the test.css file has not been used anywhere in the project. Let’s start by using this file in our project. There are two options: one is to import test. CSS into the index.css file, and the other is to cut the contents of test. CSS directly into the index.css file. You might think that importing directly (the first method here) would be better, but there are problems with handling this, which we’ll talk about later. Let’s take the second method first (cut the contents of test.css directly to index.css) :

Index.css is introduced in component.js (the entry file for the project is main.js, which is already introduced in main.js) :

So running the project will also deal with the style code in index.css.

But there are styles that involve adding browser prefixes (for example: Fullscreen, user-select). By default, NPM run build is not prefixed by the browser, which can be seen in the browser:

However, we need to prefix styles with browsers, so how do we do that?

We can go to the webpack configuration file (in this case, wk.config.js), modify the CSS file matching rules, use the postCSS tool before using csS-loader processing, then how to use the PostCSS tool processing? At this point, we need another loader called postCSs-loader. Postcss-loader will automatically find the postCSS tool, and then use the postCSS tool to process the style, then the CSS -loader, style-loader processing, so the final generated style will have a browser prefix.

There is no postCSS-loader in the project yet, so let’s install it first:

npm install postcss-loader -D
Copy the code

Remember, the purpose of using postCSS-Loader is so that we can use PostCSS in webpack. (Every time we install a tool, we need to know what the tool does.)

After installing postCSS-loader, modify the matching rule of CSS file and add postCSs-loader at the end of the array corresponding to the use attribute, as shown in the following figure:

Then after such configuration will really do processing? To verify this, run the NPM run build command to compile the project code, and then go to the browser page. After the page is refreshed, it looks like this:

As you can see, the browser prefix has not been added, which means that the current PostCSS is not in effect. Why should that be? Postcss-loader = postCSs-loader = postCSs-loader = postCSs-loader = postCSs-loader = postCSs-loader The reason is simple: PostCSS itself has to rely on other plug-ins to add a prefix, but we haven’t told PostCSS which plug-ins to rely on yet, so it won’t work. Therefore, we modify the configuration as follows:

use: [
  // Notice the execution order (bottom up, right to left, back to front)
  'style-loader'.'css-loader',
  {
    loader: 'postcss-loader'.options: {
      postcssOptions: {
        plugins: [
          require('autoprefixer']}}}],Copy the code

We change the “postCSS-loader” string to UseEntry object (in this article we have discussed the use of CSS-Loader and the Rule configuration in Webpack). The loader and Options properties are set in the. The loader property is set to postCSs-loader, which means postCSs-loader is loaded. We also need to pass some parameters to tell loader which plug-in to load, so we need to set the options property. The value of the options property is passed to loader. This property corresponds to another object. In this object, you really start to configure the plug-ins that PostCSS depends on. The postcssOptions object has a plugins property that corresponds to an array (why is it an array? We can put multiple plugins in the array, because the plugin we need to rely on is Autoprefixer, so we can use require to import it.

To summarize the configuration changes above, when using postCSs-Loader, tell it to rely on autoprefixer when using PostCSS.

Now, we run the NPM run build command again to package the code, and then go to the browser page. The page is refreshed and looks like this:

As you can see, the :fullscreen CSS pseudo-class and the user-select CSS property have been prefixed by the browser. As you can see, the current postcss tool works with the autoprefixer plugin. This means that any CSS written in the project will not need to be prefixed by the browser, because postCSS has been configured to load autoprefixer with postCSS-loader. Automatically add browser prefixes to CSS styles when needed.

Of course, we can also try to modify the query criteria in the.browserslistrc file and repackage it to see the style effect:

After changing the market share of the browser to greater than 1% to greater than 0.1% (meaning that the conditions are broader and more browsers need to be adapted), we run NPM Run Build, and then go to the browser page. After the page is refreshed, the effect is as follows:

And as you can see, as we adapt to more browsers, this time the TRANSITION CSS property also has a browser prefix. (All browsers support Transition, so you don’t need to add a browser prefix.)

That’s the process of adding browser prefixes in WebPack. It is important to understand the role of the individual packages installed throughout the process and the relevant configuration in the WebPack configuration file (in this case, wk.config.js).