A file named angular.json at the root level of an Angular workspace provides workspace-wide and project-specific configuration defaults for build and development tools provided by the Angular CLI.\nPath values given in the configuration are relative to the root workspace folder.
At the top level of angular.json, a few properties configure the workspace, and a projects section contains the remaining per-project configuration options. CLI defaults set at the workspace level can be overridden by defaults set at the project level, and defaults set at the project level can be overridden on the command line.
The following properties, at the top level of the file, configure the workspace.
\nversion: The configuration-file version.newProjectRoot: Path where new projects are created. Absolute or relative to the workspace folder.defaultProject: Default project name to use in commands, where not provided as an argument. When you use ng new to create a new app in a new workspace, that app is the default project for the workspace until you change it here.schematics : A set of schematics that customize the ng generate sub-command option defaults for this workspace. See Generation schematics below.projects : Contains a subsection for each project (library or application) in the workspace, with the per-project configuration options.The initial app that you create with ng new app_name is listed under \"projects\":
When you create a library project with ng generate library, the library project is also added to the projects section.
Note that the projects section of the configuration file does not correspond exactly to the workspace file structure.
The initial app created by ng new is at the top level of the workspace file structure.
Additional applications and libraries go into a projects folder in the workspace.
For more information, see Workspace and project file structure.
\nWhen you create new workspaces and projects, you have the option to use Angular's strict mode, which can help you write better, more maintainable code.\nFor more information, see Strict mode.
\nThe following top-level configuration properties are available for each project, under projects:<project_name>.
| PROPERTY | \nDESCRIPTION | \n
|---|---|
root | \nThe root folder for this project's files, relative to the workspace folder. Empty for the initial app, which resides at the top level of the workspace. | \n
sourceRoot | \nThe root folder for this project's source files. | \n
projectType | \nOne of \"application\" or \"library\". An application can run independently in a browser, while a library cannot. | \n
prefix | \nA string that Angular prepends to generated selectors. Can be customized to identify an app or feature area. | \n
schematics | \nA set of schematics that customize the ng generate sub-command option defaults for this project. See Generation schematics below. | \n
architect | \nConfiguration defaults for Architect builder targets for this project. | \n
Angular generation schematics are instructions for modifying a project by adding files or modifying existing files.\nIndividual schematics for the default Angular CLI ng generate sub-commands are collected in the package @schematics/angular.\nSpecify the schematic name for a subcommand in the format schematic-package:schematic-name;\nfor example, the schematic for generating a component is @schematics/angular:component.
The JSON schemas for the default schematics used by the CLI to generate projects and parts of projects are collected in the package @schematics/angular.\nThe schema describes the options available to the CLI for each of the ng generate sub-commands, as shown in the --help output.
The fields given in the schema correspond to the allowed argument values and defaults for the CLI sub-command options.\nYou can update your workspace schema file to set a different default for a sub-command option.
\n\nArchitect is the tool that the CLI uses to perform complex tasks, such as compilation and test running.\nArchitect is a shell that runs a specified builder to perform a given task, according to a target configuration.\nYou can define and configure new builders and targets to extend the CLI.\nSee Angular CLI Builders.
\n\nAngular defines default builders for use with specific CLI commands, or with the general ng run command.\nThe JSON schemas that define the options and defaults for each of these default builders are collected in the @angular-devkit/build-angular package.\nThe schemas configure options for the following builders.
The architect section of angular.json contains a set of Architect targets.\nMany of the targets correspond to the CLI commands that run them.\nSome additional predefined targets can be run using the ng run command, and you can define your own targets.
Each target object specifies the builder for that target, which is the npm package for the tool that Architect runs.\nIn addition, each target has an options section that configures default options for the target, and a configurations section that names and specifies alternative configurations for the target.\nSee the example in Build target below.
The architect/build section configures defaults for options of the ng build command.\nSee Build target below for more information.
The architect/serve section overrides build defaults and supplies additional serve defaults for the ng serve command. In addition to the options available for the ng build command, it adds options related to serving the app.
The architect/e2e section overrides build-option defaults for building end-to-end testing apps using the ng e2e command.
The architect/test section overrides build-option defaults for test builds and supplies additional test-running defaults for the ng test command.
The architect/lint section configures defaults for options of the ng lint command, which performs code analysis on project source files. The default linting tool for Angular is TSLint.
The architect/extract-i18n section configures defaults for options of the ng extract-i18n command, which extracts marked message strings from source code and outputs translation files.
The architect/server section configures defaults for creating a Universal app with server-side rendering, using the ng run <project>:server command.
The architect/app-shell section configures defaults for creating an app shell for a progressive web app (PWA), using the ng run <project>:app-shell command.
In general, the options for which you can configure defaults correspond to the command options listed in the CLI reference page for each command.\nNote that all options in the configuration file must use camelCase, rather than dash-case.
\n\nThe architect/build section configures defaults for options of the ng build command. It has the following top-level properties.
| PROPERTY | \nDESCRIPTION | \n
|---|---|
builder | \nThe npm package for the build tool used to create this target. The default builder for an application (ng build myApp) is @angular-devkit/build-angular:browser, which uses the webpack package bundler. Note that a different builder is used for building a library (ng build myLib). | \n
options | \nThis section contains default build target options, used when no named alternative configuration is specified. See Default build targets below. | \n
configurations | \nThis section defines and names alternative configurations for different intended destinations. It contains a section for each named configuration, which sets the default options for that intended environment. See Alternate build configurations below. | \n
Angular CLI comes with two build configurations: production and development. By default, the ng build command uses the production configuration, which applies a number of build optimizations, including:
You can define and name additional alternate configurations (such as stage, for instance) appropriate to your development process. Some examples of different build configurations are stable, archive and next used by AIO itself, and the individual locale-specific configurations required for building localized versions of an app. For details, see Internationalization (i18n).
You can select an alternate configuration by passing its name to the --configuration command line flag.
You can also pass in more than one configuration name as a comma-separated list. For example, to apply both stage and fr build configurations, use the command ng build --configuration stage,fr. In this case, the command parses the named configurations from left to right. If multiple configurations change the same setting, the last-set value is the final one.
The configurable options for a default or targeted build generally correspond to the options available for the ng build, ng serve, and ng test commands. For details of those options and their possible values, see the CLI Reference.
Some additional options can only be set through the configuration file, either by direct editing or with the ng config command.
| OPTIONS PROPERTIES | \nDESCRIPTION | \n
|---|---|
assets | \nAn object containing paths to static assets to add to the global context of the project. The default paths point to the project's icon file and its assets folder. See more in Assets configuration below. | \n
styles | \nAn array of style files to add to the global context of the project. Angular CLI supports CSS imports and all major CSS preprocessors: sass/scss, less, and stylus. See more in Styles and scripts configuration below. | \n
stylePreprocessorOptions | \nAn object containing option-value pairs to pass to style preprocessors. See more in Styles and scripts configuration below. | \n
scripts | \nAn object containing JavaScript script files to add to the global context of the project. The scripts are loaded exactly as if you had added them in a <script> tag inside index.html. See more in Styles and scripts configuration below. | \n
budgets | \nDefault size-budget type and threshholds for all or parts of your app. You can configure the builder to report a warning or an error when the output reaches or exceeds a threshold size. See Configure size budgets. (Not available in test section.) | \n
fileReplacements | \nAn object containing files and their compile-time replacements. See more in Configure target-specific file replacements. | \n
The options assets, styles, and scripts can have either simple path string values, or object values with specific fields.\nThe sourceMap and optimization options can be set to a simple Boolean value with a command flag, but can also be given a complex value using the configuration file.\nThe following sections provide more details of how these complex values are used in each case.
Each build target configuration can include an assets array that lists files or folders you want to copy as-is when building your project.\nBy default, the src/assets/ folder and src/favicon.ico are copied over.
To exclude an asset, you can remove it from the assets configuration.
\nYou can further configure assets to be copied by specifying assets as objects, rather than as simple paths relative to the workspace root.\nA asset specification object can have the following fields.
\nglob: A node-glob using input as base directory.input: A path relative to the workspace root.output: A path relative to outDir (default is dist/project-name). Because of the security implications, the CLI never writes files outside of the project output path.ignore: A list of globs to exclude.followSymlinks: Allow glob patterns to follow symlink directories. This allows subdirectories of the symlink to be searched. Defaults to false.For example, the default asset paths can be represented in more detail using the following objects.
\nYou can use this extended configuration to copy assets from outside your project.\nFor example, the following configuration copies assets from a node package:
\nThe contents of node_modules/some-package/images/ will be available in dist/some-package/.
The following example uses the ignore field to exclude certain files in the assets folder from being copied into the build:
An array entry for the styles and scripts options can be a simple path string, or an object that points to an extra entry-point file.\nThe associated builder will load that file and its dependencies as a separate bundle during the build.\nWith a configuration object, you have the option of naming the bundle for the entry point, using a bundleName field.
The bundle is injected by default, but you can set inject to false to exclude the bundle from injection.\nFor example, the following object values create and name a bundle that contains styles and scripts, and excludes it from injection:
You can mix simple and complex file references for styles and scripts.
\nIn Sass and Stylus you can make use of the includePaths functionality for both component and global styles, which allows you to add extra base paths that will be checked for imports.
To add paths, use the stylePreprocessorOptions option:
Files in that folder, such as src/style-paths/_variables.scss, can be imported from anywhere in your project without the need for a relative path:
Note that you will also need to add any styles or scripts to the test builder if you need them for unit tests.\nSee also Using runtime-global libraries inside your app.
The optimization browser builder option can be either a Boolean or an Object for more fine-tune configuration. This option enables various optimizations of the build output, including:
There are several options that can be used to fine-tune the optimization of an application.
\n| Option | \nDescription | \nValue Type | \nDefault Value | \n
|---|---|---|---|
scripts | \nEnables optimization of the scripts output. | \nboolean | \ntrue | \n
styles | \nEnables optimization of the styles output. | \nboolean|Styles optimization options | \ntrue | \n
fonts | \nEnables optimization for fonts. Note: This requires internet access. | \nboolean|Fonts optimization options | \ntrue | \n
| Option | \nDescription | \nValue Type | \nDefault Value | \n
|---|---|---|---|
minify | \nMinify CSS definitions by removing extraneous whitespace and comments, merging identifiers and minimizing values. | \nboolean | \ntrue | \n
inlineCritical | \nExtract and inline critical CSS definitions to improve First Contentful Paint. | \nboolean | \ntrue | \n
| Option | \nDescription | \nValue Type | \nDefault Value | \n
|---|---|---|---|
inline | \nReduce render blocking requests by inlining external Google fonts and icons CSS definitions in the application's HTML index file. Note:This requires internet access. | \nboolean | \ntrue | \n
You can supply a value such as the following to apply optimization to one or the other:
\n For Universal, you can reduce the code rendered in the HTML page by\nsetting styles optimization to true.
The sourceMap browser builder option can be either a Boolean or an Object for more fine-tune configuration to control the source maps of an application.
| Option | \nDescription | \nValue Type | \nDefault Value | \n
|---|---|---|---|
scripts | \nOutput source maps for all scripts. | \nboolean | \ntrue | \n
styles | \nOutput source maps for all styles. | \nboolean | \ntrue | \n
vendor | \nResolve vendor packages source maps. | \nboolean | \nfalse | \n
hidden | \nOutput source maps used for error reporting tools. | \nboolean | \nfalse | \n
The example below shows how to toggle one or more values to configure the source map outputs:
\nWhen using hidden source maps, source maps will not be referenced in the bundle.\nThese are useful if you only want source maps to map error stack traces in error reporting tools,\nbut don't want to expose your source maps in the browser developer tools.
\n