A monorepo is a beautiful thing when it works — one repo, many packages, a single install and lint. It’s also an easy way to lose your bearings. The deeper the tree, the more packages, the harder it is to answer the simplest questions:

  • Where is the frontend app?
  • Which package do I open for this?
  • What’s the command to run that sub-project?
  • Which editor should I launch, and into which folder?

If you’ve ever stared at packages/apps/web/src/ and felt a small spike of dread, this guide is for you. It’s a practical, low-overhead approach to managing a monorepo of side projects on macOS — without installing yet another heavy tool.

1. Make the structure legible before anything else

Monorepos get unmanageable when the layout is ambiguous. Start with a boring, predictable convention:

my-monorepo/
  apps/
    web/
    api/
  packages/
    ui/
    lib/
  tools/

Nothing clever. The value of a convention isn’t elegance — it’s that you never have to think about where something lives. Write it once in a top-level README.md with a one-line purpose for each folder. Future-you will be grateful.

2. Don’t jump through the tree by hand

Navigating a monorepo by opening a deep file path in your editor is a recipe for context loss. Instead, you want a way to see the sub-projects as a list and jump into one with a click.

This matters because sub-projects inside a monorepo behave like their own little side projects — they have a name, a directory, a script to run. Treating them that way makes a monorepo feel like a set of projects rather than a wall of folders.

Dev WorkDir handles this on macOS: it auto-detects monorepos (JavaScript/TypeScript, Rust, Go), shows a MONO badge, lists all sub-projects in one view, and lets you open any sub-project directly in your editor — or create a new one right inside the monorepo.

Add monorepo root
  → sub-projects appear as cards
  → click one → opens in editor
  → right-click → create sub-project

The entire “where is it / why is it / how do I open it” problem collapses into a card list.

3. Give every package a run command

Inside a monorepo, the command to run one package is often forgotten because it changes. From npm run dev -w @you/app, to workspace scripts, to build order.

Two habits that save you:

  1. Define a workspace-level script in the root package.json for the actions you do most (e.g. npm run dev:web, npm run build:ui).
  2. Store the per-package run command next to the package, not in your head.

With a project launcher, the second one is automatic — each sub-project remembers how it runs, and a double-click does it. You’re not hunting for package names or flags anymore.

4. Keep dependencies out of your head

The part of a monorepo that bites people hardest is dependency management — which package depends on which, and the docs that drift out of date. You can’t easily fix tooling, but you can avoid overlapping with your project launcher.

Your launcher should be about where things are and how to run them. Root it at the monorepo root, let it surface sub-projects, and leave dependency graph analysis to the tools (pnpm, Turborepo, Nx) built for it.

The concise workflow

For a monorepo of side projects on macOS:

  1. Adopt a predictable apps/ + packages/ layout.
  2. Open sub-projects from a card list, not deep paths — on macOS, Dev WorkDir already does this.
  3. Remember one run command per package, stored with the package.
  4. Keep your launcher about “where + run,” not dependency analysis.

A monorepo stops being scary the moment navigating it becomes one click instead of a mental map. If you’re also wrangling several separate side projects (not just one monorepo), the same idea scales — see how to organize side projects.

Explore Dev WorkDir’s monorepo support or see the full feature list.