Our last release blog post has been published not even a month ago and we already released 2 more minors. You missed the releases? No worries, we've got you covered. Here's all you need to know.

targetDependencies -> targetDefaults

To get things started, targetDependencies got renamed to targetDefaults. We originally named them targetDependencies because you were able to define dependencies among project targets (e.g. to run the build target of dependent projects). See the next section for some more info about that.

You could always do more though. However, with our current mission to reduce configuration duplication, the now-called targetDefaults will get more powerful by allowing you to define sensible defaults for your project configs in a central place.

Don't worry, if you're using nx migrate it'll handle the rewriting for you.

Syntactic sugar for "dependsOn"

One of the key features of the Nx task scheduling system is that it is able to automatically build/test/lint/{name your operation} dependencies of your project. If you have proj-a which has a dependency on proj-b and we run nx build proj-a then Nx automatically builds proj-b before building proj-a. Why? Because proj-a depends on the output of proj-b.

These target defaults can be defined

• globally at the nx.json level for all the projects in the workspace
• per project level in the project.json/package.json depending whether you use the project.json config option or package.json

You can still use the same notation as you did until now:

{
  ...
  "targetDefaults": {
    "build": {
        "dependsOn": [
            {
                "target": "build",
                "projects": "dependencies"
              }
        ]
    }
  },
  ...
}

With this release we introduce another, much more concise and elegant way of expressing the same:

{
  ...
  "targetDefaults": {
    "build": {
      "dependsOn": ["^build"]
    }
  },
  ...
}

Similarly, if you don't specify the ^ it would be the same as writing the following:

{
  ...
  "targetDefaults": {
    "build": {
        "dependsOn": [
            {
                "target": "prebuild",
                "projects": "self"
              }
        ]
    }
  },
  ...
}

In that case target prebuild on the project itself is invoked before running its build target.

Inputs, Named Inputs, ENV and runtime variables

In order to improve cache hits we added the possibility to define inputs. For example on the build target, you could define the following input glob pattern to avoid cache invalidation when only spec files got changed.

{
    ...
    "targetDefaults": {
        "build": {
            "inputs": ["!{projectRoot}/**/*.spec.ts"]
        }
    }
}

You can have as many inputs as you like. Also, in order to avoid ambiguity when specifying the path, you need to use either {projectRoot} or {workspaceRoot} in the glob pattern.

Since you might want to reuse certain patterns across multiple targets, we also introduced namedInputs, which allows you to define a set of patterns that can then be referenced in the various targetDefaults:

{
    ...
    "namedInputs": {
        "prodFiles": ["!{projectRoot}/**/*.spec.ts"]
    },
    "targetDefaults": {
        "build": {
            "inputs": ["prodFiles", "^prodFiles"]
        },
        "publish": {
            "inputs": ["prodFiles", "^prodFiles"]
        }
    }
}

Note, by also adding ^ in front of the named input pattern, it also gets applied to all dependent projects, just like with the dependsOn definition.

Inputs can not only just be file globs, but also runtime or environment variables. This makes the inputs even more powerful and helps improve cache hits. In the following example, the environment variable "SELECTED_CLI", as well as the runtime output of running node -v would be included in the computation of the hash used for storing the cached result.

{
    ...
    "targetDefaults": {
        "e2e": {
            "inputs": [
                {
                    "env": "SELECTED_CLI"
                },
                {
                    "runtime": "node -v"
                }
            ]
        }
    }
}

Note that targetDefaults is just a way to specify project-specific settings in a central place within the nx.json. All of these can directly also be added to the package.json or project.json (depending on which approach you use for configuring your projects).

Check out the following video which goes into some of the details on the example of a Lerna monorepo that uses the new Nx inputs configuration.

Optional npmScope

When you create a new Nx workspace it sets up a "npm scope" which you can find in the nx.json.

{
    "npmScope": "myorg",
    ...
}

Although most of the time you might want to use one, it is not mandatory any more. This contributes to our mission of simplifying Nx and making it more flexible.

Speeding up workspace config computation

Project configuration calculations can take up quite some time in large workspaces. Starting with v14.4 we offloaded that part to the Nx Daemon, optimizing the overall command execution time in particular for large workspaces.

New NX_PROJECT_GRAPH_CACHE_DIRECTORY

When using shared volumes on CI, different consumers of the cache can write a different project graph to the cache, thus overwriting one that may be in use by other consumers. Up until now, there was no way to specify a different cache directory just for the project graph.

With this release, we introduce a new NX_PROJECT_GRAPH_CACHE_DIRECTORY environment variable to dictate where Nx (and the Nx Daemon) should store the project graph cache.

Angular updates

In Nx v14.2 we also shipped the Angular v14 migrations which went smoothly. We keep improving our support. In this release in particular we

• added support to generate Storybook stories also for Angular standalone components
• upgraded @angular-eslint/* to version 14
• added support for ngrx version 14

How to Update Nx

Updating Nx is done with the following command, and will update your Nx workspace dependencies and code to the latest version:

After updating your dependencies, run any necessary migrations.

npx nx migrate --run-migrations

Exciting?

We're already deep into following our v15 roadmap with a lot of cool stuff coming up on the horizon.

Makes sure you don't miss anything by

• Following us on Twitter, and
• Subscribe to the YouTube Channel for more information on Angular, React, Nx, and more!
• Subscribing to our newsletter!