Recommended Free Tools
iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Angular workspace configuration lives in the root angular.json file. Workspace-level settings provide shared defaults; each project can define its own targets such as build, serve, and test, with named configurations for environments such as production or staging. To change a setting safely, identify the project key and target first, then check the installed builder’s schema for the option’s supported spelling and values.
Find angular.json and the project you need
Open angular.json at the workspace root. Its top-level properties configure the workspace, while the projects object contains configuration for individual applications and libraries. Paths in the file are relative to the workspace root.
The keys under projects are logical project names, not a guaranteed list of folders. For example, an initial application can be configured at the workspace root, while additional projects commonly live under projects/. Use the project key in angular.json to find the right configuration rather than assuming its name matches a directory. See Angular’s workspace and file structure guidance.
What project properties mean
A project entry can include properties such as root, projectType, sourceRoot, prefix, i18n, schematics, and architect. The root and sourceRoot values help describe where project files live; the project key is the name used to address that project in CLI commands.
#1 Best Overall
Understand the configuration layers
Think of the file as a set of layered defaults. Workspace-level properties can provide shared CLI and code-generation settings. A project can set its own values, and a command-line argument can override configuration for one invocation. Within a project, its architect section defines targets, each of which can have default options and named configurations.
- Workspace: Shared properties, including CLI settings and generation schematics.
- Project: Project-specific properties and targets under
projects[project-name]. - Target: A builder plus base
optionsand optional namedconfigurations. - Command invocation: CLI arguments can override configured defaults for that run.
For a particular option, inspect the applicable project and target configuration, any selected named configuration, and the command’s flags. A project-specific value can override a workspace default; a command-line value can override the configured value when the corresponding option is supported by that builder.
How targets connect to Angular CLI commands
A target identifies the builder package and builder that perform a task. The target’s options provide its base settings, while configurations can supply alternatives. The familiar commands normally invoke corresponding targets for the selected project:
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
ng buildruns the project’sbuildtarget.ng serveruns itsservetarget; the documented common builder is@angular/build:dev-server.ng testruns itstesttarget.
To invoke a custom target, use ng run with the project and target. Angular’s build documentation and serve documentation explain these target relationships. The development server can rebuild and live-reload as source changes.
Rank #3
Builder and CLI options can vary by installed version and selected builder. Before adding or changing an option, check the schema for the builder actually configured in your workspace rather than relying on an example written for a different release.
Choose and combine named configurations
Angular documents production and development build configurations; a team can add names such as staging. Select one with --configuration. When you pass multiple configuration names separated by commas, Angular applies them from left to right. If configurations set the same option, the later value wins.
For example, a command can combine a shared staging configuration with a deployment-specific configuration. Put the shared settings first and the settings that should take precedence last. Confirm that the chosen names exist on the target you are invoking.
Make a targeted change
- Start at the workspace root. Locate
angular.json. - Find the project key. Under
projects, identify the logical project name for the application or library. - Find the target. Under that project’s
architectsection, locate the target such asbuildorserve. Check its builder to know which schema governs its options. - Choose the right layer. Put a shared default at workspace level when appropriate; use the project target for a project-specific change, or a named configuration for an environment-specific value.
- Edit or inspect the JSON path. You can edit
angular.jsondirectly or useng config. For example,ng config projects.my-app.architect.build.optionsreads that JSON path; adding a value sets it. Replacemy-appwith the actual project key and use the path appropriate to the setting. See theng configreference. - Check spelling and schema. In
angular.json, configuration keys use camelCase, even when CLI flags use dash-case. Verify the option name and accepted values in the installed builder’s schema. - Run the matching command. Use the relevant CLI command and, when needed, select a named configuration. Confirm that it affects the project and target you intended.
Build options and common pitfalls
Build target options can cover assets, styles, scripts, style preprocessor settings, file replacements, budgets, index behavior, source maps, optimization, and output paths. Their precise shape and valid values depend on the configured builder, so consult its schema before changing them.
Pay attention to path semantics: paths are relative to the workspace root, but individual fields can describe paths in different contexts. The Angular workspace configuration documentation notes that asset copying does not write outside the project output path. Do not assume every path field is interpreted relative to the same directory; check the description of that field in the applicable documentation or schema.
Keep source maps from becoming public
Source-map settings can control details such as whether original source content is embedded. Hidden source maps are not linked from the generated JavaScript bundles, but that alone does not make them private. If maps should not be public, ensure the deployment does not serve the generated map files. Angular describes these options in its workspace configuration reference.
Check the serve target separately
The serve target uses a development-server builder and can include server-specific options in addition to its relationship with build behavior. Inspect the configured target rather than assuming a build setting can be copied into serve unchanged. The serve guide describes the development server’s target and rebuild behavior.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
