Cover image by DALL-E.
The defaultProject
setting for the Nx CLI was originally inherited from the Angular CLI. In integrated and standalone Nx workspaces, the defaultProject
setting is located in nx.json
. In package-based Nx workspaces, defaultProject
is located in package.json#nx
. While it was removed from Angular CLI version 16, it is still present but unofficially deprecated in Nx version 16.x as evident by the nx.json
reference which doesn't list it.
As of Nx 16.2, a defaultProject
setting is still configured when using create-nx-workspace
to generate a standalone Nx workspace. However, it is safe to remove this setting as Nx detects the project.json
file in the root directory of a standalone workspace.
In this article, we discuss why the defaultProject
is being deprecated, which use cases it affects with example commands not depending on it, and finally the viable replacement for defaultProject
.
Why will defaultProject
be removed?
The defaultProject
setting is being depreacted and eventually removed because it doesn't make sense in integrated and package-based Nx workspaces where the preferred project usually varies between teams and developers and so shouldn't be committed to a configuration shared between most or all teams and developers.
Standalone Nx workspaces can have more than one project but the original project is defined in a package.json
or project.json
file in the root workspace directory which Nx detects to infer the project for Nx CLI commands run from this directory.
What does defaultProject
affect?
Let's explore most of the use cases affected by the defaultProject
setting and how we can complete them without this setting.
Running tasks
An Nx workspace defines projects, targets, and, optionally, configurations.
To run a task for a specific configuration of a project target, we use the following command format.
nx run <project>:<target>[:<configuration>]
or
nx run <project>:<target> [--configuration=<configuration>]
For example, to start a task running the build
target on the my-app
project, we use the following command.
nx run my-app:build
Common target names have alias commands, for example the following command is an alias of the previous nx run
command.
nx build my-app
To make sure we use the production
build configuration, we prepend :production
to our nx run
command as seen in the following.
nx run my-app:build:configuration
The aliased version is as follows.
nx build my-app --configuration=production
Running generators
Some Nx generators and Angular schematics require a --project
option but use the defaultProject
setting when omitted, for example @nx/component
and @schematics/angular:component
.
Without a deafultProject
setting, we must pass a --project
option as seen in the following example.
nx generate @nx/angular:component button --standalone --project=my-app
What should I use instead of defaultProject
?
Although the preferred project isn't the same for all teams or developers, it is still convenient to leave out the same project name for most task runs and generators.
As a viable replacement for the defaultProject
setting, we can use the NX_DEFAULT_PROJECT
environment variable which is planned to outlive the defaultProject
setting as we have many options for setting this in individual environments, both for CI and local development use cases.
When we set the value of the NX_DEFAULT_PROJECT
environment variable to a project name, both task running and code generation works as if we had specified the defaultProject
setting but without committing it to a shared configuration.
For example, with the NX_DEFAULT_PROJECT
environment variable set to my-app
, we can use the following build commands.
# build the app
nx run build
# or
nx build
# build the app in production mode
nx run build: production
# or
nx build --configuration=production
Additionally, we can use generators and schematics that require a --project
option witout specifying a project.
nx generate @nx/angular:component button --standalone
# or
nx generate @schematics/angular:component button --standalone
Conclusion
In this article, we learned that defaultProject
is being deprecated and removed because it is no longer necessary for standalone Nx workspaces and in the case of integrated or package-based Nx workspaces, different teams and developers often want a different default project. Because of this, we shouldn't commit a shared setting.
We learned how the defaultProject
setting affects the nx run
command as well as Nx generators and Angular schematics that require a --project
option.
Finally, we learned how we can use the NX_DEFAULT_PROJECT
environment variable to configure an individual environment for CI tasks or local development in the same way as we would have used the defaultProject
setting in the past but without committing a setting to a shared configuration.
Top comments (1)
That makes totally sense. Thanks for the article, it is very informative.