This page discusses build-specific configuration options for Angular projects.
\n\nYou can define different named build configurations for your project, such as stage and production, with different defaults.
\nEach named configuration can have defaults for any of the options that apply to the various builder targets, such as build, serve, and test. The Angular CLI build, serve, and test commands can then replace files with appropriate versions for your intended target environment.
A project's src/environments/ folder contains the base configuration file, environment.ts, which provides a default environment.\nYou can add override defaults for additional environments, such as production and staging, in target-specific configuration files.
For example:
\nThe base file environment.ts, contains the default environment settings. For example:
The build command uses this as the build target when no environment is specified.\nYou can add further variables, either as additional properties on the environment object, or as separate objects.\nFor example, the following adds a default for a variable to the default environment:
You can add target-specific configuration files, such as environment.prod.ts.\nThe following sets content sets default values for the production build target:
The following application structure configures build targets for production and staging environments:
\nTo use the environment configurations you have defined, your components must import the original environments file:
\nThis ensures that the build and serve commands can find the configurations for specific build targets.
\nThe following code in the component file (app.component.ts) uses an environment variable defined in the configuration files.
The main CLI configuration file, angular.json, contains a fileReplacements section in the configuration for each build target, which allows you to replace any file in the TypeScript program with a target-specific version of that file.\nThis is useful for including target-specific code or variables in a build that targets a specific environment, such as production or staging.
By default no files are replaced.\nYou can add file replacements for specific build targets.\nFor example:
\nThis means that when you build your production configuration with ng build --configuration production, the src/environments/environment.ts file is replaced with the target-specific version of the file, src/environments/environment.prod.ts.
You can add additional configurations as required. To add a staging environment, create a copy of src/environments/environment.ts called src/environments/environment.staging.ts, then add a staging configuration to angular.json:
You can add more configuration options to this target environment as well.\nAny option that your build supports can be overridden in a build target configuration.
\nTo build using the staging configuration, run the following command:
\nYou can also configure the serve command to use the targeted build configuration if you add it to the \"serve:configurations\" section of angular.json:
As applications grow in functionality, they also grow in size.\nThe CLI allows you to set size thresholds in your configuration to ensure that parts of your application stay within size boundaries that you define.
\nDefine your size boundaries in the CLI configuration file, angular.json, in a budgets section for each configured environment.
You can specify size budgets for the entire app, and for particular parts.\nEach budget entry configures a budget of a given type.\nSpecify size values in the following formats:
\n123 or 123b: Size in bytes
\n123kb: Size in kilobytes
\n123mb: Size in megabytes
\n12%: Percentage of size relative to baseline. (Not valid for baseline values.)
\nWhen you configure a budget, the build system warns or reports an error when a given part of the app reaches or exceeds a boundary size that you set.
\nEach budget entry is a JSON object with the following properties:
\n| Property | \nValue | \n
|---|---|
| type | \n\n The type of budget. One of: \n
| \n
| name | \n\n The name of the bundle (for | \n
| baseline | \nThe baseline size for comparison. | \n
| maximumWarning | \nThe maximum threshold for warning relative to the baseline. | \n
| maximumError | \nThe maximum threshold for error relative to the baseline. | \n
| minimumWarning | \nThe minimum threshold for warning relative to the baseline. | \n
| minimumError | \nThe minimum threshold for error relative to the baseline. | \n
| warning | \nThe threshold for warning relative to the baseline (min & max). | \n
| error | \nThe threshold for error relative to the baseline (min & max). | \n
It is recommended that you avoid depending on CommonJS modules in your Angular applications.\nDepending on CommonJS modules can prevent bundlers and minifiers from optimizing your application, which results in larger bundle sizes.\nInstead, it is recommended that you use ECMAScript modules in your entire application.\nFor more information, see How CommonJS is making your bundles larger.
\nThe Angular CLI outputs warnings if it detects that your browser application depends on CommonJS modules.\nTo disable these warnings, you can add the CommonJS module name to allowedCommonJsDependencies option in the build options located in angular.json file.
The CLI uses Autoprefixer to ensure compatibility with different browser and browser versions.\nYou may find it necessary to target specific browsers or exclude certain browser versions from your build.
\nInternally, Autoprefixer relies on a library called Browserslist to figure out which browsers to support with prefixing.\nBrowserlist looks for configuration options in a browserslist property of the package configuration file, or in a configuration file named .browserslistrc.\nAutoprefixer looks for the browserslist configuration when it prefixes your CSS.
package.json:.browserslistrc, to the project directory, that specifies browsers you want to support:See the browserslist repo for more examples of how to target specific browsers and versions.
\nIf you want to produce a progressive web app and are using Lighthouse to grade the project, add the following browserslist entry to your package.json file, in order to eliminate the old flexbox prefixes:
CSS grid layout support in Autoprefixer, which was previously on by default, is off by default in Angular 8 and higher.
\nTo use CSS grid with IE10/11, you must explicitly enable it using the autoplace option.\nTo do this, add the following to the top of the global styles file (or within a specific css selector scope):
or
\nFor more information, see Autoprefixer documentation.
\n\nYou can use the proxying support in the webpack dev server to divert certain URLs to a backend server, by passing a file to the --proxy-config build option.\nFor example, to divert all calls for http://localhost:4200/api to a server running on http://localhost:3000/api, take the following steps.
Create a file proxy.conf.json in your project's src/ folder.
Add the following content to the new proxy file:
\nIn the CLI configuration file, angular.json, add the proxyConfig option to the serve target:
To run the dev server with this proxy configuration, call ng serve.
You can edit the proxy configuration file to add configuration options; some examples are given below.\nFor a description of all options, see webpack DevServer documentation.
\nNote that if you edit the proxy configuration file, you must relaunch the ng serve process to make your changes effective.
The pathRewrite proxy configuration option lets you rewrite the URL path at run time.\nFor example, you can specify the following pathRewrite value to the proxy configuration to remove \"api\" from the end of a path.
If you need to access a backend that is not on localhost, set the changeOrigin option as well. For example:
To help determine whether your proxy is working as intended, set the logLevel option. For example:
Proxy log levels are info (the default), debug, warn, error, and silent.
You can proxy multiple entries to the same target by defining the configuration in JavaScript.
\nSet the proxy configuration file to proxy.conf.js (instead of proxy.conf.json), and specify configuration files as in the following example.
In the CLI configuration file, angular.json, point to the JavaScript proxy configuration file:
If you need to optionally bypass the proxy, or dynamically change the request before it's sent, add the bypass option, as shown in this JavaScript example.
\nIf you work behind a corporate proxy, the backend cannot directly proxy calls to any URL outside your local network.\nIn this case, you can configure the backend proxy to redirect calls through your corporate proxy using an agent:
\nWhen you define an environment variable http_proxy or HTTP_PROXY, an agent is automatically added to pass calls through your corporate proxy when running npm start.
Use the following content in the JavaScript configuration file.
\n