In browserslist, what is the point of having different environments configurations?

Viewed 360

Introduction: browserslist is a configuration for letting other developers, packages, plugins, etc., know which browsers your project gives support to. This is done through queries, and there is a way to split these queries into different environments.

{
  "browserslist": {
    "production": [
      ">0.2%",
      "not dead",
      "not op_mini all"
    ],
    "development": [
      "last 1 chrome version",
      "last 1 firefox version",
      "last 1 safari version"
    ]
  },
}

Let's say I use a javascript function that is supported by the development config, but not by production.

My question is: then what is the point of having split config between production and development if I would find possible errors for production config that are not detected earlier in development? (Is it because it gives speed on compiling time or some similar advantage?)

1 Answers

Production: This will minify your code for fast web performance and has a feature for production-built-in

eg. at your CSS styling you should wrap all your CSS code in a file or MiniCssExtractPlugin when you decided to deploy your project

Development: This will give the productivity when building your project

eg. you should have a DevServer and StylingLoaders to put styling at the DOM and when you deploy the project you can implement the Css Plugin to create a file

Your production config gives you an error because it may need to update some dependencies or npm packages

Related