DEV Community: Suryansh Sharma

Monorepos!! Nx vs Turborepo vs Lerna – Part 3: Lerna

Suryansh Sharma — Thu, 05 Jun 2025 11:43:33 +0000

In our previous post, we walked through setting up a Nx monorepo containing a React web app, a Node.js API, and a React Native mobile app. In this post, we'll achieve the same setup using Lerna as our monorepo tool of choice.

Getting Started with the Monorepo

Start by creating a new directory for your monorepo, navigating into it, and initializing Lerna. This sets up the foundational structure for your project, including the necessary configuration files and a packages folder where your future sub-projects will reside.

mkdir Lerna
cd Lerna
npx lerna init

Setting Up the React Website

Next, we'll create a packages directory (if it doesn't already exist), navigate into it, and scaffold a new Vite project. This is where we'll add individual packages or apps managed by Lerna.

mkdir packages
cd packages
npm create vite@latest

Now, navigate into your new project directory (for example, website), install all required dependencies, and launch the development server to start building and previewing your app in real time.

cd website
npm install
npm run dev

Setting Up the Node Backend

Run the following commands:

cd ../
mkdir api
cd api
npm init

These commands move you up one directory level, create a new api folder, and enter it. Running npm init then initializes a new Node.js project, allowing you to configure your API package from scratch. This is the foundation for building a clean, modular Node.js REST API, following best practices for project organization and scalability.

Create a new file in the packages/api folder named index.js and paste the following code in it. This is a basic express server.

import express from 'express';

const app = express();
const PORT = 3001;

app.get('/', (_req, res) => {
  res.send('Hello from the API!');
});

app.listen(PORT, () => {
  console.log(`API listening on port ${PORT}`);
});

Now add scripts and packages in the package.json file to run the project. The final package.json file will look like this.

{
  "name": "api",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "dev": "nodemon index.js",
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "keywords": [],
  "author": "",
  "license": "ISC",
  "dependencies": {
    "express": "^5.1.0"
  },
  "devDependencies": {
    "nodemon": "^3.1.10"
  }
}

Run npm install command to install the packages.
Run npm run dev to start the api.

Setting Up the Bare React Native App

To set up a bare React Native project as a package within your Lerna monorepo using npm workspaces, follow these steps:

cd packages
npx @react-native-community/cli@latest init mobileApp

These commands navigate into your packages directory and initialize a new bare React Native project named mobileApp.
After initializing your React Native project, you need to install the native iOS dependencies using CocoaPods. This step is essential for the iOS part of your React Native app to work correctly.

cd mobileApp/iOS
pod install

Once you have installed the CocoaPods dependencies, you’re ready to start your React Native development server and launch the app on the iOS simulator.

cd ../
npm run start
npm run ios

Resolving Git Submodule Errors

Now that the app is up and running, it's time to commit your changes.
However, there's a small issue with the starter template—it initializes a Git repository inside the newly created apps/mobileApp folder. To get ride of that git submodule, from the root folder:

rm -rf apps/mobileApp/.git
git add .
git commit -m "create mobileApp"

We now have a working mobile app located in the apps folder, fully integrated into the monorepo with a clean Git setup.

Conclusion

By following these steps, you’ve successfully set up a scalable monorepo using Lerna and npm workspaces, and added both web (Vite), API (Node.js), and mobile (React Native) projects under a single repository. This unified workflow streamlines dependency management, code sharing, and collaboration across your entire stack. Whether you’re building for web, API, or mobile, this monorepo approach will help you stay organized, boost productivity, and simplify project maintenance as your codebase grows. Happy coding!

You can find all the code in the Github Repo.

Monorepos!! Nx vs Turborepo vs Lerna – Part 2: Nx

Suryansh Sharma — Mon, 26 May 2025 06:44:58 +0000

In our previous post, we walked through setting up a Turborepo monorepo containing a React web app, a Node.js API, and a React Native mobile app. In this post, we'll achieve the same setup using Nx as our monorepo tool of choice.

Getting Started with the Monorepo

We will start by creating an Nx workspace. Follow the official documenttion of Nx. You can use the package manager of your choice, i will be using the npm packae manager.

npx create-nx-workspace@latest

This will guide you through the setup, asking whether you want a monorepo or a standalone app and whether you want to start with a blank or a preconfigured setup.

Once you've created your workspace, you can

run single tasks with npx nx <target> <project>
run multiple tasks with npx nx run-many -t <target1> <target2>

You can also install the Nx Console official extension on vscode to start commands from there rather then using cli.

Run the npx nx dev website or click on the run icon on the dev command to run the project.

 NX   @nx-monorepo/website:serve  
    VITE v6.3.5  ready in 96 ms
    ➜  Local:   http://localhost:4200/
    ➜  press h + enter to show help

The above command created an nx workspace with a React website so we just need to add Nodejs API and React Native app now.

Setting Up the Node Backend

We are going to use the @nx/node plugin to add a Nodejs API to our monorepo.
In any Nx workspace, you can install @nx/node by running the following command:

npx nx add @nx/node

This will install the correct version of @nx/node. You can add a new application with the following command:

npx nx g @nx/node:application apps/<your api name>

You can run your application with npx nx serve api or using the Nx Console extension.

You can see the {"message":"Hello API"} response on http://localhost:3000

Setting Up the React Native App

We are going to use the @nx/react-native plugin to add a React Native App to our monorepo. In any Nx workspace, you can install @nx/react-native by running the following command:

npx nx add @nx/react-native

This will install the correct version of @nx/react-native. You can add a new application with the following command:

npx nx g @nx/react-native:app apps/<your-app-name>

You can run your application with npx nx start run-ios or using the Nx Console extension.

This is the final folder structure of the project.

Conclusion

With the initial Nx setup complete, we now have a fully functional monorepo that integrates our React web app, React Native mobile app, and Node.js API. This structure allows us to share configurations, utilities, and React hooks across all platforms, streamlining development and promoting consistency and code reuse throughout the codebase.

You can find all the code in the Github Repo.

Monorepos!! Nx vs Turborepo vs Lerna – Part 1: Turborepo

Suryansh Sharma — Wed, 14 May 2025 16:11:42 +0000

As a developer, choosing the right tooling is critical when adopting a monorepo structure especially when aiming for scalability, efficiency, and code sharing. I recently went through this decision making process at Yosemite Crew, where we are building an Open Source Operating System for Animal Health.

This post is the first in a series where we'll walk through setting up a React website, an Express API, and a React Native app using three different monorepo tools. At the end of the series, we'll compare the pros and cons of each approach, and I’ll explain why Turborepo was ultimately the best fit for our use case.

Getting Started with the Monorepo

We are going to use pnpm(follow the official documentation to install pnpm) as our package manager and vercel's turborepo to handle the monorepo.
To begin, we'll follow the official Turborepo documentation. Start by creating your monorepo using pnpm and the Turborepo vite-react template.

pnpm dlx create-turbo@latest -e with-vite-react

Paste the above command in any terminal and then it will prompt you two questions:

Where would you like to create your Turborepo? react-node-native
Which package manager do you want to use? 
npm 
❯ pnpm 
  - yarn (not installed)
  - Bun (beta) (not installed)

Enter the project name in the first prompt and select pnpm as the package manager in the second.

After you answer the two setup questions, the installation process will begin. This may take a few minutes, depending on your internet speed.
Once the setup is complete, open your code editor. You should see the boilerplate structure, which includes one app(web) and three packages(eslint-config, typescript-config, and ui).

We can use the web app which comes with the template but i prefer building all my apps from scratch so we will delete the web and create one of our own.

Setting Up the React Web App

We are going to use the Vite Starter for this Web App.

pnpm create vite

Use any package name you want just remember to add /apps/ before it. Then select React and Typescript.

◇  Project name:
│  /apps/website
│
◇  Select a framework:
│  React
│
◇  Select a variant:
│  TypeScript

You can check out the new React app in the apps folder. From the root folder run:

pnpm install
pnpm dev

This command will start the website and serve it on port 5173.

website:dev:   VITE v6.3.5  ready in 1607 ms
website:dev: 
website:dev:   ➜  Local:   http://localhost:5173/
website:dev:   ➜  Network: use --host to expose
website:dev:   ➜  press h + enter to show help

You can see the Vite + React on your https://localhost:5173.

Setting Up the Node Backend

Inside your monorepo root, run these commands.

mkdir apps/api
cd apps/api
pnpm init
cd ../../

Install the express and nodemon package to build a basic backend.

pnpm add express --filter api
pnpm add nodemon -D --filter api

Create a new file in the apps/api folder named index.js and paste the following code in it. This is a basic express server.

import express from 'express';

const app = express();
const PORT = 3001;

app.get('/', (_req, res) => {
  res.send('Hello from the API!');
});

app.listen(PORT, () => {
  console.log(`API listening on port ${PORT}`);
});

Now add scripts in the package.json file to run the project. The final package.json file will look like this.

{
  "name": "api",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "dev": "nodemon index.js",
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "keywords": [],
  "author": "",
  "license": "ISC",
  "dependencies": {
    "express": "^5.1.0"
  },
  "devDependencies": {
    "nodemon": "^3.1.10"
  }
}

Now from the root folder run:

pnpm dev

This command will start both the react website and node api on ports 5173 and 3001 respectively.

api:dev: 
api:dev: > api@1.0.0 dev /Users/suryansh/Projects/react-node-native/apps/api
api:dev: > nodemon index.js
api:dev: 
website:dev: 
website:dev: > website@0.0.0 dev /Users/suryansh/Projects/react-node-native/apps/website
website:dev: > vite
website:dev: 
api:dev: [nodemon] 3.1.10
api:dev: [nodemon] to restart at any time, enter `rs`
api:dev: [nodemon] watching path(s): *.*
api:dev: [nodemon] watching extensions: js,mjs,cjs,json
api:dev: [nodemon] starting `node index.js`
api:dev: (node:36402) [MODULE_TYPELESS_PACKAGE_JSON] Warning: Module type of file:///Users/suryansh/Projects/react-node-native/apps/api/index.js is not specified and it doesn't parse as CommonJS.
api:dev: Reparsing as ES module because module syntax was detected. This incurs a performance overhead.
api:dev: To eliminate this warning, add "type": "module" to /Users/suryansh/Projects/react-node-native/apps/api/package.json.
api:dev: (Use `node --trace-warnings ...` to show where the warning was created)
api:dev: API listening on port 3001
website:dev: 8:19:28 pm [vite] (client) Re-optimizing dependencies because lockfile has changed
website:dev: 
website:dev:   VITE v6.3.5  ready in 139 ms
website:dev: 
website:dev:   ➜  Local:   http://localhost:5173/
website:dev:   ➜  Network: use --host to expose
website:dev:   ➜  press h + enter to show help

You can also run the api or website only using the filter flag.

pnpm dev --filter api

Setting Up the Bare React Native App

For this section, we’re going with the standard React Native starter, without any framework integrations.
Run the following command in the apps folder:

cd apps
pnpm dlx @react-native-community/cli@latest init mobileApp

Choose y at the question to install CocoaPods now.

✔ Downloading template
✔ Copying template
✔ Processing template
✔ Installing dependencies
✔ Do you want to install CocoaPods now? Needed for running iOS project … yes

The react native starter will then install all the required files and dependencies.

At this stage, all of our mobile app files are located in apps/mobileApp.
However, there's a small issue: since we used @react-native-community/cli@latest to initialize the project, it defaulted to using npm instead of pnpm. To fix this, we need to clean up a few files:

In apps/mobileApp, delete the package-lock.json file and the node_modules folder.
Then, navigate to apps/mobileApp/ios and remove the Podfile.lock file and the entire Pods directory.

Once everything has been cleared, you can reinstall the dependencies using pnpm in the root folder:

pnpm install

Then re-install the Pods

cd appd/mobileApp/ios
pod install

At this point, you have a fresh React Native mobile app set up with pnpm. To start the app, open two separate terminal windows and run the following from the /apps/mobileApp folder:

pnpm start

pnpm ios

This should install the app on the iOS simulator, but you'll likely see a blank screen along with an error message in the Metro server console:

This error occurs because we're using pnpm to manage our dependencies. Unlike npm, pnpm uses symlinks in its node_modules, which Metro doesn't support out of the box. As a result, Metro fails to resolve the modules correctly.
To fix this, you need to enable symlink support in Metro. The solution depends on the version of React Native you're using.

For React Native versions≥0.72, update your metro.config.js file to this:

const {getDefaultConfig, mergeConfig} = require('@react-native/metro-config');
const path = require('path');

/**
 * Metro configuration
 * <https://reactnative.dev/docs/metro>
 *
 * @type {import('metro-config').MetroConfig}
 */
const config = {
  resolver: {
    unstable_enableSymlinks: true, // this enable the use of Symlinks
  },
  // this specifies the folder where are located the node_modules for the project
  watchFolders: [path.join(__dirname, '..', '..')],
};
module.exports = mergeConfig(getDefaultConfig(__dirname), config);

For older React Native versions, the Symlinks option does not exist on Metro itself. We will need some external packages to the rescue.
Install the two packages @rnx-kit/metro-config and @rnx-kit/metro-resolver-symlinks and update your metro.config.js file as follow:

const path = require('path');
const {makeMetroConfig} = require('@rnx-kit/metro-config');
const MetroSymlinksResolver = require('@rnx-kit/metro-resolver-symlinks');

module.exports = makeMetroConfig({
  projectRoot: __dirname,
  resolver: MetroSymlinksResolver(),
  watchFolders: [path.join(__dirname, '..', '..')],
});

After applying the necessary changes, close the app and restart the Metro server using the --reset-cache flag. Then, reopen the app. You should now see the default React Native starter screen.

Resolving Git Submodule Errors

rm -rf apps/mobileApp/.git
git add .
git commit -m "create mobileApp"

We now have a working mobile app located in the apps folder, fully integrated into the monorepo with a clean Git setup.

Conclusion

With the initial setup complete, we now have a fully functional monorepo that brings together our React (web), React Native (mobile), and Node.js (API) applications. This structure enables us to share configurations, JavaScript utilities, and React hooks across platforms, greatly enhancing development efficiency and ensuring consistent code quality throughout the project.

You can find all the code in the Github Repo.

Optimizing Dev Collaboration: Monorepo or Multi-Repo?

Suryansh Sharma — Thu, 24 Apr 2025 15:49:59 +0000

Architectural decisions shape how teams scale. And one of the earliest and most debated is choosing between a monolith, monorepo, or multi-repo. I had to make the same decision as a Founding Engineer at Yosemite Crew. We are trying to build an Open Source Operating System for Animal Health where we are developing a PMS for vets and providing developers a plugin like feature to develop on top of our PMS.

In this article, we’ll delve into the advantages and disadvantages of all the approaches, helping you make an informed decision to enhance collaboration within your dev teams.

What is a monorepo?

A monorepo consolidates multiple projects or components into a single repository, promoting code reuse and simplifying dependency management while maintaining consistency across teams and services.

A related concept is the monolithic application. While a monolith bundles all functionality into a single, tightly integrated codebase, a monorepo can house multiple independent projects within the same repository. Major tech companies like Google, Meta, Microsoft, Uber, Airbnb, and Twitter all use large-scale monorepos, each with its own strategies to handle massive codebases, high-frequency changes, and complex build and version control systems.

Advantages

A monorepo fosters collaboration by centralizing codebases, making it easier for developers to access, review, and contribute to various components without the need to switch between multiple repositories. This creates a more unified and efficient team environment.
In a monorepo, managing project dependencies is typically more straightforward. Shared dependencies are centralized, reducing the likelihood of version conflicts and simplifying the process of updating libraries across the entire codebase.
Monorepos promote consistent coding practices and encourage code reuse. When similar functionality is needed across multiple projects, developers can implement it in a single location, reducing redundancy and ensuring consistency throughout the codebase.
Refactoring code across multiple projects is simpler in a monorepo. Developers can make changes and immediately test their effects on different components, ensuring a smoother and more cohesive transition.
With all related projects housed in one place, navigating a monorepo is more intuitive. This improves code discoverability, allowing developers to easily learn from each other’s work and fostering a culture of knowledge sharing.

Disadvantages

One of the key drawbacks of monorepos is performance. Storing code from different functions and contexts in a single repository can slow down operations like code pulls.
When a repository contains multiple sub-projects, managing continuous integration (CI) and continuous delivery (CD) processes can become challenging. It's also crucial to determine whether there are dedicated DevOps teams or individuals available to support this type of code management.
Monorepos can also complicate security, as they grant developers who may only be working on a specific portion of the project full access to the entire codebase. Ideally, there should be clear separation between the different projects within a monorepo, and each project should have its own versioning strategy in place from the start to streamline integration, team coordination, and maintenance.

What is a multi-repo?

A multi-repo is a software development strategy where different projects or components of a larger application are stored and managed in separate repositories. Each project or component has its own version control system, allowing teams to work independently on different parts of the system. This contrasts with a monorepo, where all the code resides in a single repository.

Multi-repo setups are often preferred to establish clear boundaries between projects, enabling teams to work autonomously while minimizing the potential for conflicts when making changes.

Advantages

Multi-repositories give teams full control over their own projects. Each team can define its own workflow, tooling, and release schedule, promoting a strong sense of ownership and accountability. This isolation helps maintain the stability and reliability of critical applications.
In a multi-repo setup, issues within one project are less likely to impact others, minimizing the risk of widespread outages across the system.
As projects expand, multi-repos provide greater scalability. Teams can manage their own repositories independently, reducing the likelihood that a single monolithic repository will become cumbersome and slow down development.
With multiple repositories, teams can optimize their continuous integration and continuous delivery (CI/CD) pipelines. Changes to one project only trigger build and deployment processes for the relevant components, improving efficiency.
Developers can concentrate on their specific project's codebase, reducing cognitive load and minimizing distractions from unrelated changes. This focused approach can enhance code quality and accelerate development cycles.

Disadvantages

Applying clean code practices and refactoring can be challenging in a multi-repo setup. While there are initial workarounds to help standardize processes across teams, code duplication becomes a significant risk.
Unit and integration tests are generally easy to manage in a multi-repo environment, but running end-to-end tests can be more complicated. Since the codebase is split across multiple repositories, pulling in dependencies from different sources becomes necessary. Fortunately, this can be addressed by having dedicated Quality Assurance (QA) team members who focus on testing the complete application flow.
Managing dependencies can lead to friction between teams if there isn't a clear strategy for periodically updating and implementing the latest versions. 4.Isolation between teams can hinder effective engineering practices and communication. Without a strong onboarding culture, integrating new team members successfully can be difficult and disruptive.

Conclusion

Ultimately, choosing between a monorepo and a multi-repo strategy comes down to finding the right balance between collaboration and autonomy. Each approach offers distinct benefits and trade-offs, so it's important to consider your team's structure, project complexity, and long-term objectives.

In my case we are building an open source project so it will be much easier for developers to contribute in a monorepo. Now the next question arises, what tool or build system should we use for a monorepo? NX, learn or turborepo. That's a discussion for another time.

Take a look and star ⭐ our monorepo and of course contributions are always welcome.

Yosemite Crew Github