DEV Community: Nx

Monorepos - Why Speed Matters

Katerina Skroumpelou — Wed, 20 Mar 2024 20:52:22 +0000

In the ever-evolving landscape of software development, efficiency and speed are vital. As projects grow in complexity, developers and teams need tools that can keep up without sacrificing quality or performance.

Nx is a suite of powerful tools designed to optimize your development workflow, which sets the building blocks for a fast CI. Nx is always innovating in many ways to make developers’ lives easier, but this post is exclusively focused on the things Nx has done in the past year to make development faster and faster.

Why speed matters

The ability to iterate quickly and efficiently is vital for any software project. Speed in the development process offers several critical advantages:

Faster feedback loops: Quick iterations mean immediate feedback, allowing teams to adapt, learn, and improve their work on the fly.
Reduced time to market: Accelerating the development process can significantly cut down the overall time to market, providing a competitive edge which reclaims revenue that would have otherwise been lost.
Decreased developer frustration: No more waiting for builds and tests to complete. A streamlined workflow keeps morale high and productivity higher.

If you’re using Nx already, you’re already familiar with

Affected - identifying and running tasks only on projects impacted by code changes,
Nx Replay - our powerful cache and
Nx Agents - the concept of Parallelization and Distribution.

But let’s see all the extra things we did this past year to make everything faster.

Speed at the core

Rustifying Nx

The Nx daemon has seen significant enhancements, notably through the use of Rust to calculate file hashes behind the scenes. This improvement not only speeds up the start-up times but also optimizes performance even without the daemon, especially on CI environments where the daemon isn't used. The benchmark results at this repo showcase the remarkable speed improvements, making Nx competitive with native code solutions while maintaining the accessibility and flexibility of Node.js. Nx is still Node-first, so contributions are easier and only the most performance-critical parts of Nx are native code.

Task Hasher and archive file innovations

The introduction of a task hasher written in Rust, alongside the use of an archive file to store workspace file hashes (.nx/cache), has significantly reduced the need for repetitive file system accesses. This innovation means that running multiple Nx commands in CI is much faster, as file hashing becomes unnecessary after the initial run.

The Archive file

The archive file is a binary file that contains the workspace file hashes with their last modified time. Every time Nx starts (ie, running nx run project:target) it gets all the files with their last modified time, and compares it to the archive. If the file exists in the archive, then Nx does not access the file system to read the file to hash (reading individual files is slower than just getting a list of files from a directory). So running multiple nx commands in CI is quick to start because Nx does not need to constantly hash files.

Nx Replay

Nx Replay enables caching and reusing of task results. It’s our well known Nx remote cache! It allows developers to avoid re-running expensive tasks by retrieving the cached results from a remote cache. This significantly improves build and test performance, as well as developer productivity. Nx Replay is also critical to the functioning of Nx Agents, which rely on the remote cache to ensure that the results of a task will be shared with every agent that needs them. By using Nx Replay, developers can optimize their workflows and reduce the time spent waiting for tasks to complete.

With Nx Replay, you can see significant speed improvements in your CI pipelines for modified PRs. What’s also important is that if a task has been executed in CI, a developer running that same task locally can reuse the task result instead of actually running the task. So you will also see improvements locally.

Nx Agents

Nx Agents represent the pinnacle of task distribution optimization, ensuring that tasks are executed as efficiently as possible based on the specific requirements of each change. Some features that make up this effort are:

Easy integration with existing providers
- Distribution is handled on the Nx Cloud infrastructure and all you need is a single line. What’s more, all results are played back to your original CI provider script which triggers the Nx Cloud distribution, so that you can make use of the resulting artifacts
Efficient task distribution
- Save compute resources and reduce costs, minimizing idle time and compute waste
- Dynamic sizing based on PR size
Tusky - our AI solution - coming soon
- You set your desired cost/speed ratio, and you forget about any more configuration. We ensure maximum speed up to limits you set yourself.

You can read more about Nx Agents here.

TaskAtomizer

The TaskAtomizer splits your Cypress or Playwright e2e tests by file. This significantly enhances granularity for caching, parallel execution, and flaky test identification. This granular approach ensures that individual test results can be cached and only the necessary tests rerun, greatly reducing CI pipeline times and facilitating more accurate flaky test detection.

Addressing flaky tests with test deflaking

Flaky tests can be a significant bottleneck in the CI process. Nx tackles this issue head-on by intelligently re-running only the flaky tasks, rather than the entire pipeline. This approach not only saves time but also provides developers with more confidence in their CI pipeline's reliability.

Nx creates a hash of all the inputs for a task whenever it is run. If it encounters a task that fails with a particular set of inputs and then succeeds with those same inputs, Nx knows for a fact that the task is flaky.

New Nx features that tie in with our core speed improvements

Module Federation

With the help of Nx and the Module Federation setup that Nx offers, you can split up large Angular apps into smaller “vertical slices”. This can significantly speed up your builds and app startup time. Nx has revolutionized the use of Module Federation, especially in how static remotes are built and served. We make use of Nx’s task orchestration, allowing users to fine tune the number of builds happening in parallel to improve local startup time, manage machine resources better, allow for scaling.

First-Class Playwright support

With first-class support for Playwright through @nx/playwright, Nx offers out-of-the-box generators to run Playwright tests efficiently. This integration is especially powerful with features like TaskAtomizer, enhancing the testing process's speed and reliability.

Conclusion

Nx provides an unparalleled toolkit for developers and teams looking to optimize their development workflows, and we keep making it faster. By intelligently leveraging modern technologies and innovative optimizations, Nx delivers speed, efficiency, and reliability, allowing teams to focus on what matters most: building great software.

Learn more

#nx Follow

Add Cypress, Playwright, and Storybook to Nx Expo Apps

Emily Xiong — Mon, 19 Feb 2024 21:18:25 +0000

Expo has first-class support for building full-stack websites with React, so I can leverage that to add Cypress/Playwright for E2E testing and add the Storybook for UI components.

In this blog, I am going to add Cypress, Playwright, and Storybook to my Nx Expo app:

xiongemi / nx-expo-monorepo

a repo showing 2 apps created by @nx/expo

NxExpoMonorepo

This workspace is created using @nx/expo (Nx and Expo).

✨ This workspace has been generated by Nx, a Smart, fast and extensible build system. ✨

Workspace structure

It contains 2 apps:

cats and its e2e (cypress/playwright)
dogs and its e2e (cypress/playwright)

4 libs:

models
queries: tanstack react-query
states: redux state management
ui

Commands

nx start cats to start the cats app
nx start dogs to start the dogs app
nx build cats to build the cats app using EAS
nx build dogs to build the dogs app using EAS
nx test cats to test the cats app
nx test dogs to test the dogs app
nx lint cats to lint the cats app
nx lint dogs to lint the dogs app
npm run deploy to deploy the cats app to github page
nx e2e cats-cypress to run cypress e2e tests on cats app
nx e2e cats-playwright to…

View on GitHub

It is an app that shows a random fact about cats:

What is @nx/expo? Nx is a build system that helps you maintain and scale monorepos, both locally and on CI. @nx/expo contains generators for managing Expo applications and libraries within an Nx workspace.

I am going to go through:

How to add Cypress
How to add Playwright
How to add Storybook

Add Cypress

In this section, I am going to go through:

When I already have an existing Nx Workspace, how do I add the Expo and Cypress projects?
When I already have an existing Nx Expo app, how do I add the Cypress tests to my app?

Add a new Expo App in an Nx Workspace

In any Nx workspace, I can install @nx/expo by running the following command:

npx nx add @nx/expo

Now when I generate a new Expo app, I can simply use @nx/expo:application generator with the flag --e2eTestRunner=cyperss:

npx nx generate @nx/expo:app --e2eTestRunner=cypress

It should create the expo app and its Cypress e2e tests. I can run npx nx run <your-app-name>-e2e:e2e to run the Cypress e2e tests.

Add Cypress to an Existing Nx Expo App

Before I start, I need to make sure I can serve my Expo app for the web view. In this example, in my apps/cats/project.json, I got a serve target defined:

   "serve": {  
      "executor": "@nx/expo:serve",  
      "options": {  
        "port": 8081  
      }  
    },

So I can run the command npx nx run cats:serve to serve the app on http://localhost:8081/.

I can also use @nx/expo inferred tasks without having a serve target in project.json. In .env file, set NX_ADD_PLUGINS=true; then run the command

npx nx add @nx/expo

Then I can still run the serve command npx nx run <your expo project>:serve without a serve target defined.

Then I can set up the cypress e2e project against the web app.

First, I need to install @nx/cypress:

npx nx add @nx/cypress

Second, I create a project.json for my Cypress project. In this example, I create a project.json at apps/cats-cypress/project.json, I name the project cats-cypress:

{  
  "name": "cats-cypress"  
}

Third, run the below command to generate Cypress configuration:

npx nx generate @nx/cypress:configuration --project cats-cypress --devServerTarget=cats:serve --baseUrl=http://localhost:8081 --verbose --bundler=none

Since the serve command is npx nx run cats:serve, so the flag is --devServerTarget is cats:serve. Also, the --baseUrl is http://localhost:8081.

It should generate cypress.config.ts and a sample test:

I can run the Cypress test using the below command:

npx nx run cats-cypress:e2e

Add Cypress Tests

I change the example tests:

Now I can run the command npx nx run cats-cypress:e2e and it should pass:

 2 passing (867ms)  


  (Results)  

  ┌────────────────────────────────────────────────────────────────────────────────────────────────┐  
  │ Tests:        2                                                                                │  
  │ Passing:      2                                                                                │  
  │ Failing:      0                                                                                │  
  │ Pending:      0                                                                                │  
  │ Skipped:      0                                                                                │  
  │ Screenshots:  0                                                                                │  
  │ Video:        false                                                                            │  
  │ Duration:     0 seconds                                                                        │  
  │ Spec Ran:     app.cy.ts                                                                        │  
  └────────────────────────────────────────────────────────────────────────────────────────────────┘  


\===================================================================================  

  (Run Finished)  


       Spec                                              Tests  Passing  Failing  Pending  Skipped    
  ┌────────────────────────────────────────────────────────────────────────────────────────────────┐  
  │ ✔  app.cy.ts                                869ms        2        2        -        -        - │  
  └────────────────────────────────────────────────────────────────────────────────────────────────┘  
    ✔  All specs passed!                        869ms        2        2        -        -        -    


 —————————————————————————————————————————————————————————————————————————————————  

 >  NX   Successfully ran target e2e for project cats-cypress (15s)

Add Playwright

Alternatively, I can use Playwright to e2e test.

In this section, I am going to go through:

When I already have an existing Nx Workspace, how do I add the Expo and Playwright projects?
When I already have an existing Nx Expo app, how do I add the Playwright tests to my app?

Add a new Expo App in an Nx Workspace

In any Nx workspace, I can install @nx/expo by running the following command:

npx nx add @nx/expo

Now when I generate a new Expo app, I can simply use @nx/expo:application generator with the flag --e2eTestRunner=playwright:

npx nx generate @nx/expo:app --e2eTestRunner=playwright

It should create the expo app and its Playwright e2e tests.

Add Playwright to an Existing Nx Expo App

Similarly to Cypress steps, before I start, I need to make sure I can serve my Expo app for the web view. In this example, in my apps/cats/project.json, I got a serve target defined:

   "serve": {  
      "executor": "@nx/expo:serve",  
      "options": {  
        "port": 8081  
      }  
    },

First, I need to install @nx/playwright:

npx nx add @nx/playwright

Second, I create a project.json for my Playwright project. In this example, I create a project.json at apps/cats-playwright/project.json, I name the project cats-playwright:

{  
  "name": "cats-playwright"  
}

Third, run the below command to generate Cypress configuration:

npx nx g @nx/playwright:configuration --project cats-playwright --webServerCommand "nx run cats:serve" --webServerAddress http://localhost:8081

Since the serve command is npx nx run cats:serve, so the flag is --webServerCommand is nx run cats:serve. Also, the --webServerAddress is [http://localhost:8081](http://localhost:8081.).

It should generate playwright.config.ts and a sample test file:

For this example, I change the example test at apps/cats-playwright/e2e/example.spec.ts to:

import { test, expect } from '@playwright/test';  

test('has title', async ({ page }) => {  
  await page.goto('/');  

  // Expect h1 to contain a substring.  
  expect(await page.locator('h1').innerText()).toContain('Cat Facts');  
});

Run command npx nx run cats-playwright:e2e, and the tests should pass:

Add Storybook

To add the storybook, simply run the command:

npx nx generate @nx/react:storybook-configuration <your expo app name>

In this example, I should see in the console output:

npx nx g @nx/react:storybook-configuration cats  

>  NX  Generating @nx/react:storybook-configuration  

✔ Do you want to set up Storybook interaction tests? (Y/n) · true  
✔ Automatically generate \*.stories.ts files for components declared in this project? (Y/n) · true  

✔ Configure a static file server for the storybook instance? (Y/n) · true  
UPDATE nx.json  
UPDATE package.json  
CREATE apps/cats/.storybook/main.ts  
CREATE apps/cats/.storybook/preview.ts  
CREATE apps/cats/tsconfig.storybook.json  
UPDATE apps/cats/tsconfig.app.json  
UPDATE apps/cats/tsconfig.json  
UPDATE apps/cats/project.json  
CREATE apps/cats/src/app/App.stories.tsx  
CREATE apps/cats/src/app/bookmarks/bookmarks.stories.tsx  
CREATE apps/cats/src/app/facts/facts.stories.tsx

That is it! In one single, it should generate the Storybook for me. Run the command to see Storybook in web view:

npx nx run <your-expo-app>:storybook

It interpolates my native UI components to web components and then creates the Storybook. How does it achieve that?

In this example, it generates a file apps/cats/.storybook/main.ts:

import type { StorybookConfig } from '@storybook/react-webpack5';  

const config: StorybookConfig = {  
  stories: \['../src/lib/\*\*/\*.stories.@(js|jsx|ts|tsx|mdx)'\],  
  addons: \[  
    '@storybook/addon-essentials',  
    '@storybook/addon-interactions',  
    '@nx/react/plugins/storybook',  
  \],  
  framework: {  
    name: '@storybook/react-webpack5',  
    options: {},  
  },  
  webpackFinal: async (config) => {  
    if (config.resolve) {  
      config.resolve.alias = {  
        ...config.resolve.alias,  
        'react-native$': 'react-native-web',  
      };  
      config.resolve.extensions = \[  
        '.web.tsx',  
        '.web.ts',  
        '.web.jsx',  
        '.web.js',  
        ...(config.resolve.extensions ?? \[\]),  
      \];  
    }  
    return config;  
  },  
};  

export default config;  

// To customize your webpack configuration you can use the webpackFinal field.  
// Check https://storybook.js.org/docs/react/builders/webpack#extending-storybooks-webpack-config  
// and https://nx.dev/recipes/storybook/custom-builder-configs

Notice there is a line:

      config.resolve.alias = {  
        ...config.resolve.alias,  
        'react-native$': 'react-native-web',  
      };

It uses Webpack to bundle and alias react-native to react-native-web.

When serving up my Storybook for the first time, I have some issues and problems preventing components from rendering. Below are the issues I run into and how I troubleshoot them.

Troubleshooting

Root Element

“Full-screen React Native apps with a root <ScrollView> may require the following styles inlined in the HTML document shell.” (https://necolas.github.io/react-native-web/docs/setup/#root-element).

In this example, I do have a root element, so I need to add styles to apps/cats/.storybook/preview-head.html to make my root full height:

<style type="text/css">  
  /\* These styles make the body full-height \*/  
  html,  
  body {  
    height: 100%;  
  }  
  /\* These styles disable body scrolling if you are using <ScrollView> \*/  
  body {  
    overflow: hidden;  
  }  
  /\* These styles make the root element full-height \*/  
  #storybook-root {  
    display: flex;  
    height: 100%;  
  }  
</style>

Error: Couldn’t find a navigation object.

Because I am using the library @react-navigation/native and I use its hooks like useNavigtion and useRoute inside my component, I have this error:

The easiest way is just to mock this library and create a decorator for it. In this example, I create a Navigation Decorator at apps/cats/.storybook/mocks/navigation-decorator.tsx:

import { NavigationContainer } from '@react-navigation/native';  
import React from 'react';  

export const NavigationDecorator = (story: any) => {  
  return (  
    <NavigationContainer independent={true}>{story()}</NavigationContainer>  
  );  
};

Then I can add this decoration to my story file. In this example, I add it to apps/cats/src/app/bookmarks/bookmarks.stories.tsx:

import type { Meta, StoryObj } from '@storybook/react';  
import { Bookmarks } from './bookmarks';  

import { within } from '@storybook/testing-library';  
import { expect } from '@storybook/jest';  
import { NavigationDecorator } from '../../../.storybook/mocks/navigation-decorator';  

const meta: Meta<typeof Bookmarks> = {  
  component: Bookmarks,  
  title: 'Bookmarks',  
  decorators: NavigationDecorator, // <---- add the decorator here  
};  
export default meta;  
type Story = StoryObj<typeof Bookmarks>;  

export const Primary = {  
  args: {},  
};  

export const Heading: Story = {  
  args: {},  
  play: async ({ canvasElement }) => {  
    const canvas = within(canvasElement);  
    expect(canvas.getByText(/Welcome to Bookmarks!/gi)).toBeTruthy();  
  },  
};

Error: Couldn’t find a route object.

This issue is similar to “Couldn’t find a navigation object”, it is also related to the library @react-navigation/native.

It happens because my component is using the useRoute hook and expecting certain routing parameters. I simply need to customize the mock NavigationDecorator for my component. For example, below is a component that is expecting an id from the route parameters:

const route = useRoute<RouteProp<{ params: { id: string } }>>();  
const id = route.params?.id;

I can simply modify the mock NavigationDecorator at apps/cats/.storybook/mocks/navigation-decorator.tsx:

import { NavigationContainer } from '@react-navigation/native';  
import { createNativeStackNavigator } from '@react-navigation/native-stack';  
import React from 'react';  

export const NavigationDecorator = (story: any) => {  
  const Stack = createNativeStackNavigator();  
  return (  
    <NavigationContainer independent={true}>  
      <Stack.Navigator>  
        <Stack.Screen  
          name="MyStorybookScreen"  
          component={story}  
          initialParams={{ id: 123 }}  
        />  
      </Stack.Navigator>  
    </NavigationContainer>  
  );  
};

Error: No QueryClient set, use QueryClientProvider to set one

This happens because I use the library @tanstack/react-query. I need to create a decorator for QueryClientProvider. At apps/cats/.storybook/mocks/query-client-decorator.tsx, I create this decorator:

import { QueryClient, QueryClientProvider } from '@tanstack/react-query';  
import React from 'react';  

export const QueryClientDecorator = (story: any) => {  
  const queryClient = new QueryClient();  
  return (  
    <QueryClientProvider client={queryClient}>{story()}</QueryClientProvider>  
  );  
};  

export default QueryClientDecorator;

In this example, my story at apps/cats/src/app/facts/facts.stories.tsx will become:

import type { Meta, StoryObj } from '@storybook/react';  
import { Facts } from './facts';  

import { within } from '@storybook/testing-library';  
import { expect } from '@storybook/jest';  
import { NavigationDecorator } from '../../../.storybook/mocks/navigation-decorator';  
import { QueryClientDecorator } from '../../../.storybook/mocks/query-client-decorator';  

const meta: Meta<typeof Facts> = {  
  component: Facts,  
  title: 'Facts',  
  decorators: \[NavigationDecorator, QueryClientDecorator\], // <---- add the QueryClientDecorator here  
};  
export default meta;  
type Story = StoryObj<typeof Facts>;  

export const Primary = {  
  args: {},  
};  

export const Heading: Story = {  
  args: {},  
  play: async ({ canvasElement }) => {  
    const canvas = within(canvasElement);  
    expect(canvas.getByText(/Welcome to Facts!/gi)).toBeTruthy();  
  },  
};

Error: Unable to load react-native-vector-icons.

I got this error when I tried to compile the storybook:

You may need an additional loader to handle the result of these loaders.  
|   
|       return (  
>         <Text selectable={false} {...props}>  
|           {glyph}  
|           {children}  
 @ ./node\_modules/react-native-vector-icons/MaterialCommunityIcons.js 6:0-50 9:16-29  
 @ ./node\_modules/react-native-paper/lib/module/components/MaterialCommunityIcon.js 8:27-94  
 @ ./node\_modules/react-native-paper/lib/module/core/PaperProvider.js 3:0-72 73:12-33  
 @ ./node\_modules/react-native-paper/lib/module/index.js 4:0-59 4:0-59 5:0-64 5:0-64  
 @ ./apps/cats/src/app/App.tsx 1:717-760 1:1882-1892  
 @ ./apps/cats/src/app/ lazy ^\\.\\/.\*$ namespace object ./App.tsx ./App  
 @ ./storybook-stories.js 1:383-427  
 @ ./storybook-config-entry.js 1:171-216 1:1789-1797 1:1871-1985 1:1926-1984 1:1972-1980

This happens because I use the library react-native-paper which depends on react-native-vector-icons.

In react-native-vector-icons, it .js files contain jsx code: <Text selectable={false} {…props}>. To solve this, I need to load the react-native-vector-icons library using babel-loader. In this example, I can add a rule to Storybook’s Webpack config:

        config.module.rules.push({  
          test: /\\.(js|jsx)$/,  
          include: /react-native-vector-icons/,  
          loader: 'babel-loader',  
          options: {  
            presets: \[  
              '@babel/preset-env',  
              \['@babel/preset-react', { runtime: 'automatic' }\],  
            \],  
          },  
        });

Then I need to also load the font MaterialCommunityIcons.ttf for Storybook:

Download the font from https://github.com/oblador/react-native-vector-icons/blob/master/Fonts/MaterialCommunityIcons.ttf to apps/cats/.storybook/public.
Add staticDirs option to Storybook configuration at apps/cats/.storybook/main.ts:

staticDirs: \['./public'\],

Add the below style to apps/cats/.storybook/preview-head.html to load the font:

<style type="text/css">  
  @font-face {  
    font-family: 'MaterialCommunityIcons';  
    src: url('/MaterialCommunityIcons.ttf') format('truetype');  
  }  
</style>

The Storybook configuration at apps/cats/.storybook/main.ts will become:

import type { StorybookConfig } from '@storybook/react-webpack5';  

const config: StorybookConfig = {  
  stories: \['../src/app/\*\*/\*.stories.@(js|jsx|ts|tsx|mdx)'\],  
  staticDirs: \['./public'\],  
  addons: \[  
    '@storybook/addon-essentials',  
    '@storybook/addon-interactions',  
    '@nx/react/plugins/storybook',  
  \],  
  framework: {  
    name: '@storybook/react-webpack5',  
    options: {},  
  },  
  webpackFinal: async (config) => {  
    if (config.resolve) {  
      config.resolve.alias = {  
        ...config.resolve.alias,  
        'react-native$': 'react-native-web',  
      };  
      config.resolve.extensions = \[  
        '.web.tsx',  
        '.web.ts',  
        '.web.jsx',  
        '.web.js',  
        ...(config.resolve.extensions ?? \[\]),  
      \];  
      if (config.module?.rules) {  
        config.module.rules.push({  
          test: /\\.(js|jsx)$/,  
          include: /react-native-vector-icons/,  
          loader: 'babel-loader',  
          options: {  
            presets: \[  
              '@babel/preset-env',  
              \['@babel/preset-react', { runtime: 'automatic' }\],  
            \],  
          },  
        });  
      }  
    }  
    return config;  
  },  
};  

export default config;  

// To customize your webpack configuration you can use the webpackFinal field.  
// Check https://storybook.js.org/docs/react/builders/webpack#extending-storybooks-webpack-config  
// and https://nx.dev/recipes/storybook/custom-builder-configs

Now I can see react-native-vector-icons are being loaded correctly for the Storybook.

Now I can run npx nx run cats:storybook and it should render the storybook for me.

Summary

In this article, you have learned how to add Cypress, Playwright, and Storybook to your Nx Expo app.

With Nx, it will help you with your Expo development process.

Learn more

Unit Testing Expo Apps With Jest

Emily Xiong — Mon, 19 Feb 2024 19:11:00 +0000

In my latest blog, I successfully navigated through the steps of setting up an Expo Monorepo with Nx. The next challenge? Testing! This blog dives into:

Crafting effective unit tests for Expo components utilizing Jest
Addressing common issues encountered during unit testing

Repo:

xiongemi / nx-expo-monorepo

a repo showing 2 apps created by @nx/expo

NxExpoMonorepo

This workspace is created using @nx/expo (Nx and Expo).

✨ This workspace has been generated by Nx, a Smart, fast and extensible build system. ✨

Workspace structure

It contains 2 apps:

cats and its e2e (cypress/playwright)
dogs and its e2e (cypress/playwright)

4 libs:

models
queries: tanstack react-query
states: redux state management
ui

Commands

nx start cats to start the cats app
nx start dogs to start the dogs app
nx build cats to build the cats app using EAS
nx build dogs to build the dogs app using EAS
nx test cats to test the cats app
nx test dogs to test the dogs app
nx lint cats to lint the cats app
nx lint dogs to lint the dogs app
npm run deploy to deploy the cats app to github page
nx e2e cats-cypress to run cypress e2e tests on cats app
nx e2e cats-playwright to…

View on GitHub

Stacks

Here’s my setup

Testing framework: jest
Testing library: @testing-library/react-native
Jest Preset: jest-expo

Writing and Running Unit Tests

When you use Nx, it not only configures and sets up Jest, but also creates a default unit test for every expo component that is being generated. Here’s what that looks like:

import { render } from '@testing-library/react-native';  
import React from 'react';  

import Loading from './loading';  

describe('Loading', () => {  
  it('should render successfully', () => {  
    const { root } = render(<Loading />);  
    expect(root).toBeTruthy();  
  });  
});

To run all unit tests for a given project, use:

npx nx test <project-name>

Here’s the output of running this for my example app:

When it comes to writing tests, the React Native Testing Library is a game-changer for writing cleaner unit tests in React Native applications. Its intuitive query API simplifies the process of selecting elements within your components, making it straightforward to write more maintainable and readable tests. You mark elements with a testID

<Headline testID='title'>{film.title}</Headline>

Then in the test file, you can use the function getByTestId to query testID:

const { getByTestId } = render(<your component>);  
expect(getByTestId('title')).toHaveTextContent(...);

You can find more options for querying elements on the official React Native Testing Library docs: https://callstack.github.io/react-native-testing-library/docs/api-queries.

Troubleshooting Common Issues When Writing Tests

However, unit tests do not always pass. Here are some common errors I ran into and how to resolve them.

Error: AsyncStorage is null.

I am using the library @react-native-async-storage/async-storage, and I got the below error when running unit testing:

 \[@RNC/AsyncStorage\]: NativeModule: AsyncStorage is null.  

    To fix this issue try these steps:  

      • Rebuild and restart the app.  

      • Run the packager with \`--reset-cache\` flag.  

      • If you are using CocoaPods on iOS, run \`pod install\` in the \`ios\` directory and then rebuild and re-run the app.  

      • If this happens while testing with Jest, check out docs how to integrate AsyncStorage with it: https://react-native-async-storage.github.io/async-storage/docs/advanced/jest  

    If none of these fix the issue, please open an issue on the Github repository: https://github.com/react-native-async-storage/async-storage/issues  

       5 | import { ReactQueryDevtools } from '@tanstack/react-query-devtools';  
       6 | import { Platform } from 'react-native';  
    >  7 | import AsyncStorage from '@react-native-async-storage/async-storage';

The issue is that @react-native-async-storage/async-storage library can only be used in NativeModule. Since unit testing with Jest only tests JS/TS file logic, I need to mock this library.

In the app’s test-setup.ts file, add the below lines:

jest.mock('@react-native-async-storage/async-storage', () =>  
  require('@react-native-async-storage/async-storage/jest/async-storage-mock')  
);

Error: Could not find “store”

I am using Redux for state management, and I got this error for my stateful components:

Could not find "store" in the context of "Connect(Bookmarks)". Either wrap the root component in a <Provider>, or pass a custom React context provider to <Provider> and the corresponding React context consumer to Connect(Bookmarks) in connect options.

To fix this, the simple way is to mock a redux store. I need to install redux-mock-store and its typing:

\# npm  
npm install redux-mock-store @types/redux-mock-store --save-dev  

\# yarn  
yarn add redux-mock-store @types/redux-mock-store --dev

Then I can create a mock store using this library like the below code:

import configureStore, { MockStoreEnhanced } from 'redux-mock-store';  

  const mockStore = configureStore<any>(\[\]);  

  let store: MockStoreEnhanced<any>;  

  beforeEach(() => {  
    store = mockStore({});  
    store.dispatch = jest.fn();  
  });

For example, one of my stateful components’ unit test will become:

import React from 'react';  
import { render } from '@testing-library/react-native';  
import { Provider } from 'react-redux';  
import configureStore, { MockStoreEnhanced } from 'redux-mock-store';  
import { RootState, initialRootState } from '@nx-expo-monorepo/states/cat';  

import Bookmarks from './bookmarks';  

describe('Bookmarks', () => {  
  const mockStore = configureStore<RootState>(\[\]);  

  let store: MockStoreEnhanced<RootState>;  

  beforeEach(() => {  
    store = mockStore(initialRootState);  
    store.dispatch = jest.fn();  
  });  

  it('should render successfully', () => {  
    const { container } = render(  
      <Provider store={store}>  
        <Bookmarks />  
      </Provider>  
    );  
    expect(container).toBeTruthy();  
  });  
});

The above code will apply the initial redux state to my components.

Error: No QueryClient set

Because I use TanStack Query , when I run unit tests, I have this error:

No QueryClient set, use QueryClientProvider to set one

This error occurred because I used useQuery from @tanstack/react-query in my component; however, in this unit test, the context of this hook is not provided.

To solve this, I can just mock the useQuery function:

import \* as ReactQuery from '@tanstack/react-query';  

jest.spyOn(ReactQuery, 'useQuery').mockImplementation(  
  jest.fn().mockReturnValue({  
    data: 'random cat fact',  
    isLoading: false,  
    isSuccess: true,  
    refetch: jest.fn(),  
    isFetching: false,  
    isError: false,  
  })  
);

Error: Couldn’t find a navigation object

If you use @react-navigation library for navigation, and inside your component, there are hooks from this library like useNavigation and useRoute, you are likely to get this error:

Couldn't find a navigation object. Is your component inside NavigationContainer?

The fix this, I need to mock the @react-nativgation/native library. In the app’s test-setup.ts file, I need to add:

jest.mock('@react-navigation/native', () => {  
  return {  
    useNavigation: () => ({  
      navigate: jest.fn(),  
      dispatch: jest.fn(),  
      setOptions: jest.fn()  
    }),  
    useRoute: () => ({  
      params: {  
        id: '123',  
      },  
    }),  
  };  
});

SyntaxError: Unexpected token ‘export’

I got this error when using a library with ECMAScript Module (ESM), such as [udid](https://github.com/uuidjs/uuid):

 /Users/emilyxiong/Code/nx-expo-monorepo/node\_modules/uuid/dist/esm-browser/index.js:1  
    ({"Object.<anonymous>":function(module,exports,require,\_\_dirname,\_\_filename,jest){export { default as v1 } from './v1.js';  
                                                                                      ^^^^^^  

    SyntaxError: Unexpected token 'export'  

       5 | import { connect } from 'react-redux';  
       6 | import 'react-native-get-random-values';  
    >  7 | import { v4 as uuidv4 } from 'uuid';

Jest does not work with ESM out of the box. The simple solution is to map this library to the CommonJS version of this library.

In the app’s jest.config.ts, there should be an option called moduleNameMapper. The library I used is called uuid, so I need to add the map uuid: require.resolve(‘uuid’) under moduleNameMapper. So when the code encounters imports from uuid library, it will resolve the CommonJS version of it:

module.exports = {  
  moduleNameMapper: {  
    uuid: require.resolve('uuid'),  
  },  
}

Alternatively, I can also mock this library in the test files:

import {v4 as uuidv4} from 'uuid';  

jest.mock('uuid', () => {  
  return {  
    v4: jest.fn(() => 1)  
  }  
})

Error: Jest encountered an unexpected token

I got this error when I was importing from a library such as react-native-vector-icons:

 console.error  
      Jest encountered an unexpected token  

      Jest failed to parse a file. This happens e.g. when your code or its dependencies use non-standard JavaScript syntax, or when Jest is not configured to support such syntax.  

      Out of the box Jest supports Babel, which will be used to transform your files into valid JS based on your Babel configuration.  

      By default "node\_modules" folder is ignored by transformers.  

      Here's what you can do:  
       • If you are trying to use ECMAScript Modules, see https://jestjs.io/docs/ecmascript-modules for how to enable it.  
       • If you are trying to use TypeScript, see https://jestjs.io/docs/getting-started#using-typescript  
       • To have some of your "node\_modules" files transformed, you can specify a custom "transformIgnorePatterns" in your config.  
       • If you need a custom transformation specify a "transform" option in your config.  
       • If you simply want to mock your non-JS modules (e.g. binary assets) you can stub them out with the "moduleNameMapper" config option.  

      You'll find more details and examples of these config options in the docs:  
      https://jestjs.io/docs/configuration  
      For information about custom transformations, see:  
      https://jestjs.io/docs/code-transformation

To fix this, add this library name to transformIgnorePatterns in the app's jest.config.ts.

What is transformIgnorePatterns? The transformIgnorePatterns allows developers to specify which files shall be transformed by Babel. transformIgnorePatterns is an array of regexp pattern strings that should be matched against all source file paths before the transformation. If the file path matches any patterns, it will not be transformed by Babel.

By default, Jest will ignore all the files under node_modules and only transform the files under the project’s src.

However, some libraries such as react-native-paper or react-native-svg, the library files are in .ts or .tsx. These files are not compiled to js. So I need to add these libraries' names to transformIgnorePatterns, so these libraries will be transformed by Babel along with my project. source file. The default generated jest.config.js already has:

transformIgnorePatterns: \[  
    'node\_modules/(?!((jest-)?react-native|@react-native(-community)?)|expo(nent)?|@expo(nent)?/.\*|@expo-google-fonts/.\*|react-navigation|@react-navigation/.\*|@unimodules/.\*|unimodules|sentry-expo|native-base|react-native-svg)',  
\]

If I have an error related to a library with an unexpected token, I need to check whether they are compiled or not.

If this library source files are already transformed to .js, then its name should match regex, so it would be ignored, so it will NOT be transformed.
If this library source files are NOT transformed to .js (e.g. still in .ts or .tsx), then its name should NOT match regex, so it will be transformed.

Summary

Here are some common errors that I will probably run into while doing unit testing. The solution to most problems is to find a way to mock a library that is not relevant to my component logic.

With Nx, you do not need to explicitly install any testing library, so you can dive right in and focus on writing the tests rather than spending time on setup.

Learn more

Add Cypress, Playwright, and Storybook to Nx Expo Apps
🧠 Nx Docs
👩‍💻 Nx GitHub
💬 Nx Community Discord
📹 Nx Youtube Channel
🚀 Speed up your CI

State Management Nx React Native/Expo Apps with TanStack Query and Redux

Emily Xiong — Fri, 16 Feb 2024 23:21:05 +0000

There are currently countless numbers of state management libraries out there. This blog will show you how to use state management for React Native in Nx monorepo with TanStack Query (which happens to use Nx on their repo) and Redux.

This blog will show:

How to set up these libraries and their dev tools
How to build the sample page below in React Native / Expo with state management
How to do unit testing

It will call an API and show a cat fact on the page, allowing users to like or dislike the data.

Github repo:

xiongemi / nx-expo-monorepo

a repo showing 2 apps created by @nx/expo

NxExpoMonorepo

This workspace is created using @nx/expo (Nx and Expo).

✨ This workspace has been generated by Nx, a Smart, fast and extensible build system. ✨

Workspace structure

It contains 2 apps:

cats and its e2e (cypress/playwright)
dogs and its e2e (cypress/playwright)

4 libs:

models
queries: tanstack react-query
states: redux state management
ui

Commands

nx start cats to start the cats app
nx start dogs to start the dogs app
nx build cats to build the cats app using EAS
nx build dogs to build the dogs app using EAS
nx test cats to test the cats app
nx test dogs to test the dogs app
nx lint cats to lint the cats app
nx lint dogs to lint the dogs app
npm run deploy to deploy the cats app to github page
nx e2e cats-cypress to run cypress e2e tests on cats app
nx e2e cats-playwright to…

View on GitHub

Before We Start

From TanStack Query documentation, it says:

TanStack Query is a server-state library.
Redux is a client-state library.

What is the difference between the server state and the client state?

In short:

Calling an API, dealing with asynchronous data-> server state
Everything else about UI, dealing with synchronous data -> client state

Installation

To use TanStack Query / React Query for the server state, I need to install:

Library: @tanstack/react-query
Dev tools: @tanstack/react-query-devtools

I will use Redux for everything else.

Library: redux, react-redux, @reduxjs/toolkit
Dev tools: @redux-devtools/extension
Logger: redux-logger, @types/redux-logger
Storage: redux-persist, @react-native-async-storage/async-storage

To install all the above packages:

#npm  
npm install @tanstack/react-query @tanstack/react-query-devtools redux react-redux @reduxjs/toolkit @redux-devtools/extension redux-logger @types/redux-logger redux-persist @react-native-async-storage/async-storage --save-dev  

#yarn  
yarn add @tanstack/react-query @tanstack/react-query-devtools redux react-redux @reduxjs/toolkit @redux-devtools/extension redux-logger @types/redux-logger redux-persist @react-native-async-storage/async-storage --dev  

#pnpm  
pnpm add @tanstack/react-query @tanstack/react-query-devtools redux react-redux @reduxjs/toolkit @redux-devtools/extension redux-logger @types/redux-logger redux-persist @react-native-async-storage/async-storage --save-dev

Server State with React Query

Setup Devtools

First, you need to add React Query / TanStack Query in the App.tsx:

import React from 'react';  
import { QueryClient, QueryClientProvider } from '@tanstack/react-query';  
import { ReactQueryDevtools } from '@tanstack/react-query-devtools';  
import { Platform } from 'react-native';  

const App = () => {  
  const queryClient = new QueryClient();  
  return (  
    <QueryClientProvider client={queryClient}>  
      { Platform.OS === 'web' && <ReactQueryDevtools />}  
      ...  
    </QueryClientProvider>  
  );  
};  

export default App;

Note: the React Query Devtools currently do not support react native, and it only works on the web, so there is a condition: { Platform.OS === ‘web’ && <ReactQueryDevtools />}.

For the react native apps, in order to use this tool, you need to use react-native-web to interpolate your native app to the web app first.

If you open my Expo app on the web by running nx start cats and choose the options Press w │ open web, you should be able to use the dev tools and see the state of my react queries:

Create a Query

What is a query?

“A query is a declarative dependency on an asynchronous source of data that is tied to a unique key. A query can be used with any Promise-based method (including GET and POST methods) to fetch data from a server.” (https://tanstack.com/query/v4/docs/react/guides/queries)

Now let’s add our first query. In this example, it will be added underlib/queries folder. To create a query to fetch a new fact about cats, run the command:

# expo workspace  
npx nx generate @nx/expo:lib use-cat-fact --directory=queries  

# react-native workspace  
npx nx generate @nx/react-native:lib use-cat-fact --directory=queries

Or use Nx Console:

Now notice under libs folder, use-cat-fact folder got created under libs/queries:

If you use React Native CLI, just add a folder in your workspace root.

For this app, let’s use this API: https://catfact.ninja/. At libs/queries/use-cat-fact/src/lib/use-cat-fact.ts, add code to fetch the data from this API:

import { useQuery } from '@tanstack/react-query';  

export const fetchCatFact = async (): Promise<string> => {  
  const response = await fetch('https://catfact.ninja/fact');  
  const data = await response.json();  
  return data.fact;  
};  

export const useCatFact = () => {  
  return useQuery({  
    queryKey: \['cat-fact'\],  
    queryFn: fetchCatFact,  
    enabled: false,  
  });  
};

Essentially, you have created a custom hook that calls useQuery function from the TanStack Query library.

Unit Testing

If you render this hook directly and run the unit test with the command npx nx test queries-use-cat-fact, this error will show up in the console:

 Invalid hook call. Hooks can only be called inside of the body of a function component. This could happen for one of the following reasons:  
    1. You might have mismatching versions of React and the renderer (such as React DOM)  
    2. You might be breaking the Rules of Hooks  
    3. You might have more than one copy of React in the same app  
    See https://reactjs.org/link/invalid-hook-call for tips about how to debug and fix this problem.

To solve this, you need to wrap your component inside the renderHook function from @testing-library/react-native library:

1. Install Library to Mock Fetch

Depending on which library you use to make HTTP requests. (e.g. fetch, axios), you need to install a library to mock the response.

If you use fetch to fetch data, you need to install jest-fetch-mock.
If you use axios to fetch data, you need to install axios-mock-adapter.

For this example, since it uses fetch, you need to install jest-fetch-mock:

#npm  
npm install jest-fetch-mock --save-dev  

#yarn  
yard add jest-fetch-mock --dev

You also need to mock fetch library in libs/queries/use-cat-fact/test-setup.ts:

import fetchMock from 'jest-fetch-mock';  

fetchMock.enableMocks();

2. Create Mock Query Provider

To test out useQuery hook, you need to wrap it inside a mock QueryClientProvider. Since this mock query provider is going to be used more than once, let’s create a library for this wrapper:

# expo library  
npx nx generate @nx/expo:library test-wrapper --directory=queries  

# react native library  
npx nx generate @nx/react-native:library test-wrapper --directory=queries

Then a component inside this library:

# expo library  
npx nx generate @nx/expo:component test-wrapper --project=queries-test-wrapper  

# react native library  
npx nx generate @nx/react-native:component test-wrapper --project=queries-test-wrapper

Add the mock QueryClientProvider in libs/queries/test-wrapper/src/lib/test-wrapper/test-wrapper.tsx:

import { QueryClient, QueryClientProvider } from '@tanstack/react-query';  
import React from 'react';  

export interface TestWrapperProps {  
  children: React.ReactNode;  
}  

export function TestWrapper({ children }: TestWrapperProps) {  
  const queryClient = new QueryClient();  
  return (  
    <QueryClientProvider client={queryClient}>{children}</QueryClientProvider>  
  );  
}  

export default TestWrapper;

3. Use Mock Responses in Unit Test

Then this is what the unit test for my query would look like:

import { TestWrapper } from '@nx-expo-monorepo/queries/test-wrapper';  
import { renderHook, waitFor } from '@testing-library/react-native';  
import { useCatFact } from './use-cat-fact';  
import fetchMock from 'jest-fetch-mock';  

describe('useCatFact', () => {  
  afterEach(() => {  
    jest.resetAllMocks();  
  });  

  it('status should be success', async () => {  
    // simulating a server response  
    fetchMock.mockResponseOnce(JSON.stringify({  
      fact: 'random cat fact',  
    }));  

    const { result } = renderHook(() => useCatFact(), {  
      wrapper: TestWrapper,  
    });  
    result.current.refetch(); // refetching the query  
    expect(result.current.isLoading).toBeTruthy();  

    await waitFor(() => expect(result.current.isLoading).toBe(false));  
    expect(result.current.isSuccess).toBe(true);  
    expect(result.current.data).toEqual('random cat fact');  
  });  

  it('status should be error', async () => {  
   fetchMock.mockRejectOnce();  

    const { result } = renderHook(() => useCatFact(), {  
      wrapper: TestWrapper,  
    });  
    result.current.refetch(); // refetching the query  
    expect(result.current.isLoading).toBeTruthy();  

    await waitFor(() => expect(result.current.isLoading).toBe(false));  
    expect(result.current.isError).toBe(true);  
  });  
});

If you use axios, your unit test would look like this:

import { TestWrapper } from '@nx-expo-monorepo/queries/test-wrapper';
import { renderHook, waitFor } from '@testing-library/react-native';
import { useCatFact } from './use-cat-fact';
import axios from 'axios';
import MockAdapter from 'axios-mock-adapter';

// This sets the mock adapter on the default instance
const mockAxios = new MockAdapter(axios);

describe('useCatFact', () => {
  afterEach(() => {
    mockAxios.reset();
  });

  it('status should be success', async () => {
    // simulating a server response
    mockAxios.onGet().replyOnce(200, {
      fact: 'random cat fact',
    });

    const { result } = renderHook(() => useCatFact(), {
      wrapper: TestWrapper,
    });
    result.current.refetch(); // refetching the query
    expect(result.current.isLoading).toBeTruthy();

    await waitFor(() => expect(result.current.isLoading).toBe(false));
    expect(result.current.isSuccess).toBe(true);
    expect(result.current.data).toEqual('random cat fact');
  });

  it('status should be error', async () => {
    mockAxios.onGet().replyOnce(500);

    const { result } = renderHook(() => useCatFact(), {
      wrapper: TestWrapper,
    });
    result.current.refetch(); // refetching the query
    expect(result.current.isLoading).toBeTruthy();

    await waitFor(() => expect(result.current.isLoading).toBe(false));
    expect(result.current.isError).toBe(true);
  });
});

Notice that this file imports TestWrapper from @nx-expo-monorepo/queries/test-wrapper, and it is added to renderHook function with { wrapper: TestWrapper }.

Now you run the test command nx test queries-use-cat-fact, it should pass:

 PASS   queries-use-cat-fact  libs/queries/use-cat-fact/src/lib/use-cat-fact.spec.ts (5.158 s)  
  useCatFact  
    ✓ status should be success (44 ms)  
    ✓ status should be error (96 ms)

Integrate with Component

Currently userQuery returns the following properties:

isLoading or status === 'loading' - The query has no data yet
isError or status === 'error' - The query encountered an error
isSuccess or status === 'success' - The query was successful and data is available

Now with components controlled by the server state, you can leverage the above properties and change your component to follow the below pattern:

export interface CarouselProps {  
  isError: boolean;  
  isLoading: boolean;  
  isSuccess: boolean;  
}  


export function Carousel({  
  isSuccess,  
  isError,  
  isLoading,  
}: CarouselProps) {  
  return (  
    <>  
      {isSuccess && (  
        ...  
      )}  
      {isLoading && (  
        ...  
      )}  
      {isError && (  
        ...  
      )}  
    </>  
  );  
}  

export default Carousel;

Then in the parent component, you can use the query created above:

import { useCatFact } from '@nx-expo-monorepo/queries/use-cat-fact';  
import { Carousel } from '@nx-expo-monorepo/ui';  
import React from 'react';  

export function Facts() {  
  const { data, isLoading, isSuccess, isError, refetch, isFetching } =  
    useCatFact();  

  return (  
    <Carousel  
      content={data}  
      isLoading={isLoading || isFetching}  
      isSuccess={isSuccess}  
      isError={isError}  
      onReload={refetch}  
    >  
    ...  
   );  
}

If you serve the app on the web and open the React Query Devtools, you should be able to see the query I created cat-fact and data in the query.

Redux

Create a Library

First, you need to create a library for redux:

# expo library  
npx nx generate @nx/expo:lib cat --directory=states  

# react native library  
npx nx generate @nx/react-native:lib cat --directory=states

This should create a folder under libs:

Create a State

This app is going to track when users click the like button, so you need to create a state called likes.

You can use the Nx Console to create a redux slice:

Or run this command:

npx nx generate @nx/react:redux likes --project=states-cat --directory=likes

Then update the redux slice at libs/states/cat/src/lib/likes/likes.slice.ts:

import {  
  createEntityAdapter,  
  createSelector,  
  createSlice,  
  EntityState,  
} from '@reduxjs/toolkit';  

export const LIKES\_FEATURE\_KEY = 'likes';  

export interface LikesEntity {  
  id: string;  
  content: string;  
  dateAdded: number;  
}  

export type LikesState = EntityState<LikesEntity>;  

export const likesAdapter = createEntityAdapter<LikesEntity>();  

export const initialLikesState: LikesState = likesAdapter.getInitialState();  

export const likesSlice = createSlice({  
  name: LIKES\_FEATURE\_KEY,  
  initialState: initialLikesState,  
  reducers: {  
    like: likesAdapter.addOne,  
    remove: likesAdapter.removeOne,  
    clear: likesAdapter.removeAll,  
  },  
});  

/\*  
 \* Export reducer for store configuration.  
 \*/  
export const likesReducer = likesSlice.reducer;  

export const likesActions = likesSlice.actions;  

const { selectAll } = likesAdapter.getSelectors();  

const getlikesState = <ROOT extends { likes: LikesState }>(  
  rootState: ROOT  
): LikesState => rootState\[LIKES\_FEATURE\_KEY\];  

const selectAllLikes = createSelector(getlikesState, selectAll);  

export const likesSelectors = {  
  selectAllLikes,  
};

Every time the “like” button gets clicked, you want to store the content of what users liked. So you need to create an entity to store this information.

export interface LikesEntity {  
  id: string;  
  content: string;  
  dateAdded: number;  
}

This state has 3 actions:

like: when users click like
remove: when users cancel the like
clear: when users clear all the likes

Root Store

Then you have to add the root store and create a transform function to stringify the redux state:

Connect Redux State with UI

Then in apps/cats/src/app/App.tsx, you have to:

wrap the app inside the StoreProvider with the root store to connect with the Redux state.
wrap the app inside PersistGate to persist the redux state in the storage

import React from 'react';  
import AsyncStorage from '@react-native-async-storage/async-storage';  
import { PersistGate } from 'redux-persist/integration/react';  
import { createRootStore, transformEntityStateToPersist } from '@nx-expo-monorepo/states/cat';  
import { Loading } from '@nx-expo-monorepo/ui';  
import { Provider as StoreProvider } from 'react-redux';  

const App = () => {  

  const persistConfig = {  
    key: 'root',  
    storage: AsyncStorage,  
    transforms: \[transformEntityStateToPersist\],  
  };  
  const { store, persistor } = createRootStore(persistConfig);  

  return (  
    <PersistGate loading={<Loading />} persistor={persistor}>  
      <StoreProvider store={store}>  
        ...  
      </StoreProvider>  
    </PersistGate>  
  );  
};  

export default App;

In your component where the like button is located, you need to dispatch the like action. I created a file at apps/cats/src/app/facts/facts.props.ts:

import { likesActions, LikesEntity, RootState } from '@nx-expo-monorepo/states/cat';  
import { AnyAction, ThunkDispatch } from '@reduxjs/toolkit';  

const mapDispatchToProps = (  
  dispatch: ThunkDispatch<RootState, void, AnyAction>  
) => {  
  return {  
    like(item: LikesEntity) {  
      dispatch(likesActions.like(item));  
    },  
  };  
};  

type mapDispatchToPropsType = ReturnType<typeof mapDispatchToProps>;  

type FactsProps = mapDispatchToPropsType;  

export { mapDispatchToProps };  
export type { FactsProps };

Now you have passed the like function to the props of the facts component. Now inside the facts component, you can call the like function from props to dispatch the like action.

Debugging

To debug redux with Expo, I can simply open the Debugger Menu by entering “d” in the console or in the app, then choose the option “Open JS Debugger”.

Then you can view my redux logs in the JS Debugger console:

You can see the redux logs in console now:

Or you can run nx serve cats to launch the app in web view. Then you can use Redux Devtools and debug the native app like a web app:

Summary

Here is a simple app that uses TanStack Query and Redux for state management. These 2 tools are pretty powerful and they manage both server and client state for you, which is easy to scale, test, and debug.

Nx is a powerful monorepo tool. Together with Nx and these 2 state management tools, it will be very easy to scale up any app.

TanStack Query site: https://tanstack.com/query/latest
Official @nx/expo plugin: https://nx.dev/packages/expo
Official @nx/react-native plugin: https://nx.dev/packages/react-native

Learn more

Step-by-Step Guide to Creating an Expo Monorepo with Nx

Emily Xiong — Fri, 16 Feb 2024 22:19:07 +0000

This blog will show you how to create an Expo monorepo with Nx. In this example, you will be creating two Expo apps in a monorepo with @nx/expo: one shows random facts about cats, and the other shows random facts about dogs.

As shown in the above screenshots, these two apps have the same branding and reuse all components.

This blog will go through:

How to create a monorepo workspace with Nx
How to share a React Native library
How to build an Expo app
How to submit an Expo app to the app store

Github repo: https://github.com/xiongemi/nx-expo-monorepo

Creating an Nx Workspace

To create a new Nx workspace, run the command npx create-nx-workspace in the terminal. In this example, let’s name it nx-expo-monorepo:

✔ Where would you like to create your workspace? · create-nx-monorepo
✔ Which stack do you want to use? · react
✔ What framework would you like to use? · expo
✔ Application name · cats
✔ Enable distributed caching to make your CI faster · No

This will create an integrated repo. What is an integrated repo?

An integrated repo contains projects that depend on each other through standard import statements. There is typically a single version of every dependency defined at the root.
https://nx.dev/concepts/integrated-vs-package-based#integrated-repos

Now, your Nx workspace should have cats and cats-e2e under the apps folder and an empty libs folder:

Existing Nx Workspace

If you already have an Nx workspace, you need to install the @nx/expo package:

npx nx add @nx/expo

To create an Expo app, run:

npx nx generate @nx/expo:app cats

Alternatively, if you use Visual Studio Code as your code editor, you can also create apps using Nx Console:

Install Tech Stacks

Here are the tech stacks this example is going to use:

Material design library: react-native-paper

# npm  
npm install react-native-paper react-native-safe-area-context --save  

# yarn  
yarn add react-native-paper react-native-safe-area-context  

# pnpm  
pnpm add react-native-paper react-native-safe-area-context --save

Routing: @react-navigation/native

# npm  
npm install react-native-paper react-native-screens @react-navigation/native-stack --save  

# yarn  
yarn add react-native-paper react-native-screens @react-navigation/native-stack  

# pnpm  
pnpm add react-native-paper react-native-screens @react-navigation/native-stack --save

Create a Shareable UI Library

With all the required libraries installed, you need to create a sharable UI library:

npx nx generate @nx/expo:lib ui

Now under the libs folder, a ui folder has been created:

To create a component in the ui library, run:

npx nx generate @nx/expo:component carousel --project=ui --export

You can see that a carousel folder has been created in the libs/ui/src/lib folder:

Next, modify this component to display the content with props passed in:

Now you can use this component in your app directly using an import:

import { Carousel } from '@nx-expo-monorepo/ui';

Add Navigation

This project is going to use the stack navigator from @react-navigation/native. So the app needs to import from @react-navigation/stack. In apps/cats/src/app/App.tsx, you can change the UI to have one screen displaying a carousel with mock data:

Run the app with nx start cats, and you should be able to see the app on the simulator:

Page on the simulator (left: iOS, right: Android)

Add Another App

In this example, there is already a Cats app. To create the Dogs app, run the command:

npx nx generate @nx/expo:app dogs

Alternatively, if you use Visual Studio Code as your code editor, you can also create apps using Nx Console:

Under the apps folder, there should be cats/, dogs/ and their e2es.

You can reuse the UI library in the Dogs app in apps/dogs/src/app/App.tsx with the below code:

Build Expo Apps

EAS Build is a hosted service for building app binaries for your Expo and React Native projects. To set up EAS locally:

1. Install EAS CLI

EAS CLI is the command-line app to interact with EAS services in the terminal. To install it, run the command:

npm install -g eas-cli

2. Login To EAS

If you are not logged in, run the command:

eas login

3. Build the Apps

After the EAS setup, you can build apps by running the command:

npx nx build cats  
npx nx build dogs

There are different options you can specify with the build command. For example, you can specify the platform you want to build:

npx nx build cats --platform=all  
npx nx build cats --platform=android  
npx nx build cats --platform=ios

Alternatively, if you want to create a build to run on a simulator/emulator, you can run:

npx nx build cats --profile=preview

You can view your build status at https://expo.dev/:

If you want to create a build locally using your own infrastructure:

npx nx build cats --local

Here is the complete list of flags for the build command: https://nx.dev/packages/expo/executors/build.

Submit to the App Store

Before you submit, you need to have paid developer accounts for iOS and Android.

iOS: You need to create an Apple Developer account on the Apple Developer Portal.
Android: You need to create a Google Play Developer account on the Google Play Console sign-up page. You also need to manually create an app on Google Play Console and upload your app for the first time.

1. Run the production build

To submit to the app store, you can build the app by running:

npx nx build cats --profile=production

2. Submit the Build

You can manually upload the build bundle binary to the app store, or you can submit it through EAS.

First, in app.json under the project apps/cats/app.json, you need to make sureios.bundleIdentifier and android.package keys are correct:

To submit your app to the app stores, run:

npx nx submit cats

Nx will prompt you to choose the platform to which you want to submit:

Or you can also specify the platform directly in the initial command:

npx nx submit cats --platform=all  
npx nx submit cats --platform=android  
npx nx submit cats --platform=ios

It will then ask you to choose which binary to submit from one of the following options:

The latest finished Android build for the project on EAS servers.
Specific build ID. It can be found on the builds dashboard.
Path to an .apk or .aab or .ipa archive on your local filesystem.
URL to the app archive.

Alternatively, you can submit your app on the expo.dev site. Go to your build, under options, choose “Submit to an app store”:

Summary

In this article, you have learned how to:

Create multiple apps in a monorepo using @nx/expo
Create a shared library
Build your app using EAS
Submit your app to the App Store

With Nx, it is easy to create and scale up an Expo app. Even though this app is currently a simple 2-page app, you can easily scale it up with more libraries and components. Furthermore, you can also reuse those libraries in the future if you decide to add another app to the repo.

Learn more

Unit Testing Expo Apps With Jest
Add Cypress, Playwright, and Storybook to Nx Expo Apps
🧠 Nx Docs
👩‍💻 Nx GitHub
💬 Nx Community Slack
📹 Nx Youtube Channel
🚀 Speed up your CI

Launch Nx Week Recap!!

Zack DeRose — Thu, 15 Feb 2024 18:09:12 +0000

We just finished wrapping up Launch Nx Week, which ran from February 5-9, including a full conference on Thursday!

In this article, we're going to recap all the things launched during Launch Nx Conf, as well as all the talks given during the conference! Here's a set of links so you can fast-forward to the stuff you're most interested in if you want!

Nx 18.0 && Project Crystal
- Project Crystal - By Juri Strumpflohner
- Project Crystal + .NET in Action - By Craigory Coppola
New Plugin: @nx/nuxt
Nx Agents
- Nx Agents Walkthrough: Effortlessly Fast CI Built for Monorepos - By Rares Matei
- Solving E2E Tests - By Altan Stalker
Tusky
Nx Release
- Releasing Nx Release - By James Henry

Nx 18.0 && Project Crystal

Exciting news!! We've broken our standard release cadance of publishing a new major version every 6 months to release Nx 18, just 3 months after releasing Nx 17 in December 2024.

Juri announced launched Project Crystal with this video:

The short version is: Nx project crystal means Nx plugins make your codebases work more seemlessly with less config.

For the long version, checkout this blog post by Juri where he describes how Nx plugins are now more like VsCode Extentions!

And don't miss our two conference talks on this subject:

Conference Talk: Project Crystal

Speaker: Juri Strumpflohner | slides

Conference Talk: Project Crystal + .NET in Action

Speaker: Craigory Coppola | slides | example repo

New Plugin: @nx/nuxt

On Tuesday we launched our newest plugin, and our first plugin to be 💎crystalized💎 from it's very beginning: @nx/nuxt!

Zack explains Nuxt and how to use the new plugin in this video:

To add @nx/nuxt to your codebase, use the command:

> nx add @nx/nuxt

Huge thanks to Katerina for her work on the plugin, and Nuxt maintainer, Daniel Roe, for helping to guide the project!

Zack, Katerina, and Daniel got together to live code a working tic-tac-toe app using the new Nuxt plugin and partykit in this livestream:

Nx Agents Launched

Nx Agents are here!! We launched Nx Agents on Wednesday, and it climbed into the top 20 on Product Hunt!

We're very excited about Nx Agents because we think that in its current state, Continuous Integration/Deployment is broken, and we think that Nx paired with Nx Agents fixes Continuous Integration. Zack explains more in this video:

Be sure to also checkout the blog post from Isaac on the topic, including explanations of the Nx Agents exclusive features, like auto-detection and retrying for flaky tasks, and automatically splitting lengthy end-to-end tests!

You can signup for Nx Agents NOW, and find out more of the details in our docs!

Rares and Altan are on the team building Nx Cloud, and during the conference, they dove deeper into some of these topics:

Conference Talk: Nx Agents Walkthrough: Effortlessly Fast CI Built for Monorepos

Speaker: Rares Matei | slides | example repo | failed runs example | nx agents full run

Conference Talk: Solving E2E Tests

Speaker: Altan Stalker

Tusky

Thursday, we had a surprise announcement for our newest product on Nx Cloud: Tusky.

Tusky is an Artificial Intelligence for your codebase, and it will be available on Nx Cloud soon - starting in Spring of 2024.

In the teaser video, you can see some ways Tusky will be integrated into Nx Cloud to provide explainations on failed tasks, or cache misses.

The more exciting features of Tusky though includes the ability to perfectly optimize the number of agents used per PR - even spinning up and tearing down agents mid-pipeline! This is a huge optimization for task distribution, and will help optimize both walltime of your CI, as well as compute costs!

Tusky will also be able to provide organizational-level insights to your codebase, including automatically detecting development groups (like lines of business) inside your codebase based on commit history, and providing statistical insights on their commit patterns. We're also excited about Tusky being able to make suggestions on things you can do to further optimize your codebase - like generating a PR to introduce Codeowners to the repo!

Nx Release Is Stable

Versioning and publishing packages is always a bit tricky. Mix in the added complexity of having multiple packages - sometimes with different versioning or publishing strategies - inside the same codebase, and things can get weird quick!

For a long time, Nx has been purposefully versioning and publishing agnostic, but given our time spent as stewards of Lerna (the OG Javascript monorepo tool), we've been able to take alot of that experience and finally feel confident creating our own versioning and publishing implementation.

Therefore, we've been working on a new command to the Nx CLI: nx release. We launched this on Friday of our Launch Nx week!

Juri goes into full details in this blog post, and James Henry - our Director of Engineering and the primary engineer responsible for both maintaining Lerna and creating Nx Release - expands further in his conference talk:

Conference Talk: Releasing Nx Release

Speaker: James Henry | example repo

Wrapping up

Juri, Zack, and Victor wrapped up the week with a livestream recapping the launches from the week - including answering your questions live:

That’s all for now folks! We’re just starting up a new iteration of development on Nx, so be sure to subscribe to our YouTube channel to get updates when new features land! Until next time, KEEP WORKING HARD!

Learn more

Versioning and Releasing Packages in a Monorepo

Juri Strumpflohner — Fri, 09 Feb 2024 18:49:59 +0000

When it comes to publishing NPM packages, there are a bunch of libraries and utilities out there that help with the process. Many of them are tricky when it comes to properly configuring them in a monorepo.

Nx already has all that knowledge. About project dependencies and relationships and leverages that information already for optimizing your task runs.

Here's the structure of our current example workspace we're going to refer to in this article:

As you can see @tuskdesign/forms relies on @tuskdesign/buttons and as such has to consider that when running versioning and publishing.

Note, it is worth mentioning that the Nx community has also stepped up in the past and created jscutlery/semver, a package that adds semantic versioning and publishing to your Nx workspace. Make sure to check that out as well

Prefer a video?

Table of Contents

Adding Nx
- Installing the JavaScript/TypeScript versioning Package
Running Nx Release
Excluding Packages
Running the Versioning and Changelog Generation
Versioning using Conventional Commits
Generating a GitHub Release
Programmatic Mode
Wrapping Up
Learn more

Adding Nx

You can add Nx to your existing monorepo workspace using the following command:

pnpm dlx nx@latest init

(use npx nx@latest init in a NPM workspace)

This brings up a couple of questions. It'll also ask about installing Project Crystal plugins.

It gives you some additional benefits (you can read more here), but you don't have to as it is not required for Nx Release.

Installing the JavaScript/TypeScript versioning Package

Nx Release is made to handle the versioning and publishing of any package. For now, the Nx team provides the JS/TS package publishing approach, which comes with the @nx/js. You could provide your own implementation, like for Cargo, NuGet etc..

pnpm add @nx/js -w

(We use the -w flag to install it at the monorepo root level)

Running Nx Release

Once you're set-up, you can already go ahead and run the following command:

pnpm nx release --dry-run

This command will do the versioning, changelog generation, and publishing steps together. Note the --dry-run, simply simulating a run.

You'll get asked whether you want to release a major, pre-major, minor... release or choose an exact version.

Once this runs through, you might hit the following error:

Since Nx Release has never been run on this repository, it cannot figure out the historical information, for instance, to generate the changelog starting from previous git tags. Re-run the command with --first-release

pnpm nx release --dry-run --first-release

If you inspect the console output, you can see that:

it would increment the version in the package.json
update the pnpm (or npm) lockfile
stage the changes with git
creates a CHANGELOG.md file
git commits everything
git tags the commit using the version

The dry-run mode also nicely previews all package.json changes in a git diff style:

Note, if you want to get even more insights into what is happening when running the command, you can use the --verbose, which will also print the actual git commands.

Excluding Packages

If you look closely at the dry-run logs, you may notice that Nx Release bumped the version on all of our packages:

@tuskdesign/forms
@tuskdesign/buttons
@tuskdesign/demo

While we want to have it bumped on the forms and buttons packages, the demo is just for us to test things in the workspace. In this particular workspace, Nx Release doesn't have a way to distinguish what is an app and what is a library/package. Note, if you're in an Nx-generated workspace that uses Nx Plugins, you'd potentially have that classification in the project.json files.

In our particular scenario, let's exclude @tuskdesign/demo as follows:

// nx.json
{
    ...
    "release": {
        "projects": ["*", "!@tuskdesign/demo"]
    }
}

You can also explicitly list the packages to be released individually. Or, as shown above, include all (*) and exclude the private package.

If you re-run the nx release command, you'll see that @tuskdesign/demo will be ignored now.

Running the Versioning and Changelog Generation

Once you have configured the excluded packages, feel free to go ahead and run the command without --dry-run:

pnpm nx release --first-release

You can skip the release part when prompted for now. Check how the workspace got updated, incrementing the package.json version property and updating the version on the package dependency definition, i.e. the @tuskdesign/buttons version got updated in the @tuskdesign/forms package.json.

Versioning using Conventional Commits

Instead of manually confirming the next version each time, we can use a versioning strategy: Conventional Commits is a commonly adopted approach for publishing packages.

To configure conventional commits with Nx Release, go to the nx.json and adjust it as follows:

// nx.json
{
    ...
    "release": {
        "projects": ["*", "!@tuskdesign/demo"],
        "version": {
            "conventionalCommits": true
        }
    }
}

If you now run..

pnpm nx release --dry-run

..you'll notice that it doesn't pick up any changes because it leverages conventional commit, and we haven't changed anything yet.

Let's go ahead and change something in our @tuskdesign/buttons package and then commit it as follows:

git commit -am 'feat(buttons): add new background shadow'

Now re-run the nx release command (don't forget the --dry-run). You'll see how it chooses v1.2.0 as our new version (we had v1.1.0 previously), given we added a new feature (denoted by the feat(...) conventional commit).

It also generates a nice CHANGELOG.md for us:

## 1.2.0 (2024-02-09)

### 🚀 Features

- **buttons:** add new background shadow

### ❤️  Thank You

- Juri

## 1.1.0 (2024-02-09)

This was a version bump only, there were no code changes.

Generating a GitHub Release

Instead of just generating a CHANGELOG.md entry in our repository you can also opt-in for creating a Github release (here's the example of the Nx repository).

Use the createRelease property and set it to github.

// nx.json
{
    ...
    "release": {
        "projects": ["*", "!@tuskdesign/demo"],
        "version": {
            "conventionalCommits": true
        },
        "changelog": {
            "workspaceChangelog": {
                "createRelease": "github"
            }
        }
    }
}

To see the working, you need to make sure to

push the repo to GitHub
make some change so you can run the nx release command again and get a changelog generated
now also get a GH release created

Note, you can still use --dry-run and it'd show you the URL where the GitHub release would be created. You can also use the --skip-publish to skip the NPM publishing.

Programmatic Mode

As you've seen, you can use nx release right away with minimal configuration. However, we are very well aware that many real-world scenarios are more complex, you want/need more control over when the version is happening, when the changelog generation kicks in and so on. This is why we also introduced a programmatic API.

This approach gives you full control to embed Nx Release into your current release flow. There's a nice example script on our docs that can help you get started.

Create a file - I call it release.ts - at the root of my workspace. Nx Release obviously doesn't care how the file is called or where you place it. You can also go with plain JS.

Here's the example script from our docs:

import { releaseChangelog, releasePublish, releaseVersion } from 'nx/release';
import * as yargs from 'yargs';

(async () => {
  const options = await yargs
    .version(false) // don't use the default meaning of version in yargs
    .option('version', {
      description:
        'Explicit version specifier to use, if overriding conventional commits',
      type: 'string',
    })
    .option('dryRun', {
      alias: 'd',
      description:
        'Whether or not to perform a dry-run of the release process, defaults to true',
      type: 'boolean',
      default: true,
    })
    .option('verbose', {
      description:
        'Whether or not to enable verbose logging, defaults to false',
      type: 'boolean',
      default: false,
    })
    .parseAsync();

  const { workspaceVersion, projectsVersionData } = await releaseVersion({
    specifier: options.version,
    dryRun: options.dryRun,
    verbose: options.verbose,
  });

  await releaseChangelog({
    versionData: projectsVersionData,
    version: workspaceVersion,
    dryRun: options.dryRun,
    verbose: options.verbose,
  });

  // The returned number value from releasePublish will be zero if all projects are published successfully, non-zero if not
  const publishStatus = await releasePublish({
    dryRun: options.dryRun,
    verbose: options.verbose,
  });
  process.exit(publishStatus);
})();

You can invoke it with tsx or tsnode.

pnpm dlx tsx release.ts

Notice by default in the script we have dry-run enabled as a more cautious approach to not accidentally publish something as we keep editing and trying our programmatic setup.

From here on you have full control and can pretty much do whatever works best for your workspace setup. Common examples include to

move files to a common root-level dist/ folder and version and release them from there. This is pretty common to avoid messing with your src files and swapping versions there, allowing you to always depend on the latest local packages for instance.
setup fully automated releases on CI, including enabling provenance support. Our docs have more details on how to set that up or check out the linked talk above which goes through those steps
...

Wrapping Up

With this release of Nx Release it is fully ready to be used. Make sure to check out our docs on Managing Releases as well as our release-related recipes.

Here are some example repositories already leveraging Nx release

our own Nx Repo
RxJS repo
typescript-eslint
Watch the live stream with Kent and James as they enable Nx Release on the EpicWeb workshop app repository.

Learn more

Introducing @nx/nuxt: Enhanced Nuxt.js Support in Nx

Katerina Skroumpelou — Tue, 06 Feb 2024 16:35:05 +0000

We're excited to introduce a new way to enhance your Nuxt development workflow! After the Vue plugin, we're introducing our new Nx plugin for Nuxt, @nx/nuxt. Designed for Nuxt developers and existing Nx users alike, this integration brings the best of both worlds into your development ecosystem, enabling you to leverage Nx's powerful capabilities seamlessly within your Nuxt projects.

Why Consider Nx for Your Nuxt Projects?

Using Nx with your Nuxt.js projects presents the following advantages:

Monorepo Management: Simplify the management of multiple projects within a single repository, facilitating code sharing and reducing overhead.
Modular Development: Break down your Nuxt app into manageable, independent modules that can be developed, tested, and deployed in isolation.
Enhanced Caching: Accelerate your development with Nx's intelligent caching, automatically configured for your Nuxt projects.
Nx generators: Nx provides generators for scaffolding new Nuxt applications, with support for Jest, Storybook, and e2e test generation with Cypress or Playwright.
Automated upgrades: Nx offers a set of migrators that help you upgrade your projects.

Getting Started with Nx and Nuxt.js

Whether you're initiating a new project or integrating into an existing one, @nx/nuxt offers a straightforward setup process:

Starting a New Nx Workspace with Nuxt

Creating a new Nx workspace optimized for Nuxt is as simple as running:

npx create-nx-workspace@latest --preset=nuxt

Our setup wizard will guide you through the initial configuration, ensuring your workspace is tailored to your needs:

npx create-nx-workspace@latest

 >  NX   Let's create a new workspace [https://nx.dev/getting-started/intro]

✔ Where would you like to create your workspace? · my-org
✔ Which stack do you want to use? · vue
✔ What framework would you like to use? · nuxt
✔ Integrated monorepo, or standalone project? · integrated
✔ Application name · my-app
✔ Test runner to use for end to end (E2E) tests · playwright (also cypress)
✔ Default stylesheet format · scss (also css, less)
✔ Set up CI with caching, distribution and test deflaking · github

This command will create a new Nx workspace with a single Nuxt application, complete with essential features and ready for development.

Enhancing an Existing Nuxt Project with Nx

Integrating Nx into an existing Nuxt.js project has never been easier, with the help of the nx init command. This command will add Nx to your project without the need to disrupt your current setup.

How It Works

When you run nx init in your existing Nuxt.js project, Nx does the following:

Installs @nx/nuxt: Adds the necessary Nx and @nx/nuxt dependencies to your project, enabling Nx's features while keeping your existing setup intact.
Understands Existing Configurations: Nx automatically recognizes your nuxt.config.js or nuxt.config.ts file, ensuring that all your custom configurations, scripts, and commands are preserved and utilized.
Minimal Configuration: Only a minimal nx.json file is added to your project. This file is used to configure the @nx/nuxt plugin if needed, but in most cases, your existing Nuxt.js configurations will suffice.

To begin the integration process, simply navigate to the root of your existing Nuxt.js project and run:

npx nx init

This approach offers several key benefits for teams looking to adopt Nx:

Zero Disruption: Your project will continue to use its existing configurations, and the existing configuration entrypoint files. There's no need to learn new configuration syntaxes or reconfigure your project to start using Nx.
Immediate Value: Instantly gain access to Nx's powerful developer tools and build system, without significant changes to your project.
Future Flexibility: As your project grows, Nx is ready to scale with you. You can gradually adopt more Nx features and plugins over time, at a pace that suits your team.

Using Nx to run your Nuxt app

Nx scans your workspace to look for Nuxt configuration files (eg. nuxt.config.ts). It uses these files to understand where your Nuxt projects live, and uses them to set up tasks that can be invoked through Nx, like serve and build. So, in your Nx workspace, you can then run:

nx serve my-nuxt-app

and

nx build my-nuxt-app

and these commands will call the nuxt CLI under the hood, enhanced with Nx's features.

You can see a visual representation of your task dependencies by running

nx graph

You can also see how Nx configures your tasks, by running:

nx show project my-nuxt-app --web

Using Nx Console

You get access to all these features through our VSCode and WebStorm Nx Console extension.

You can use Nx Console to visualize tasks, and understand where each inferred task (like build and serve in Nuxt's case) is coming from, with our codelens-like feature, as an alternative to the --web flag on the nx show project command.

Nx Console is also very convenient for generating code and running tasks, since it offers a graphical user interface for all the amazing features of the Nx CLI.

What Does Nx Bring to Your Nuxt Development?

With @nx/nuxt, your Nuxt projects gain automatic recognition of build and serve processes. There's no need to deal with unfamiliar configurations; Nx intuitively understands your Nuxt project structure and optimizes accordingly.

Modularize and Scale with Ease

One of the most compelling aspects of using Nx with Nuxt.js is the ability to modularize large applications into manageable libraries or components. This not only makes your codebase more organized and maintainable but also significantly enhances your development workflow and CI processes.

Breaking Down a Monolithic Nuxt App

Large Nuxt applications can become challenging to maintain and scale over time. By adopting Nx, you can structure your Nuxt app as a collection of smaller, focused libraries. Each library can encapsulate specific functionalities or features, such as UI components, utilities, or business logic.

Independent Development and Testing

This modular structure allows teams to work on different aspects of the application in parallel, reducing bottlenecks and improving collaboration. Furthermore, you can run tests, linters, and other checks independently for each library, making your development process more efficient and targeted.

For instance, if you want to create a new Vue UI library, you can use the following command:

nx generate @nx/vue:lib my-shared-ui

This command creates a my-shared-ui library within your workspace, which can then be used across your Nuxt app and potentially other applications within the same workspace.

Enhancing CI with Modular Builds

On the CI front, Nx's modular approach makes things much faster. You can configure your CI pipeline to build, test, and deploy only the affected libraries and applications, thanks to Nx's advanced dependency graph analysis. This results in faster CI runs and more efficient resource utilization.

Sharing Code Between Applications

Nx's workspace model facilitates code sharing between projects, which is particularly useful in monorepos containing multiple front-end projects. With Nx, sharing UI components, utilities, or services between these applications becomes straightforward.
To share code, simply import the library into your Nuxt and Vue applications as needed. Nx takes care of the rest, ensuring that dependencies are correctly managed and that your applications remain buildable and testable.

Imagine a scenario where your workspace contains a Nuxt application for your public-facing website and a Vue application for an internal tool. You can create a shared library for common UI components, such as buttons, inputs, and modals, and use these components in both applications. This not only reduces duplication but also ensures consistency across your projects.

// Importing a shared UI component in your Nuxt app
import { MyButton } from '@my-org/my-shared-ui';

// Importing the same component in your Vue app
import { MyButton } from '@my-org/my-shared-ui';

Visualizing Your Project Structure

Nx provides a clear overview of your project's structure and dependencies, making it easier to manage complex applications. The Nx Console extension for VSCode, for instance, offers a graphical interface to visualize and run tasks, enhancing your development experience.

In your workspace, you can run

nx graph

and see the structure of your projects:

Embracing Nx in Your Nuxt Journey

Whether you're starting a new Nuxt project or looking to enhance an existing one, Nx offers a compelling set of tools and features to streamline your development process. From modularization to caching, the integration of Nx into your Nuxt projects promises a more efficient, scalable, and enjoyable development experience. By embracing Nx's capabilities in your Nuxt development, you're not just optimizing your current workflow; you're future-proofing your development process. As your projects grow and evolve, Nx's modular architecture and powerful tooling will continue to provide value, making your development experience more enjoyable and productive.

Learn more

#nx Follow

What if Nx Plugins Were More Like VSCode Extensions

Juri Strumpflohner — Mon, 05 Feb 2024 15:32:55 +0000

Enhance, but don't interfere! That's the ideal! And this is how extensions work in VSCode (or Webstorm). You can use VSCode without any extension and get some basic functionality, or you can add an extension on top to enhance your experience and, ideally, increase your productivity.

Table of Contents

Adding Nx to an Existing Monorepo
Project Crystal
Project Crystal Plugins in an Nx Monorepo
- Inferred Targets
- Visualizing Inferred Targets
More Transparency and a Single Source of Truth
Enhancing existing Monorepos with Nx Plugins
This is just the Beginning
Learn more

Prefer a video? I've got you covered!

Also, make sure to check out Launch Nx Conf on Thursday, Feb 08th, where there are going to be more in-depth talks about Project Crystal as well as other exciting features around Nx and Nx Cloud.

Take, for instance, the Playwright plugin. You install it, and it'll automatically detect the Playwright config file and enhance your workspace by providing quick run buttons alongside your tests or even a dedicated Test Explorer window.

Adding Nx to an Existing Monorepo

You can add Nx to an existing npm/yarn/pnpm monorepo quite straightforwardly. You run

npx nx@latest init

You'll get an nx package installed and an nx.json allowing you to define task dependencies and caching. With that, you're now able to run commands like nx build <your project> or nx run-many -t build test to run all build and test targets in your workspace in parallel. Nx will read and use your existing package.json scripts. I've written an in-depth blog post about adopting Nx in such a scenario.

This is the most lightweight setup you can get while still getting some improvements via Nx regarding faster task running and more intelligent parallelization. But, you need to deal with the remaining of the monorepo setup.

Project Crystal

Nx always had more to offer, though, which it mainly did through its plugins. They're optional but usually something you'd get set up when creating a new workspace with create-nx-workspace. Nx Plugins are extremely powerful, helping you not only create and configure new monorepos, but also taking away the burden of integrating various tooling as well as providing features for enforcing consistency and helping with maintainability. These aspects are fundamental in enterprise settings, where Nx Plugins have proven to help teams successfully manage their monorepos.

However, this is a balancing act. More abstraction and automation means more support but also potentially a learning curve and giving up some low-level control. It also requires a slightly more significant upfront investment when migrating to an Nx plugin-powered monorepo.

These are things we wanted to solve, and Project Crystal is the first step in that direction.

Some of the main objectives of Project Crystal are to

make Nx plugins more transparent
reduce the amount of configuration required
allow Nx plugins to be drop-in enhancements in existing npm/yarn/pnpm monorepos
allow for a migration to an Nx plugin-powered monorepo

Project Crystal Plugins in an Nx Monorepo

Note, starting with Nx 18, Project Crystal will be active for new workspaces only. You can opt-in to use them though.

When you create a new Nx workspace using

npx create-nx-workspace myorg

..and you choose an "integrated monorepo" you'll get the usual setup powered by Nx Plugins and all the features and benefits that come with them. Where you'll see Project Crystal in action is when you open a project.json file, which will most likely look like the following:

{
  "name": "reactapp",
  "$schema": "../../node_modules/nx/schemas/project-schema.json",
  "sourceRoot": "apps/reactapp/src",
  "projectType": "application",
  "targets": {},
  "tags": []
}

Inferred Targets

Starting with Nx 18 and Project Crystal, we don't generate any targets anymore, but the corresponding Nx plugin instead infers them. If we open the nx.json, you'll see a new property, plugins:

{
  ...
  "plugins": [
    {
      "plugin": "@nx/vite/plugin",
      "options": {
        "buildTargetName": "build",
        "previewTargetName": "preview",
        "testTargetName": "test",
        "serveTargetName": "serve",
        "serveStaticTargetName": "serve-static"
      }
    },
    {
      "plugin": "@nx/eslint/plugin",
      "options": {
        "targetName": "lint"
      }
    },
    {
      "plugin": "@nx/cypress/plugin",
      "options": {
        "targetName": "e2e",
        "componentTestingTargetName": "component-test"
      }
    },
    ...
  ],
  ...
}

Notice the options property defining the names of the potentially inferred targets for each plugin. These targets will be generated dynamically s.t. you can still run nx build reactapp even though there's no build target explicitly defined in the project.json of your apps/reactapp project.

This dramatically reduces the redundancy of repeatedly configuring the same tasks (e.g., Jest or Vitest tasks) throughout your various projects. Instead, with this new approach, you get the defaults, and if you need to override them, you can still define them in your project.json file as you were accustomed to before.

Visualizing Inferred Targets

Dynamically inferred targets help with the maintainability aspect and reduce the configuration overhead overall. But how do we know which targets are available for a given project?

Option 1 is to run the following command:

npx nx show project reactapp --web

This opens your browser with the following view:

Option 2 is Nx Console, which is an extension for VSCode as well as IntelliJ (Webstorm etc..). It comes with a project detail view, as shown below, as well as "Codelens" features that enhance your configuration files with context-based information and features.

More Transparency and a Single Source of Truth

We also wanted the new approach to plugins to be closer to the actual CLI tool of the framework you're using. If you have a React + Vite project, nx build should be as close as possible to the vite build while still providing the enhancements around caching configuration.

And this is what happens. Behind the scenes, the plugin configures caching with inputs and outputs and task dependencies (e.g., ^build) but then mostly pipes through to the Vite CLI (in this particular case), Remix, Next CLI, etc.

Furthermore, the framework-specific config - in the example of Vite, the vite.config.ts - is the single source of truth from which Nx infers configuration such as caching. If you change your Vite build.outDir, Nx automatically picks that up and uses that as the caching output directory.

Enhancing existing Monorepos with Nx Plugins

As mentioned earlier, one of the key goals of Project Crystal was to improve the adoption story of Nx Plugins, which implicitly also helps with migrating to Nx plugin-based monorepos. By reducing the config footprint of an Nx plugin and by automatically inferring tasks from existing framework configs, we've moved in a direction where plugins have become much more of a drop-in approach.

Starting with Nx 18, if you now run nx init on an existing npm/yarn/pnpm workspace, you'll also get asked about installing plugins based on the setup you have in your monorepo.

You can also obviously start with no plugin at all and incrementally add them as you go and feel comfortable using the new add command:

npx nx add @nx/vite

This is just the Beginning

We just released Project Crystal, so this is just the beginning of it. While we've moved many of our existing Nx plugins to adopt the new approach, there are still some more refinements to be done in the coming weeks. But we are excited about the possibilities Project Crystal enables for Nx and its adoption story going forward, making Nx plugins more approachable, transparent, and lightweight.

Learn more

Also, if you liked this, click the ❤️ and make sure to follow Juri and Nx on Twitter for more!

#nx Follow

Nx - Highlights of 2023

Juri Strumpflohner — Thu, 28 Dec 2023 17:01:08 +0000

Co-authored by Victor Savkin and Zack DeRose

It is that time again: getting flooded by Year of Review blog posts. We did it last year, and we should do it again! So here we go, and be warned, 2023 was massive!!

Table of Contents

Top 10 Nx Highlights of 2023
- TypeScript for Extensibility - Rust for Speed
- First Class Vite Support
- Nx't Level Publishing
- Improved Node Backend Development: Fastify and Docker
- Nx Console support for IntelliJ
- Playwright for e2e testing
- TypeScript Packaging and Batch Mode
- Nx team maintained Vue plugin
- Extending Nx: Local Generators, Build your Own CLI, Verdaccio Support
- Module Federation
Many OSS repos adopt Nx
Nx Community
New Content & Improved Docs
New Tagline: Smart Monorepos - Fast CI
Nx Conf
Looking ahead - 2024

Top 10 Nx Highlights of 2023

We shipped a ton of features in 2023. You can find all our release blog posts and release-related info here: https://nx.dev/changelog or check out our Dev.to collection.

I picked out 10 highlights for you.

TypeScript for Extensibility - Rust for Speed

At Nx, we’ve heavily embraced Typescript from the beginning and we’ve been very happy with that decision. Nx also stands as the fastest JS monorepo tool available, demonstrating that adopting TypeScript does not necessarily compromise speed. However, we don't stop here. To push the boundaries further, we started to rewrite the most performance critical and computationally intensive parts of the Nx core in Rust.

Our initial focus was on rewriting the task hasher, previously reliant on Git with a Node fallback. This shift to Rust brings a noticeable performance boost, particularly in large repositories, while maintaining the same user experience.

Following this, we revamped the TypeScript dependency resolution, observing an almost 5x speed increase with our Rust-based approach over the traditional TSC method.

// Detect dark theme var iframe = document.getElementById('tweet-1726977598218199302-389'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1726977598218199302&theme=dark" }

Such enhancements are especially crucial for the efficient project graph calculation. As we continue to evolve Nx, Rust will play a key role in optimizing performance-critical components. This strategic use of Rust complements our ongoing commitment to TypeScript, ensuring Nx remains as extensible and powerful as ever.

First Class Vite Support

Vite is rapidly transforming the landscape of frontend development! Its refreshing simplicity and innovative approach have made a significant mark in the developer community. What truly stands out is not just Vite's technological aspect but also how its team approaches and grows the community around the tool. Vite stands for speed and community, values that deeply resonate with us here at Nx.

Our collaboration with our friends in the Vite core team has been incredibly fruitful. Vite is not just compatible but a first-class option with many of Nx's frontend plugins. When you create a new Nx powered React workspace, Vite (and Vitest) are your default options.

We also built some powerful code generators that not only facilitate a seamless transition from Webpack to Vite but also pave the way for an effortless migration from a CRA-based setup to a modern Nx + Vite based workspace. To see this process in action, check out this short video.

AnalogJS - the fullstack Angular meta-framework which also heavily builds on top of Vite - is using the @nx/vite plugin to power its Angular and Nx based workspaces.

We also spoke at both editions of ViteConf. If you're curious check out Juri's talk about High Speed Monorepos and this year's talk by Katerina on Streamlining your Vite dev flow with Nx.

Nx't Level Publishing

Open source libraries and frameworks share a common necessity: the need to develop multiple packages cohesively and efficiently while managing their versioning and publishing to NPM. Nx has emerged as a go-to choice for handling such open source monorepos (as we'll explore further in the next section of this blog post). Until recently, one area Nx did not address directly was versioning and release management. Traditionally, this gap has been filled with tools like release-it, changesets, or custom Node scripts, similar to our approach in the Nx repository.

However, many in our community have expressed a desire for a more native, integrated experience for versioning and publishing, akin to what Lerna offers. In response to this feedback, we've introduced the "nx release" command, a solution designed to seamlessly integrate these processes into the Nx workflow.

James Henry gave a deep dive talk of an early version of it at this year's Nx Conf:

Since its introduction, the "nx release" feature has significantly evolved, leveraging the power of the Nx project graph to effectively understand inter-package dependencies. This understanding is crucial as it allows for:

Versioning packages offering support for both independent and "locked" versioning strategies.
Releasing packages in the correct sequence, ensuring dependency integrity.

Beyond these core functionalities, the feature also includes a robust grouping mechanism, supports semantic versioning, and changelog generation. Additionally, it provides various release targets, such as GitHub and NPM. For those having special requirements, the programmatic API offers maximum flexibility.

Improved Node Backend Development: Fastify and Docker

Colocating frontend and backend code within the same monorepo has become a popular practice. It greatly facilitates cross-functional teams and helps ensure end-to-end type safety. Although you can use other backend stacks with Nx, Node is a popular backend companion for JS based frontends. We had support for Express and NestJS backend for a while.

This year we added another popular option: Fastify. Known for its high performance, excellent developer experience, and useful built-in features like logging, Fastify aligns well with Nx's modular software design principles. Its extensible and modular nature complements the Nx philosophy perfectly.

In tandem with Fastify, we've also introduced Docker support for Node deployments.

Nx Console support for IntelliJ

Nx Console has evolved from an experimental side project of the Nx team to a core part for enhancing your productivity when working in a monorepo. Being integrated right into your editor it can provide useful information and functionality right where you need it, whether that's running commands, providing contextual autocomplete support or the ability to explore the project and task graph.

This year we not only added a lot of new features to Nx Console, but also rewrote its internals which paved the way to expand Nx Console to other code editors: JetBrains IDEs.

Yes, this means you can now use the latest Nx Console directly in your Webstorm IDE. Read the announcement blog post for all the details or go ahead and install Nx Console if you didn't already:

Playwright for e2e testing

2023 saw Nx introduce official support for Playwright - a popular testing tool from Microsoft.

In this video, Zack DeRose explains how you can use Playwright to test both a single web application, as well as stand up a full-stack system - including a backend server and a frontend application - and write and run tests using Playwright:

The repo for this video can also be found here.

Generally, Playwright fits in the Nx ecosystem as a tool that developers can use as a possible alternative to Cypress - a popular e2e testing tool that Nx has supported for a long time now! In addition to publishing an official @nx/playwright package, running the command to create a new workspace will now prompt for Playwright as an option for React, Angular, and Vue stacks:

% npx create-nx-workspace@latest

 >  NX   Let's create a new workspace [https://nx.dev/getting-started/intro]

✔ Which stack do you want to use? · react
✔ What framework would you like to use? · none
✔ Integrated monorepo, or standalone project? · integrated
✔ Which bundler would you like to use? · vite
? Test runner to use for end to end (E2E) tests … 
Cypress [ https://www.cypress.io/ ]
Playwright [ https://playwright.dev/ ]
None

Similar options will appear when using Nx generators to create new frontend web applications for an existing workspace.

TypeScript Packaging and Batch Mode

TypeScript has won. It has become the prevalent way of writing modern JavaScript applications. And we kept improving our support to streamline development and polish some of the rough edges. Like properly defining secondary package entry points. You can define them in the package.json, but both creating these entries but especially maintaining them can be quite painful.

{  
  "exports": {  
    "./package.json": "./package.json",  
    ".": "./src/index.js",  
    "./foo": "./src/foo.js",  
    "./bar": "./src/bar.js"  
  }  
}

So in v16.8 we added the ability to automatically have these generated for you by defining the additionalEntryPoints and generateExportsField when using the @nx/js plugin.

// packages/my-awesome-lib/project.json
{
  "name": "my-awesome-lib",
  "targets": {
    "build": {
      "executor": "@nx/js:tsc",
      ...
      "options": {
        "main": "packages/my-awesome-lib/src/index.ts",
        ...
        "additionalEntryPoints": ["packages/my-awesome-lib/src/foo.ts"],
        "generateExportsField": true
      },
    },
    ...
  }
}

Similarly we improved the ability to package your TS libraries in multiple formats (ESM and CJS). When using the @nx/rollup plugin, all you need to do is define the format property in your config:

// packages/my-awesome-lib/project.json
{
  "name": "my-awesome-lib",
  "targets": {
    "build": {
      "executor": "@nx/rollup:rollup",
      ...
      "options": {
        "main": "packages/my-awesome-lib/src/index.ts",
        ...
        "format": ["esm", "cjs"],
        "additionalEntryPoints": ["packages/my-awesome-lib/src/foo.ts"],
        "generateExportsField": true
      },
    },
    ...
  }
}

Here's a video that walks you through:

But we wouldn't be talking about Nx if we didn't also look into speeding up TypeScript compilation for large monorepos. We called it "batch mode". When enabling batch mode, Nx leverages the underlying project graph to generate TypeScript project references behind the scenes for you, to fully leverage TS incremental building. The results are amazing. According to our benchmarks, batch mode has the potential to speed up Typescript compilation by up to 5x for large monorepos.

Nx team maintained Vue plugin

After adding Vite as a first-class citizen of Nx workspaces, it was only a matter of time before Nx started offering official support to Vue!

Vue is currently the second most popular frontend framework (according to npm downloads) behind React and slightly ahead of Angular.

The first place your might notice Nx's support for Vue is in the create-nx-workspace script:

The option above will create a new Nx workspace with a fresh new Vue application, all set up and ready to develop! To add new Vue projects to an existing Nx workspace, you can also add our @nx/vue package as a dev dependency to your workspace:

% npm add -D @nx/vue

And you'll then have access to Nx generators so you can create Vue applications, libraries, and more in your workspace!

Checkout out our Vue standalone tutorial for more, as well as our Vue API docs and stay tuned as Nx prepares to offer more Vue support (including support for Nuxt, a full-stack framework built around Vue) in the near future!

Extending Nx: Local Generators, Build your Own CLI, Verdaccio Support

Extensibility is at the heart of Nx, serving as the cornerstone of its flexibility. It enables the Nx core team to continually expand capabilities through dedicated plugins and simultaneously paves the way for a rich array of community plugin contributions. Furthermore, Nx's adaptable nature is particularly beneficial for large enterprises, as it allows for the creation of custom automation solutions, specifically tailored to meet their unique organizational needs.

In 2023 we kept improving Nx's extensibility, unifying the Nx plugin development model and how you develop workspace-local automations. You can now scaffold a new plugin into your Nx workspace and run it right away which makes it an interesting approach to automate your monorepo.

When creating automations with Nx you cannot just enhance existing Nx workspaces, but also develop a complete Nx preset that controls the entire appearance of an Nx workspace. Basically your own, personalized create-nx-workspace. You can publish and then use your preset like

npx create-nx-workspace myrepo --preset=@yourpkg/nx-preset

We wanted to make building on top of Nx even more pleasant, allowing you to introduce your own branding by building your own CLI with Nx. The Qwik-Nx repo is a great example where they allow you to scaffold a new Nx workspace for Qwik development with:

npx create-qwik-nx

And finally, we extracted our own Verdaccio setup that we've been using to run our e2e tests in the Nx repo s.t. you can use it for your own plugin development as well. Check out this video for a walkthrough on how this works.

Module Federation

Module Federation is an exciting new feature of Webpack 5 that has gained a significant amount of interest in 2023.

Simply put, Module Federation allows a Javascript application running in a browser to dynamically load code from another application hosted at a different url, while facilitating optimal loading of shared dependencies.

This is an exciting development as it allows a paradigm shift in how you can architect, build, and deploy Javascript applications! And this is especially exciting for monorepo fans, as Nx has best-in-class support for module federation that makes a Module Federation approach easy to adopt and simple to understand!

Currently, our @nx/angular and @nx/react plugins both have generators to create a "host" application that will load and consume federated modules from "remote" applications, which you can also generate using Nx. Then, by running a simple command with Nx, you can serve all applications required for your host application with the command:

% nx serve host-application --devRemotes=remote-application

Where in the example above your host application is named host-application and a remote application that you want live updates on as you're developing is named remote-application.

Throughout 2023, we've continued to increase Nx's support and general dev experience around Module Federation, including adding a generator to federate an existing module, improving the local developer experience by improving local webserver performance, and introducing the concept of Dynamic Module Federation which will allow you to dynamically specify the location of your remote applications via a module-federation.manifest.json file!

At Nx, we're excited about the Module Federation support we offer for our users, and think that it has many interesting applications when paired with Nx's CI capabilities - in particular allowing for much shorter build times, especially for larger Angular applications.

Many OSS repos adopt Nx

By simply installing the nx package (or initializing with nx init in any project or monorepo), you already get some cool features:

Advanced task scheduling, including task pipelines and parallel execution.
Efficient caching mechanisms.

If you want to learn more about such setup, make sure to check out our blog post on how to adopt Nx on a npm/yarn/pnpm workspace or the corresponding video version.

Numerous open-source packages are adopting Nx in this lightweight manner. It enables them to maintain their existing setup while notably enhancing the local developer experience (DX) in task execution and accelerating processes on CI.

I picked out some of the more well-known OSS repos that started using Nx this year:

Tanstack - Tanstack has evolved to an entire ecosystem consisting of the famous Tanstack (or React) Query, Tanstack Table, now also Tanstack Router and Tanstack Form. It started with Tanstack Query, which adopted Nx and Nx Cloud. Zack talked about this collab with Dominik, and we also had Dominik on our Nx live stream. Now, all the above-mentioned Tanstack libs have adopted Nx, and there's more coming.

Sentry JavaScript - Sentry, renowned for its comprehensive solutions in frontend monitoring and error logging, recently adopted Nx for their official JavaScript SDK. This move integrates Nx's capabilities into their monorepo, containing packages for popular frontend and Node.js backend integrations. They also published a blog post on the benefits they've seen following the adoption of Nx in their monorepo (hint: reducing CI times by 35%).

RxJS - The library for reactive programming in JavaScript. It is widely popular, with over 40 million downloads/week on NPM. RxJS only recently adopted Nx, not only leveraging speed improvements via caching, but also leveraging Nx's latest nx release feature to publish packages to NPM.

AnalogJS - Analog is a full-stack Angular meta-framework that brings exciting features to Angular, like faster Vite setup, support for both server-side and static rendering, and easy file-based routing. Analog uses an Nx monorepo for its development and also uses Nx's DevKit to create tools that work great in both Nx and Angular CLI workspaces.

Qwikifier - The Qwikifiers community built a dedicated Nx plugin to combine the power of Qwik and Nx. Their repo is a great example of building Nx plugins and using Nx to build your own CLI.

Builder.io Mitosis - BuilderIO has an ambitious compiler project that allows you to write a component once and then compile it to different frameworks. Check out their mind-blowing demo page. They adopted Nx to coordinate task dependencies and speed up their CI builds.

Ghost - Are you into blogging? You might want to look at Ghost. They were using Lerna in the past and migrated to a fully Nx-powered workspace.

And these are just some of them that joined in 2023. If I missed some cool ones (which I'm pretty sure), ping me and let me know!

Nx Community

Nx has a huge community! We're lucky to have so many folks rooting for Nx, whether on socials, talking at conferences, writing blog posts or creating awesome plugins.

Nx Champions - This year we finally launched which we had planned for a long time. Our Nx Champions program.

These are individuals who stood out for their contributions and passion for helping within the NX community. We wanted to build a more connected relationship with these folks and have a channel to gather more direct feedback as well. Get to know all of our champions.

New Discord server - Around September we also switched over from our previous Nx Slack community to a brand new Nx community Discord, which is already counting 2,600+ members. Discord is popular among OSS communities and allows new folks to join easily. In addition, we now have a dedicated forum integrated, as well as a couple of useful automations. More coming next year!

Make sure you join!

New Content & Improved Docs

Our Youtube channel has grown to over 15k subscribers and peaks of 65k views a month. We love to provide educational video content, so make sure to subscribe! It got a little silent towards the end of the year, but we've been working a lot behind the scenes. So stay tuned!

We also poured a lot of effort into the docs. We restructured them following the Diataxis to make pages less overwhelming and more structured based on their type of content. You'll find

Concept docs - which explain some of the inner workings and mental model behind certain features. Like how caching works.
Recipes - which are solution oriented. You already know how to cook, we provide the exact recipe for it.
Tutorials - for when you just want to sit down and follow along, step by step to learn how to use Nx in a certain context.
Reference and API docs - pure, raw and to the point.

We created a brand new "Why Nx" page explaining the overall architecture of Nx including a brand new video giving you a holistic overview of what Nx is capable of.

We also refreshed our entry pages, including dedicated examples of using Nx with popular stacks:

You can also browse them in the nx-recipes GitHub repository.

// Detect dark theme var iframe = document.getElementById('tweet-1736023402933318011-479'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1736023402933318011&theme=dark" }

And obviously, we jumped on the AI train as well. A couple of months ago, we added the Nx Assistant. A ChatGPT-powered interface trained on our docs. Katerina wrote about it on our blog. The AI chat allows to interactively ask questions about Nx and will give you relevant answers from our docs (including linking to the sources).

New Tagline: Smart Monorepos - Fast CI

Nx stands out for its flexibility, accommodating for both monorepo and non-monorepo project structures. This approach allows users to begin with simpler project configurations, leveraging the benefits of Nx's robust tooling, and later, when the need arises, seamlessly migrate to a monorepo.

However, Nx's true strength becomes most apparent at scale, typically within a monorepo setup. We wanted to capture it in our new tagline: Smart Monorepos - Fast CI.

// Detect dark theme var iframe = document.getElementById('tweet-1734558895547568634-36'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1734558895547568634&theme=dark" }

Setting up an efficient and maintainable CI process for monorepos can be a complex task, so we've also made it a focal point in our new tagline. Nx expands beyond the local development experience, helping you set up an efficient CI process. We're publicly launching Nx Agents to add seamless distribution to your CI pipeline, and more are coming in 2024.

As part of that, we also restructured our docs to have a section entirely dedicated to CI: https://nx.dev/ci.

Nx Conf

We did it again! The second in-person Nx Conf was a resounding success, this time set against the vibrant backdrop of the Big Apple.

There's not much to say. Check out some of the amazing talks. I did a Nx Conf 2023 recap blog post.

Looking ahead - 2024

Although we shipped a lot in 2023, in many ways 2023 was about preparing for what we are planning to ship in Q1 2024.

Solving CI

Legacy CI systems are a performance and productivity bottleneck if you use a powerful build system like Nx. Big tech companies know it and that's why their CI systems look nothing like Circle or Jenkins. We've been narrowing this gap over the years, but only this year we finally built a turn-key CI solution that gives you great performance, scalability, dev ergonomics, and must better cost efficiency.

It has three components:

Nx Cache: Built-in local and remote caching to speed up your tasks and save you time and money. Available now.
Nx Agents: A single line to enable distributed computation, across multiple machines. Fully managed agents, dynamically allocated based on PR size. Available early Feb.
Nx Workflows: Next generation, fully managed CI solution with distribution at its core, designed from the ground up for monorepos. Available late March.

Optimal parallelization and distribution, using the right numbers of agents for each PR, rerunning flaky tests, splitting and distributing large test suites, handling dependencies between tasks across machines -- are just some of the things we can now handle automatically for you. Turn it on and enjoy the speed.

Solving the Simplicity vs Power Dilemma

Balancing simplicity and power is the trickiest part of the dev tools design. Simple onboarding for small projects or handling the biggest enterprise systems? Two years ago we solved this problem by giving you a choice between the package-based setup (a more powerful version of something like Turborepo) and the integrated setup (we manage your whole monorepo in the most optimal way). But now we believe we have a much better solution, where you have both, the simplicity of the former with the power of the latter. So you no longer have to choose.

We took inspiration from VSCode. Any project you open in VSCode will work right away: it is simple, and you don't need to configure anything. If you install say a Playwright plugin, VSCode becomes aware of Playwright. It can run and debug your tests right in the editor. That's what the Nx experience is going to be like. Any project, any tool will work right away. But if you - for instance - install the Playwright plugin, Nx will become aware of Playwright and will be able to cache test runs in the most optimal way and distribute your e2e tests across machines for best efficiency. All the benefits with none of the costs.

The whole team is excited about it as the new experience feels much more elegant.

As always, we try very hard not to break folks, so all your current workspaces will keep working, and we will provide automatic migrations to bring you to this new way of using Nx.

Exciting stuff! So keep an eye on our channels, and subscribe if you haven't already ;)

Nx 17.2 Update!!

Zack DeRose — Wed, 20 Dec 2023 17:02:39 +0000

It's been a bit since we launched Nx 17! In this article, we'll go over some of the new developments and improvements that have landed in Nx 17.2:

Nx Closes In On 4 Million Weekly NPM Downloads!!
New Simplified Project Configuration On the Way
Rust for Speed, Typescript for extensibility
Module Federation Updates
Nx Release Updates
Angular 17 (AND NgRx 17) Support
Smart Monorepos - Fast CI
New Canary Releases

Nx Closes In On 4 Million Weekly NPM Downloads!!

2023 has been a great year for Nx! We worked with a lot of the teams out there building fantastic open source tools. And you can see the results: we made Vite a first class citizen in many of our Nx plugins, we added support for Rspack, streamlined our Node experience by adding an Nx team maintained Fastify plugin, support for Storybook interaction testing, welcomed Playwright to the family and much more, continuing our missing to push developer productivity to the limits!

And our downloads on NPM keep confirming this. We are about to cross 4 million downloads per week.

If this made you curious, keep an eye on our blog or X/Twitter as we're going to release a 2023 year recap blog post next week.

New Simplified Project Configuration On the Way

Adoption is crucial, and simplicity is the driver for adoption. Last year we heavily optimized how you can use Nx in an existing project. Just drop the nx package (or run nx init) and that's it. Nx understands your workspace and efficiently runs your package.json scripts.

Using Nx at that level is definitely useful as you get intelligent parallelization, task pipelines and caching. But it is just the tip of the iceberg of what Nx is actually capable of. Nx plugins provide much more, especially in terms of DX and developer productivity by taking away some of the burden of configuring your monorepo tooling. But many devs new to Nx found it harder to get started with them initially and incrementally migrating to Nx plugins wasn't as straightforward as we'd wanted it to be.

This is something that's gonna change drastically in 2024. And we've layed the first cornerstone for that. Nx 17.2 includes what we codename "Nx project config v3". But it is behind a feature flag still as we're streamlining the last bits. The goal?

going almost configuration-less (good defaults, you customize when you need to)
allowing easy drop-in of Nx plugins into existing workspaces (provides immediate productivity gains, but stays out of your way)

This opens up a series of possibilities which we're already super excited about. You'll hear more about this in the new year ;)

Rust for Speed, Typescript for extensibility

At Nx, we've heavily embraced Typescript from the beginning, and we've been very happy with that decision.

If you've been paying attention to previous release announcements though, you've probably noticed that we've been moving more and more of the computationally intensive and performance critical pieces of the core of Nx from Typescript to Rust.

That trend continues in Nx 17.2 with Nx using Rust for its task hashing by default. There's no adjustments needed for this change, and Nx will continue to behave the same way, just faster!

// Detect dark theme var iframe = document.getElementById('tweet-1724464283227234420-322'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1724464283227234420&theme=dark" }

Module Federation Updates

Module Federation has been a particularly hot topic lately, and 17.2 is coming in with some great enhancements to Nx's already best-in-class support for Module Federation!

To start, we've greatly reduced the CPU and memory used for standing up your Module Federation "web" locally. These enhancements should be great news to larger workspaces using a Module Federation approach, where there were heavy CPU and memory costs to serving your entire federation locally.

We accomplished these improvements by batching any applications that are not being watched for changes (listed with the --devRemotes option) to a single server, rather than a unique server for each application. We also parallelized the builds of these static applications when you start up your serve! You can now use the --parallel={number} option to specify how many builds you want going at any given time.

In addition to performance improvements, we've brought the concept of dynamic federation to our React module federation support. Dynamic federation allows a host application to dynamically load remotes via the manifest file.

You can generate your react module federation workspace now to use dyanmic federation via the --dynamic flag:

nx generate @nx/react:host acme --remotes=nx --dynamic

Or you can use the utility itself by importing from @nx/react/mf:

import { loadRemoteModule } from '@nx/react/mf';

Lastly, we have an example repo available now to illustrate how to create a plugin for Module Federation using Nx with Vite! This is something that we are monitoring and may provide an out-of-the-box solution to this in a future release!

Nx Release Updates

Nx 17 launched with the new nx release capability in the Nx CLI. Since then we've been streamlining the experience, accounting for various edge cases and release scenarios. (extensive docs are being worked on rn ;)

To give you full flexibility, in 17.2, we've added a programmatic API, which will allow you to easily write custom release scripts:

import {
  releaseChangelog,
  releasePublish,
  releaseVersion,
} from 'nx/release';

(async () => {
  const { workspaceVersion, projectsVersionData } = await releaseVersion({
    specifier: 'minor'
  });
  await releaseChangelog({
    versionData: projectsVersionData,
    version: workspaceVersion,
  });
  await releasePublish();

  process.exit(0);
})();

This script above demonstrates how you can use this API to create your own script for updating your workspace's version, then creating a changelog, and then publishing your package!

We've also added first class support for independently released projects, meaning you can now target a specific project for release with the --projects command. For example, you can create a new version for just one project in your workspace with the command:

nx release version patch --project=my-project

Angular 17 (AND NgRx 17) Support

Angular is in the middle of a HUGE renaissance, between their new logo, new docs site, and introduction of some awesome features like Signals.

Nx is here to support the transition! Nx has always been a great fit for Angular, and now supports Angular 17 as well as NgRx 17.

To automatically migrate existing workspaces to Angular v17, run the commands:

> nx migrate latest
> nx migrate --run-migrations

You can also use the --interactive flag if you want to migrate your workspace to the latest version of Nx while staying on your current version of Angular:

> nx migrate latest --interactive
✔ Do you want to update to TypeScript v5.2? (Y/n) · true
✔ Do you want to update the Angular version to v17? (Y/n) · false

 >  NX   The migrate command has run successfully.

   - package.json has been updated.
   - migrations.json has been generated.

 >  NX   Next steps:

   - Run 'nx migrate --run-migrations'

Smart Monorepos - Fast CI

We just gave our Nx homepage a small facelift, including a new tagline, subtagline and illustration to better reflect Nx's mission statement.

When you enter the monorepo space, having good local development experience and tooling to support you is one thing, scaling is the other. And scaling comes with multiple challenges, from scaling teams working on the monorepo to maintaining high throughput on CI.

The latter is a common headache and we've seen companies struggle. With Nx we're moving into the direction of becoming your e2e solution for monorepos, where we don't just cover your local dev experience, but also provide robust and scalable solutions on CI.

We're super excited to have launched "Nx Agents" to Early Access. If you haven't seen Victor's video yet about how he reduced e2e tests from 90 minutes to 10, then make sure to check it out.

"Nx Agents" are the next iteration of DTE, providing a more flexible, cost effective and more performant approach to distribution on CI. This includes things like being able to dynamically allocate machines based on the size of the PR and flaky task detection and re-running. Also, it can be configured with a single line:

- name: Start CI run
  run: 'npx nx-cloud start-ci-run --distributes-on="8 linux-medium-js"'
  ...

You can run Nx Agents on any CI provider. If you're curious, sign up for early access!

New Canary Releases

We've added a new npm release tag: canary!

This canary release is created via a cron job that will regularly publish the current contents of the master branch of Nx.

You can give the canary version a try new for a new workspace using the command:

> npx create-nx-workspace@canary

This should be useful for previewing new not-yet released features!

Upcoming Release Livestream

We're going live in January with the Nx team to go over these updates as well! Be sure to click the link to get notified when we go live! And feel free to come with your questions in the chat!

Automatically Update Nx

Updating Nx and its plugins is easy as we ship an automated migration command.

npx nx migrate latest

After updating your dependencies, run any necessary migrations.

npx nx migrate --run-migrations

Wrapping up

Learn more

More Nx Release Notes:

Nx 17.0 Has Landed!!!

Zack DeRose — Tue, 24 Oct 2023 14:46:00 +0000

We're excited to announce the release of Nx version 17!

In this article, we'll cover the main things you need to know to get the most of Nx 17!

Here's a Table of Contents so you can skip straight to the updates you care about the most:

It's a Vue-tiful Day for Nx
Enhancements to Module Federation Support
More Consistent Generator Paths
The NEW Nx AI Chatbot
More Seamless Integration With Nx Cloud
nx.json Simplification
Nx Repo Begins Dog-Fooding Nx Workflows
Task Graphing Improvements
@nx/linter Renamed to @nx/eslint
New Experimental Feature: Nx Release
Experimental: Nx Project Inference API v2
20k Github Stars!!
How to Update Nx

It's a Vue-tiful Day for Nx!

Ever since we added Vite a first-class citizen to Nx workspaces (see @nx/vite) we started falling in love with the Vue commmunity. The only logical next step: Nx now provides a brand new Vue plugin that is being maintained by the Nx team! (And we're already working on a Nuxt plugin 🤫)

The first place you might notice this new support is in the create-nx-workspace script:

Selecting this option will create a brand new Nx workspace with a fresh new Vue application, all setup and ready to develop! To add new Vue projects to your existing Nx workspaces, just add our new @nx/vue package as a dev dependency to your workspace, e.g.:

npm add -D @nx/vue

And you'll have access to Nx generators so that you can generate Vue applications, libraries, components, and more in your workspace:

We're very excited for this support to land and we're eager to get it into our user's hands and see what Nx can do to help Vue developers so we can continue to refine our support and make Vue with Nx an excellent developer experience.

If you're eager to learn more, make sure to check out our new Vue standalone tutorial.

Enhancements to Module Federation Support

Nx already had really great support for Module Federation - Nx 17 improves on this support:

NEW: Typesafe Config

Projects created with Nx's generators for module federation will now be created with a module-federation.config.ts file (as opposed to a .js file). A new ModuleFederationConfig interface is now exported from the @nx/webpack plugin as well.

Better Typesafety Across Modules

Nx 17 improves typesafety across modules now so that proper typesafety is now supported across dynamic imports.

NEW GENERATOR: Federate ANYTHING.

Both the @nx/react and @nx/angular now include a federate-module generator. This will allow you to create a federated module out of any Nx project.

To run this generator, use the command:

> nx g federate-module <project name> --path=<path to module to be exposed> --remote=<name of remote exposing module>

This will create a new project that exposes the targeted project as a federated module.

Managing Module Versions

Nx now supports targeted versioning for federated modules.

To create versions for a given project, you can use the version property of that project's package.json file, and then build that project create the version locally.

Then when consuming this library, you can use the shared method of the ModuleFederationConfig:

import { ModuleFederationConfig } from '@nx/webpack';

const config: ModuleFederationConfig = {
  name: 'my-remote',
  exposes: {
    './Module':
      'apps/my-remote/src/app/remote-entry/entry.module.ts',
  },
  remotes: ['federated-is-odd'],
  shared: (libName, configuration) => {
    if (libName === 'is-odd') {
      return {
        singleton: true,
        strictVersion: true,
        requiredVersion: '0.0.1',
      };
    }
    return configuration;
  },
};

export default config;

This config will make sure that version 0.0.1 of the is-odd is used.

More Consistent Generator Paths

Similar to the adjustments we made in 16.8 for most of our project-creating generators, v17 brings updates to how component generators work. The goal of these updates is to give you more control over the name and file location of your components.

Towards this end, we've added a new --nameAndDirectoryFormat option, that you can set to either as-provided or derived.

When set to as-provided, the generator will use the name option for the name of your component, and the directory option to determine where on your file system to add the component. as-provided will be used by default if none is specified.

When set to derived, the generator will try to determine where to create your component based on the project option - which will mostly operate how component generators do now.

In addition, component generators now follow any given casing for component files. For example, let's say that we have an integrated monorepo with a react application called "my-app", and we want to add a "Home" component. With Nx 17, you can run the command:

> nx g component Home --directory=apps/my-app/src/app

And a Home.tsx file will be added in the apps/my-app/src/app directory.

You can now also build your directory path right into generator command. For example, the same "Home" component would be created via:

> nx g component apps/my-app/src/app/Home

Finally, generators will now factory in your current working directory, so you can also create this "Home" component via:

> cd apps/my-app/src/app
> nx g component Home

The NEW Nx AI ChatBot

We've added a new AI ChatBot to our docs site. You can access it now at https://nx.dev/ai-chat

This feature is still in beta, so please use the thumbs up/thumbs down buttons to provide feedback on whether the chat bot is accurate and helpful!

More Seamless Integration With Nx Cloud

After running the nx migrate command to upgrade to Nx 17 and using Nx Cloud, you may have observed the removal of nx-cloud from your dev dependencies. Don't worry - Nx Cloud is not only still around but thriving. Instead of having a standalone package, we've integrated the Nx Cloud communication layer directly into the nx package. This ensures a seamless connection whenever you opt-in and eliminates potential version misalignment concerns with our API endpoint.

`nx.json` Simplification

Our Nx Cloud updates come alongside some other configuration changes in your nx.json file and project configuration as well.

Specifically, we've added an optional nxCloudAccessToken to the nx.json file - as long as a token is provided here, we'll make sure that you take advantage of the currently deployed version of Nx Cloud when running commands with Nx.

We've also removed the need to specify cacheableOperations at the task-runner level. From now on, every target configured in your project.json can be specified as cacheable using the cache property.

// nx.json
{
    "targetDefaults": {
        "build": {
            "cache": true,
            ...
        }
    }
}

If you used the nx migrate command, all updates will be handled for you, using the targetDefaults in your nx.json file. More on the docs.

In general, we've been working hard at reducing and simplifying all the configuration that is required for your Nx workspaces. Checkout our latest guide on how to Reduce Repetitive Configuration for more, and stay tuned as we've got new efforts underway to make this simplification even more appealing!

Nx Repo Dog-Fooding Nx Workflows

At Nx Conf in New York City, we unvieled the next big step for Nx: Nx Workflows.

If you missed it, Simon Critchley walks you through in his Nx Conf talk:

Put simply, Nx Workflows represents Nx entering the CI provider arena, where Nx can now provide you with Cloud Computation to run your CI tasks. This creates the foundation for a whole new class of Nx Cloud features that we're very excited to be working on in the coming cycles.

The Nx repo itself is now "dog-fooding" this latest feature (dog-fooding refers to using our tool in our own projects, or "eating our own dog food"), and you can see how it's going now on our public Nx Cloud workspace.

Nx Workflows are still in the experimental phase, we're running pilots with our enterprise clients and we're excited to open this up for everyone soon!

Task Graphing Improvements

Task Caching in Nx is based on a set of "input" files that are calculated for a given task. You can specify certain files or patterns of files in your project.json for a specific task or in the targetDefaults of your nx.json to set the default file sets for your inputs.

In the past, there's been some difficulties in determining specifically which files were included and which weren't for a given task. This is where our latest update to the task graph comes in:

You can open this graph using the command:

> nx graph

And then selecting "Task" from the "Project"/"Task" graph dropdown in the top left. Clicking on a specific task now allows you to see a comprehensive list of all files that were factored in as inputs for this task:

`@nx/linter` Renamed to `@nx/eslint`

After running nx migrate, you may have noticed that the @nx/linter plugin was removed and replaced with @nx/eslint.

In Nx 17, we removed any remaining traces of tslint from our linter package, so this is mainly a simple rename to more accurately describe the package (and to remove any confusion that this package is intended to support linting for other languages/platforms).

New Experimental Feature: Nx Release

nx release is a new top level command on the Nx CLI which is designed to help you with versioning, changelog generation, and publishing of your projects:

nx release version - Determine and apply version updates to projects and their dependents
nx release changelog - Generate CHANGELOG.md files and optional Github releases based on git commits
nx release publish - Take the freshly versioned projects and publish them to a remote registry

nx release is still experiment and therefore subject to change, but the Nx repo itself is now using these commands to version itself, as well as generate changelogs, Github releases, and publish our packages to npm.

As we solidify this command, we intend to bring robust support for various versioning and publishing strategies, as well as built-in support for publishing packages or modules to a variety of languages, registries, and platforms.

For more checkout our API docs, and be sure to catch James Henry's announcement of this new command at Nx Conf:

Experimental: Nx Project Inference API v2

At Nx, we're OBSESSED with building a better, more robust experience for our developers. Towards this end, we're now in v2 of our Project Inference API.

This API is a way of extending the Nx project graph, which can be particularly helpful for extending Nx to support other languages, allowing Nx to determine where to find and draw boundaries around projects in your workspace. A great example is our very own Vue plugin.

Interestingly, v2 includes support for dynamic targets as well. This opens up exciting new doors to reducing configuration, and we hope to expand on this to better support our first-party plugins in the near future.

For most developers, the main thing you need to know is that plugins may now add additional targets that you won't see in your project.json file. To see your actual project configuration, you can now use the command:

nx show project <project_name>

For plugin authors, check out the v2 documentation to see how you can take advantage of the new API to deliver a better experience to your users.

20k Github Stars!!

Nx is SOOO CLOSE to 20,000 stars on github! If Nx has been helpful to you, please help us get there!

How to Update Nx

Nx is known to help you automatically migrate to the new version (including potentially breaking changes). To update simply run:

npx nx migrate latest

This will update your Nx workspace dependencies, configuration and code to the latest version. After updating your dependencies, run any necessary migrations.

npx nx migrate --run-migrations