Nx 14 Roadmap

[vsavkin]

Read this post to learn about what is new in Nx 13.

Nx 14 Roadmap

As you might know, we alternate between focusing on features and focusing on quality. Nx 10 -> Nx 11 was mainly focused on features, Nx 11 -> Nx 12 on bug fixing and quality, Nx 12 -> Nx 13 on features, and now it's time to attend to stability, performance, and quality.

There will be, of course, plenty of new features, just smaller in scope compared to the last six months.

Core

Workspace Analysis in the Background

In Nx 13, we have landed initial support for running workspace analysis in a daemon process. Currently, you have to opt in to use it, but we will make it the default soon. With this, we can precompute the project graph before the developer invokes a command requiring it. This should reduce the perceived overhead of workspace analysis to basically 0.

Streamlined Configuration

An Nx workspace has the following configuration files:

• nx.json configures the CLI
• workspace.json lists the projects (the project's configuration is located either in workspace.json or in its project.json file). We are streamlining the configuration, making sure it's as small as it can be. We are also going to make the workspace.json and project.json files optional.

Splitting Workspace Package

We currently have three packages implementing the CLI behavior: cli, tao, and workspace, and their responsibilities overlap. This doesn't affect Nx uses, but affects Nx contributors. It's unclear what should live where etc. We are going to refactor this into two packages: cli and workspace (only containing generator, executors and some utils).

Improved Analysis of Third-Party Packages (e.g., NPM)

Nx builds a project graph by looking at the source of your monorepo. It then uses it to power its computation cache and affected:* commands. There are however other things in the workspace that aren't projects per se, but can have a similar impact: they can affect things, they can change the computation hash of a run. Third-party packages are such things.

Currently, we use the root-level package.json to create the list of npm packages and then we treat them as "special" projects. The result is mixed: it works well in some cases but is confusing in others. We have already started to rework this. This clean up should make this functionality a lot more reliable.

Nx Core & Nx for Publishable Libs

You don't have to use any Nx plugins to use Nx. Using Nx core by itself gives you computation caching, affected:*, dep graph viz, VSCode support, github integration and more. Doing this was always possible, but the experience wasn't perfect (e.g., we lacked good docs). We did a lot of work on it in the last couple of months to simplify the config, and we are finishing up this work now.

Our goal is for folks to see no good reason why all Yarn workspaces projects should not add Nx to get all the good stuff it offers.

React

Some React developers primarily use Nx Core when using Nx. They might use say the @nrwl/jest plugin to test their applications, but they build and serve the applications themselves using npm scripts. Even though this is totally fine, we think the following Nx plugins can really level up your productivity: @nrwl/react, @nrwl/next, @nrwl/gatsby and @nrwl/react-native.

Some notable changes that are coming:

• Add React Native Storybook support
• Add affordances to make building microfrontends easier
• Switch to using SWC to improve performance
• Support for EAS Build (React Native / Expo) for workspace libs without being published
• Support for React 18 if it is released before Nx 14

We are also putting a lot of effort into making Nx the best tool for creating publishable React libraries.

Angular

As always, we put a lot of effort into making the best tools for building modern Angular applications. Some highlights:

• Add Angular 13 and NgRx 13 Support
• Add TailwindCSS Support
• Improve migrating from Angular CLI workspaces with multiple projects
• Add a SCAM generator in preparation for Standalone Components
• Add a “create-modern-angular-app” package to create a minimal workspace for Angular

Node/JS

Some Node.js developers primarily use Nx Core when using Nx. They might use the say @nrwl/jest plugin to test their applications, but they build and run the applications or libraries directly using npm scripts.

We want Nx to be the best tool for building publishable JS/TS libraries. A lot of popular open sources libraries and tools are already built with Nx (including Nx itself), but we working hard to make Nx the default choice for many folks.

We are going to introduce the @nrwl/js package to contain executors and generators useful for anyone building JS/TS libraries. All the functionality scattered across several packages now will be moved to @nrwl/js, and new functionally will be added as well (e.g, swc executor). And, of course, automatic migrations will update existing users to use the new package. We are also adding first-class support for publishing npm packages. It has always been possible, but we think we can make it a bit simpler for folks.

We also continue to improve our support for building microservices. One of the highlights here is releasing a version of @nrwl/nest that doesn’t depend on Angular Devkit. NestJS users may not know about it, but the official NestJS tooling (which we rely on) is built with Angular Devkit. We have our own implementation of the same functionality that doesn’t use Angular Devkit. It’s simpler, takes less space, so we think folks may prefer it instead.

Nx Console

Some highlights:

• Dep graph integration
• Debugging support for running Nx tasks
• Refactoring support for removing and moving projects
• Adding support to convert Angular workspaces to Nx

Storybook

• React Native support
• Better out-of-the-box support for Storybook composition (already in development)
• Better integration between Storybook and Cypress (e.g. running multiple storybooks e2e tests in parallel)
• Improved incremental stories generation - the current generator overwrites existing stories or doesn’t allow to selectively - generate stories / keep them in sync with the changes in the components
• Storybook framework-agnostic generators for scaffolding a minimum setup to allow also things like adding @storybook/html to an existing library or application

Version Bumps

As always we will update the versions of ESlint, Jest, Cypress as they get released, and will do our best to provide migrations for folks.

[benpsnyder]

Great roadmap @vsavkin! I've got a project at the moment where we're building out beautiful DDD libraries (via generators, of course!) with a mix of nx-dotnet and NestJS micro-services. We're rewriting our scripts to use Dapr at the heart. I'll open an issue and share some knowledge when I make more progress. Would love it if we can be a part of getting Dapr support into Nx's roadmap, based on what we're learning 🥇

[bbrandt]

@benpsnyder Any blog articles or guidance for others that would like to go down that path with Nx and Dapr?

[benpsnyder]

@benpsnyder Any blog articles or guidance for others that would like to go down that path with Nx and Dapr?

I'll post a reference architecture on the @nx-enterprise repo. Summer vaca delayed our updates to that, but the purpose of it is to combine Nx and Dapr.

Just give me 48h or so

[bbrandt]

@benpsnyder Thanks! Is this where the blog will appear?
https://nx-enterprise.dev/blog

[LayZeeDK]

Angular 13 support

Wait, is Angular 13 support only coming to Nx 14? 🤔

[Niaro]

Total bummer(((

[brandonroberts]

Just to clarify, Angular 13 will be part of the features that are added in the Nx 13.x releases leading up to Nx 14. We are currently worked towards integrating it now.

[jeserkin]

Is there anyway others can help with getting what needed to be done and rolling Nx with Angular 13 support out? :)

[Niaro]

So when again the 14 is about to be released? I wanted to upgrade to Angular 13, and now, I won't be able... cause I need to wait for other stuff I don't use?( Can we do some magic with the minor version?

[brandonroberts]

It will be released in a 13.x minor

[Niaro]

@brandonroberts Thank you! You made this day much better!!)

[wizardnet972]

"Add a SCAM generator in preparation for Standalone Components"

Awesome!

Currently, I generate ngmodule inside the component file and I move all my components to work in this way.

So my thoughts:

Today nx generates a lib with empty ngmodule, which is not necessary because the component and the module should not import in another ngmodule and should just export both by index file: component-module and component. otherwise, they lose tree shake ability:

libs/
 elements
  src
    + lib
      + datepicker
      + product-form
      + product-card
      - index.ts

I think the library should generate an empty lib folder (without an empty ngmodule). and every component will have the option to export it using index.ts file.

import and exports
Also please support the importing of SCAM components should be like angular material does:
import {...} from '@angular/material/tree';

Instead of import the product-form this way:

import { ProductFormComponentModule  } from  '@nx-app/elements';

For webpack tree shake should be this way?

import { ProductFormComponentModule  } from  '@nx-app/elements/product-form';

But to do that please support generating paths in tsconfig from the generator:

path: {
  '@nx-app/elements/*': [....] 
}

Storybook and SCAM

Also, the storybook doesn't generate stories to components which are SCAMs. because they are not imported in the main library module.
I debug the code and found why the storybook generator is looking for module.ts file (which probably doesn't be in SCAM).

nx/packages/angular/src/generators/stories/lib/module-info.ts

Line 48 in 5bc1692

if (filePath.endsWith('.module.ts')) {

So this is why the generator won't generate stories for SCAM component. this is should be fixed as well.
(maybe I open an issue about it?)

[leon]

A lot of packages we use such as firebase have converted into ESM.
I have encountered a lot of problems where jest or webpack is having troubles with this.

What is your take on this, and how will it affect NX?

[brandonroberts]

We've also identified some of these issues with the conversion to ESM impacting upstream libraries. We are working to make sure compatibility is stable after upgrading. You can track the Angular v13 work here https://github.com/nrwl/nx/pull/7161/files

[adnanebrahimi]

I want to start a new project with NX 14 :))) how long I should wait?

[jeserkin]

There are so many questions here 1:1 with yours. Is one more really necessary?

[adnanebrahimi]

Relax man, We are just excited about this incoming version :)

[jeserkin]

I am don't mind excitement. Just each time someone gets excited with already existing question I am receiving email message from github. :|

[adnanebrahimi]

Fair enough, next time i just screaming my existment in front of the monitor 😄 just kidding. I just didn't notice that this question asked before.

[wrslatz]

Using Nx core by itself gives you computation caching, affected:*, dep graph viz, VSCode support, github integration and more. Doing this was always possible, but the experience wasn't perfect (e.g., we lacked good docs). We did a lot of work on it in the last couple of months to simplify the config, and we are finishing up this work now.

I'm assuming some of these docs improvements can help close out #5580? With the new workspace and project config structure and selective tsconfig hashing, it's not clear how we should be configuring Nx implicitDependencies for changes to root config files (nx.json, workspace.json, tsconfig.base.json). Changes to these files have been one of our main sources for affecting all projects.

[benpsnyder]

Would love to see Yarn v3 make its way into Nx 14! >> feat(core): upgrade yarn v1 => v3 [berry] && replace npx with yarn dlx

[puku0x]

Does Nx keep supporting Stylus for non-Angular projects?

I'm wondering about:

• Angular shows warning when using it since v12. angular/angular-cli@82ca7d0
• Although @nrwl/next supports it, @zeit/next-stylus plugin, which is used in withStylus(), is no longer supported and it is recommended to use the built-in CSS and Sass support.

(Don't get me wrong😅 I know Stylus is still alive. stylus/stylus#2637)

[DaSchTour]

What about "ng-update" and "packageGroup" used with migrate? I think that would solve #5648
So that nx migrate @angular/core or nx migrate @ngrx/store would be similar to ng update @angular/core or ng update @ngrx/store when it comes to updating packages.

I would also love to see some documentation update for #8435

[luxaritas]

Two questions:

1. Currently, there exists both @nrwl/workspace:library and @nrwl/js:library. Will the prior be removed in favor of the latter? It's unclear to me what the difference is supposed to be, if any.

2. With respect to:

   You don't have to use any Nx plugins to use Nx. Using Nx core by itself gives you computation caching, affected:*, dep graph viz, VSCode support, github integration and more. Doing this was always possible, but the experience wasn't perfect (e.g., we lacked good docs). We did a lot of work on it in the last couple of months to simplify the config, and we are finishing up this work now.

   Are there be any pointers on how to take advantage of computation caching for builds if not using a relevant NX plugin? As far as I understand, nx does some magic at build time to dynamically re-write configs based on whether a library has been previously built or not. Is this correct?

[luxaritas]

Also curious what changes might be in store for @nrwl/node or @nrwl/web given the addition of @nrwl/js, if any - I imagine it would be a good idea to have a page in the documentation describing the precise differences between the available options (eg this one builds with webpack, this one uses tsc, etc).

[luxaritas]

As far as 2 goes, to answer my own question it looks like npm/yarn workspaces is a solid option. No need to set paths in the tsconfig or anything, since the local packages will be resolved from node_modules, and the package.json handles pointing to the correct entry point when you eg point main to the the built output

[bressanelle]

Any plans for create react microfrontends using module federation?

[NEmbgen]

This would be super dope

[mwarger]

This exists now: #9413

[richardsengers]

For those getting an error while upgrading to nx 14 with yarn 2+ (I don't know if this also happens when on yarn 1)

Command failed: yarn add -W @nrwl/jest@14.0.1

yarn cache clean worked for me