Evaluating turbo: how to run a dev command for "current" project and all its dependencies

[stevebeauge]

Summary

Hi,

I'm maintaining a large monorepo, currently orchestrated by nx. However, due to reliability issues, I'm evaluating the opportunity to migrate to turbo.

The repository contains different types of packages (25 packages):

• typescript libraries. Some of these packages are react libraries. Currently, packages are built using heft (another tool to migrate, but that's another story)
• vite web application
• some exotic web apps, based on a 3rd party compiler which use webpack 4 internally (Microsoft SharePoint Framework if it matters).
• and some config/tooling packages

Because of the internal architecture of the webapp compilation), running a "watch mode" for a web app requires watching the webapp itself but also every dependencies.

This leads to a few questions:

Shorthand for "current project" ?

As far as I understand, if I want to run a "serve" command for a project and all its dependencies, I need to execute pnpm turbo run serve --filter "@myrepo/somewebapp...".

Is there a simpler command to run this? Is there any shorthand to express run this script in the current folder, and all its dependencies ?

I can probably add another package.json script like "start-serve" : "turbo run serve --filter \"@myrepo/somewebapp...\"" but it adds extra maintenance to every web apps.

Concurrency pressure

If a webapp requires a large dependency stack, the concurrent tasks are eating all CPU and memory.

turbo detects automatically the depth of dependencies and suggest to add --concurrency 12 (actual depth of my repo).

So running the serve command will create 12 concurrent serve operations for every package, which makes the system being unusable. My laptop is a core I7 + 16gb of ram, and the CPU + RAM are getting used at max.

How to prevent this ?

As a side note, the "nx" version of my repo rely on the nx "global watch" command. There's a single watch context, for the whole repo, and nx call a package.json script "build-incremental" on package owning the change. It's not as efficient as a real watch mode, like tsc --watch, but it allows me to keep the system working.

Thanks for any insights

Additional information

No response

Example

No response

[anthonyshew]

Is there a simpler command to run this? Is there any shorthand to express run this script in the current folder, and all its dependencies ?

You can do this with global turbo (or writing a turbo command into the package.json of the application): https://turbo.build/repo/docs/installing#install-globally

As far as a "global watcher" goes, we're building a Watch Mode right now.

[stevebeauge]

Sorry if I wasn't clear. It's not prepending pnpm to my command which is the issue, but to have to explicitly name the current project.

Ideally, I'd like to be able to run pnpm turbo serve this... or any kind of alias.

You are right of course, I can still add a custom script inside package.json to write once the full command.

Regarding the watch mode, It's cool it's in progress.

thanks for the help

[ignaciobockl]

Hi @stevebeauge. Two separate questions here — both solvable with Turborepo's built-in features.

1. Shorthand for "current project + dependencies"

Turborepo has Automatic Package Scoping when turbo is installed globally. From the Running Tasks docs:

When you're in a package's directory, turbo will automatically scope commands to the Package Graph for that package.

# Install turbo globally (pick your package manager)
npm install -g turbo

# cd into your webapp, then just run
cd apps/my-webapp
turbo run serve

This runs serve for that package and its dependencies — no --filter needed.

If you need the dependency tree explicitly, use the ... microsyntax from the Filters docs:

turbo run serve --filter=my-webapp...

The ... suffix means "this package and everything it depends on."

2. Concurrency pressure

The default concurrency is 10 (see configuration reference). You can adjust it in turbo.json:

{
  "$schema": "https://turborepo.dev/schema.json",
  "concurrency": "12",
  "tasks": {
    "serve": {
      "dependsOn": ["^serve"],
      "persistent": true
    }
  }
}

Or override at runtime:

turbo run serve --filter=my-webapp... --concurrency=12

The persistent flag is important for long-running tasks like dev servers — it tells Turborepo they won't exit, so dependent tasks aren't blocked (docs).

3. Hardware context

I run concurrency: 12 (or higher) without issues on my setup: AMD Ryzen 7 (8 cores / 16 threads), 32GB RAM, NVMe SSD, Windows 11. The bottleneck in your case is likely the combination of i7 + 16GB RAM trying to run 12 concurrent serve processes — each dev server consumes significant memory and CPU. Consider lowering to 4–6 and observing system resources, or upgrading RAM if the dependency tree requires high parallelism.

4. Consider Bun as your package manager

Turborepo has first-class Bun support (installation docs). If install times are part of the friction, Bun is worth evaluating:

Manager	Cold install (847 deps)	Warm install
pnpm	~12s	~4s
Bun	~2s	<1s

Migration is straightforward:

// root package.json
{
  "packageManager": "bun@1.4.0",
  "workspaces": ["apps/*", "packages/*"]
}

rm pnpm-workspace.yaml pnpm-lock.yaml
bun install
turbo run build  # same turbo.json, no pipeline changes

Bun workspaces use the same "workspaces" field as npm/yarn (Bun workspace docs). Your turbo.json pipeline stays identical.

Key advantage: Bun's faster module resolution means each dev server starts quicker, reducing total time under heavy concurrent load.

Tradeoff to note: pnpm's --filter graph selectors have more community documentation. If you use complex filter expressions like --filter="...^@scope/pkg", test them with Bun first. 

[stevebeauge]

Thanks for your answer. I've abandonned turbo for a long time now, for many reasons. I stayed with NX because NX has a global file watcher that helped me to rebuild dependencies when needed. Only one process, though longer build times. Turbo's watch command was not available at this time (still V1 if I remember correctly). Moving to turbo now may work, but I can't see any ROI yet.

That said, I don't see in your 4 points what's new to what I tried.