This is the 20th day of my participation in the August Text Challenge.More challenges in August

In order to introduce a loader called postCSS-loader, let’s first talk about some necessary front-end knowledge.

1. Browser compatibility

  • Let’s think about a problem: development, browser compatibility problem, how should we solve and deal with?

    • Of course, the question is very general, and by compatibility I don’t mean screen size adaptation;
    • By compatibility, I meanFeatures supported for different browsers (different versions): for instance,cssCharacteristics,jsCompatibility between syntax, some browsers support and some browsers don’t;

  • We know there are tons of browsers out there:

    • There areChorme,Safari,IE,Edge,Chrome for Android,UC Browser,QQ BrowserAnd so on;
    • What is their market share? Are we going to accommodate them?

  • In many scaffolding configurations, you can see configuration information similar to this:

> 1%
last 2 versions
not dead
Copy the code

How do you solve this compatibility problem?

In fact, thanks to the development of front-end engineering, it is now much easier to deal with this problem because there are tools available to help us deal with features. For example, a CSS property called user-select may not be supported by all browsers. In order for all browsers to support this property, we may prefix it (or even use CSS polyfill for special processing). Do we need to add the prefix manually? Of course not, because there are already tools like Autoprefixer that help you automatically add browser prefixes. However, whether it is necessary to add a browser prefix depends on the specific situation. For example, if a feature only needs to be adapted to some browsers that support the feature, there is no need to add a prefix, otherwise the code will increase, and users will download a larger package. Therefore, it is not certain whether you need to use the autoprefixer tool to add prefixes during adaptation. Similarly, some JS features may or may not be converted using Babel, depending on which browser we want to adapt to. If the browser you want to adapt to needs a prefix then do so, if it doesn’t need a prefix then don’t.

So, before deciding whether or not to adapt the target browser, one thing we need to know is which browsers the project supports. You might want to list all the browsers you want to support. But that’s not a good list, because there are so many browsers and so many different versions. So what do we do? How do you tell it which browsers are supported in your current project?

You’ve probably seen this configuration in many scaffolders before (e.g. vue3’s.browserslistrc file or the “browserslist” item in react’s package.json file) :

> 1%
last 2 versions
not dead
Copy the code

These configurations are really just criteria for tools (Autoprefixer, Babel, etc.) to use to tell them which browsers I want to adapt to now.

For example, > 1% in the above configuration indicates that the browser has a market share of more than 1%. For Autoprefixer, in these browsers, if there is a need for a browser prefix, it is added, if there is no need for a prefix, it is not added. For Babel, these browsers don’t need to convert if they support a feature, and convert if they don’t (or polyfill some features).

So where do you get data on browser market share and so on? There must be a more authoritative, professional place to do statistics on browser information.

2. Browser market share

  • Where can I find the browser market share?
    • One of the most useful, authoritative sites, and one of the sites that our tools often look up is Caniuse;
    • The query address is caniuse.com/usage-table

3. Knowbrowserslisttool

Remember, the browser information such as market share of the browser retrieved from this site is eventually used by many tools in the project (such as autoprefixer, Babel, PostCSS-PRESET -env, etc.). Therefore, we’d better have another tool dedicated to sharing this browser data, browserslist. The browserslist tool is responsible for helping us query the browser information that matches the current criteria and sharing the results with all tools.

  • How can we be incssCompatibility andjsSharing under compatibility what are the compatibility conditions of our configuration?
    • Is when we set a condition: > 1%;
    • What we’re saying is CSS needs to be compatible with more than 1% of the browser market, JS needs to be compatible with more than 1% of the browser market;
    • If we are used to achieve this compatibility, such as PostCSS-Preset -env, Babel, autoprefixer, etc
  • How can they share our configuration?
    • The answer is Browserslist;
  • BrowserslistWhat is?BrowserslistIs aBetween different front-end tools (examples below)And share theTarget browser andNode.jsVersion Configuration;
    • Autoprefixer
    • Babel
    • postcss-preset-env
    • eslint-plugin-compat
    • stylelint-no-unsupported-browser-features
    • postcss-normalize
    • obsolete-webpack-plugin

Each of the seven tools needs to use Browserslist to determine what results to convert to.

Therefore, the Browserslist tool is very important for our engineering projects, which is why it is available in both vue and React projects. And now when we talk about Webpack, we have to talk about this thing.

4. Browser query process

  • We could write a configuration like this:
> 1%
last 2 versions
not dead
Copy the code

  • These tools then retrieve browser information based on our configuration to determine whether compatibility support is required:

    • A conditional query usescaniuse-liteTool. The data for this tool comes fromcaniuseOn the website of;

Where does the browserslist tool come from to help us with our queries once we’ve written our rules? The answer is Caniuse, but when you look it up on Caniuse, it doesn’t mean that browserslist is a tool that sends a web request to Caniuse. In fact, caniuse provides a tool called Caniuse-Lite that browserslist uses to query. Such as in vue3 scaffolding node_modules/browserslist/index. The beginning of the js file you can see it the require caniuse – lite, The result is a small tool called Caniuse-Lite that uses the criteria we pass in to help us search for a matching browser.

Let’s demonstrate the use of the browserslist tool. To use Browserslist, you have to install its package first, but we can see if Browserslist was installed when we installed some other webPack stuff, and we can see that browserslist was installed. So we don’t need to reinstall it here. In addition, node_modules/. Bin should also have browserslist executables. So, here’s what we can do: Run the following command from the terminal:

npx browserslist "> 1%, last 2 versions, not dead"
Copy the code

If you run this command on MacOS, you should see a list of browsers that match the criteria entered in the command directly on the terminal. That means that when we do things like CSS features and JS features later, we’ll be targeting those browsers. However, running the above command on A Windows system does not currently output anything on the terminal (it was possible before). Instead, a file named 1% is generated in the current directory. The contents of the file are also different from those displayed on MacOS. We don’t have to worry about this (because the whole point of running this command is just to show that browserslist really does help us query to the browser). We can also create a new.browserslistrc file in our project directory and write our query criteria in it. NPX Browserslist will automatically read the query conditions in the configuration file (.browserslistrc or package.json) and output the results. Modify the query conditions in the.browserslistrc file. Execute NPX Browserslist again, and you’ll see different results.

But in real development, instead of using Browserslist on the command line, we configure Browserslist to be used for sharing (we automatically read the configuration file when we need it somewhere in the project, and then look up the browser based on the configuration). So how do you write this configuration file? We’ll talk about that later. Here’s one more thing about the relationship between the conditions in the above command (intersection, union, not).

  • If not, there is a default:

  • Now that we’ve written multiple conditions, what are the relationships between the conditions?

Ok, so let’s talk about how to write conditions in a Browserslist configuration if you want to share them across multiple tools. There are two methods of programming. (Choose one of them. Do not use both of them. (Browserslist: XXX contains both. Browserslistrc and package.json with browsers) :

  1. inpackage.jsonAdd to file"browserslist"Field, corresponding to an array, array to write a condition;
  2. new.browserslistrcFile in which to write conditions;

Rc in.browserslistrc should refer to the Runtime compiler, which means that other tools will read the file when it is compiled at runtime.

4.1 browserslistConfiguration Writing Mode 1 Example:

When you write the configuration shown above and use tools like Babel or autoprefixer in your project, you automatically go to the browserslist array to look up these conditions. Then use the caniuse-Lite widget to find out which browsers to use.

The conditions in the figure above are union relations. If you want to set an intersection, you can write:

Run the NPX browserslist command in both formats, and you’ll see different output:

The output of the union writing method is as follows:

The output of the writing method of intersection:

4.2 browserslistConfiguration Writing Mode 2 Example:

Create a new.browserslistrc file in your project directory and enter the conditions directly. A newline means take the union. If you want to take an intersection, you can write it like this:

Run the NPX browserslist command in both formats, and you’ll see different output:

The output of the union writing method is as follows:

The output of the writing method of intersection:

Of course, if neither option is used, the default configuration will be > 0.5%, last 2 Versions, Firefox ESR, not Dead, as mentioned above.

So that’s a quick overview of how browserslist is written. At this point, I believe you have a clear understanding of how browser adaptation works in engineering, what the role of.browserslistrc is, and what role caniuse plays in the whole process.

One more thing, you might have encountered a problem in one of the steps when creating a Vue project (such as vue Create) that asked you if you wanted to write configuration information to a package.json file or to a separate configuration file. This is similar to the two ways browserslist is configured, either in a package.json file or in a separate file.

5. BrowserslistWriting rules for

So what are the conditions that we can write in development? (Bold is the most common)

  • Defaults: Browserslist defaults (> 0.5%, last 2 versions, Firefox ESR, not Dead)
  • > 5%: Browser version selected by global usage statistics (also available> =.< 和 < =);
    • 5% in US: Uses US usage statistics. It accepts two-letter country/area codes;
    • > 5% in alt-AS: Uses usage statistics for the Asian region. For a list of all locale codes, seecaniuse-lite/data/regions
    • > 5% in my stats: Use custom usage data;
    • > 5% in browserslist-config-mycompany stats: Used frombrowserslist-config-mycompany/browserslist-stats.jsonCustom usage data of
    • Cover 99.5%: the most popular browser that provides coverage;
    • Cover 99.5% in US: Same as above, but the country/area code consists of two letters;
    • Cover 99.5% in my stats: Use custom usage data;
  • Dead: No officially supported or updated browser for 24 months. Now it’s IE 10, IE_Mob 11, BlackBerry 10, BlackBerry 7, Samsung 4 and OperaMobile 12.1;
  • last 2 versions: Last 2 versions of each browser.
    • last 2 Chrome versions: Indicates the latest two versions of Chrome.
    • last 2 major versions 或 last 2 iOS major versions: All minor/patched releases of the last two major releases.
  • node 10 and The node 10.4: Select the latest Node.js10.x.x 或 X 10.4.Version.
    • current node: Browserslist Current version of Node.js.
    • maintained node versionsAll versions of Node.js that are still maintained by the Node.js Foundation.
  • iOS 7: Directly use iOS browser version 7.
    • Firefox > 20: Firefox version later than 20. You can also use> =,< 和 < =. It can also be used with Node.js.
    • ie 6-8: Select a version’s inclusion scope.
    • Firefox ESR: Latest [Firefox ESR] version.
    • PhantomJS 2.1 and PhantomJS 1.9: Select a version of Safari similar to the PhantomJS runtime.
  • extends browserslist-config-mycompanyFrom:browserslist-config-mycompanyNPM package.
  • supports es6-module: A browser that supports specific features. Here,es6-module 是 Can I UseThe page URLfeatParameters. A list of all available features is available atcaniuse-lite/data/featuresTo find it.
  • browserslist config: the browser defined in the Browserslist configuration. Useful in differential services to modify a user’s configuration, for examplebrowserslist config and supports es6-module.
  • since 2015 或 last 2 years: All releases since 2015 (fromThe 2015-03And from2015-03-10Start).
  • unreleased versions 或 unreleased Chrome versions: Alpha and beta.
  • not ie <= 8: Exclude the browser selected by the previous query (ie version <= 8 is not suitable).