[{"_1":2,"_3":-5,"_4":-5},"loaderData",{"_5":6,"_7":8},"actionData","errors","routes/_layout",{"_106":107},"routes/blog/index",{"_9":10,"_11":12,"_13":12,"_14":15,"_16":17,"_18":19},"posts",[39],"page",2,"totalPages","tag","Node.js","allTags",[20,21,22,23,24,25,26,27,28,29,30,31,15,32,33,34,35,36,37,38],"total",7,"Android","Architecture","CSS","Database","Databases","Docker","Finance","Homelab","JavaScript","Linux","NestJS","Networking","Performance","PostgreSQL","Project","Proxmox","React","TypeScript","Ubuntu",{"_40":41,"_42":43,"_44":45,"_46":47},"slug","monorepos-in-javascript-typescript","meta",{"_84":85,"_86":87,"_88":89,"_90":91,"_92":93,"_94":95,"_96":97},"html","

In this post I will say a word on how I am structuring and maintaining monorepos. A monorepo is mostly a tooling decision, so this note is mostly about the tooling. It solves version mismatches, duplicated configs, and CI pipelines which you copy-paste from one repo to the next, but the package manager and the task runner are the things which actually do that work.

So a monorepo is one repository which holds several separate projects or packages. A monolith is one deployable unit, and a monorepo is not that. The packages inside it still deploy and version on their own, and the boundaries between them stay clear.

A typical structure:

my-monorepo/\n├── packages/\n│   ├── ui/            # shared component library\n│   ├── utils/         # shared utilities\n│   └── config/        # shared tsconfig, eslint, etc.\n├── apps/\n│   ├── web/           # Next.js frontend\n│   ├── api/           # Express/Fastify backend\n│   └── admin/         # admin dashboard\n├── package.json\n├── pnpm-workspace.yaml\n└── turbo.json

The apps/ folder holds deployable applications. And packages/ folder holds the shared libraries which those apps use. No tool enforces this split. It is just what most of teams do.

What you actually get out of it

Atomic changes, mostly. You can refactor a shared utility and update every caller in a single PR, with no release to publish and no version bumps in four repos. The rest follows from having one tree. One ESLint config and one TypeScript base instead of a copy per project. A single lockfile and one node_modules to audit. And you do not publish to npm just to share a helper between two internal apps.

Pick the package manager first

The three major package managers all support workspaces, but the differences between them matter.

npm workspaces are built in since npm 7. Fine for small setups, slower and less strict than the rest.

// package.json (root)\n{\n  "name": "my-monorepo",\n  "private": true,\n  "workspaces": ["packages/*", "apps/*"]\n}

Yarn (Berry/v4) has Plug'n'Play. Clever idea, but it breaks any tool which expects a real node_modules. Use it if your team already runs Yarn and is comfortable with PnP. Otherwise it adds trouble which you don't need.

pnpm is the one which I would choose. It is fast, and it blocks imports of any dependency which you did not declare, so there are no phantom deps. Its workspace support is the best of the three. The content-addressable store also keeps disk usage low, which you notice once you have a dozen packages that each pull in React.

# pnpm-workspace.yaml\npackages:\n  - 'packages/*'\n  - 'apps/*'

Running commands with pnpm:

# install a dep in a specific package\npnpm add zod --filter @myorg/api\n\n# run a script in a specific package\npnpm --filter @myorg/web dev\n\n# run a script in all packages that have it\npnpm -r run build

The --filter flag takes package names, directory paths, or a git diff. For example, --filter ...[HEAD~1] targets only the packages which changed since the last commit.

One tsconfig to extend

Instead of copy-pasting tsconfig.json across packages, I suggest to create a shared base:

// packages/config/tsconfig.base.json\n{\n  "compilerOptions": {\n    "target": "ES2022",\n    "module": "ESNext",\n    "moduleResolution": "bundler",\n    "strict": true,\n    "esModuleInterop": true,\n    "skipLibCheck": true,\n    "forceConsistentCasingInFileNames": true,\n    "resolveJsonModule": true,\n    "isolatedModules": true,\n    "declaration": true,\n    "declarationMap": true,\n    "sourceMap": true\n  }\n}

And each package extends it:

// apps/web/tsconfig.json\n{\n  "extends": "@myorg/config/tsconfig.base.json",\n  "compilerOptions": {\n    "outDir": "dist",\n    "rootDir": "src"\n  },\n  "include": ["src"]\n}

The same pattern works for ESLint, Prettier, and anything else which you would otherwise copy around.

Internal packages don't need a build

Shared packages which are used only inside the repo don't need a build step at all. Point the package's exports straight at the TypeScript source:

// packages/utils/package.json\n{\n  "name": "@myorg/utils",\n  "version": "0.0.0",\n  "private": true,\n  "exports": {\n    ".": {\n      "types": "./src/index.ts",\n      "default": "./src/index.ts"\n    }\n  }\n}

This works because the apps (Next.js, Vite, and similar tools) transpile the imported source through their own bundler anyway. So there is no separate build step in development, and a change to a shared util shows up right away in any app which imports it.

This changes the moment you publish a package to npm. Then you need a real build with tsc or tsup. For purely internal packages, skip it.

Running tasks: Turborepo or Nx

Past a few packages, you start to care about running builds and tests in the right order, and about not redoing work which hasn't changed.

Turborepo is the simpler option and needs little configuration:

// turbo.json\n{\n  "$schema": "https://turbo.build/schema.json",\n  "tasks": {\n    "build": {\n      "dependsOn": ["^build"],\n      "outputs": ["dist/**"]\n    },\n    "dev": {\n      "cache": false,\n      "persistent": true\n    },\n    "lint": {},\n    "test": {\n      "dependsOn": ["build"]\n    }\n  }\n}

"dependsOn": ["^build"] means "build my dependencies before building me." Turborepo reads the graph and runs in parallel what it can. The cache uses a content hash as its key, so if the inputs haven't changed it just replays the previous output.

# run build across all packages, respecting dependency order\nturbo build\n\n# run dev servers for web and api in parallel\nturbo dev --filter=@myorg/web --filter=@myorg/api

Nx is more powerful and more opinionated: a plugin system, code generators, affected-based testing, a cloud cache. It is worth it on large setups, somewhere above fifty packages. Below that, I would start with Turborepo. Moving from Turborepo to Nx later is not hard. Going the other way is the painful one.

Wiring packages to each other

Reference internal packages in the dependencies field with the workspace protocol:

// apps/web/package.json\n{\n  "name": "@myorg/web",\n  "dependencies": {\n    "@myorg/utils": "workspace:*",\n    "@myorg/ui": "workspace:*",\n    "react": "^19.0.0"\n  }\n}

workspace:* (pnpm and Yarn) tells the package manager to resolve from the local workspace. npm workspaces use plain "*" and the symlink happens automatically.

Version conflicts on shared external dependencies are where this gets painful. If @myorg/web uses React 19 but @myorg/ui lists React 18 as a peer dependency, you can get two copies of React loaded at once, and the runtime bug after that takes a long time to find. So keep peer dependency ranges aligned, or pin a single version with overrides or resolutions.

What this looks like in a real repo

monorepo/\n├── apps/\n│   ├── web/\n│   │   ├── src/\n│   │   ├── package.json      # depends on @myorg/ui, @myorg/utils\n│   │   └── tsconfig.json     # extends shared config\n│   └── api/\n│       ├── src/\n│       │   ├── routes/\n│       │   └── index.ts\n│       ├── package.json      # depends on @myorg/utils, @myorg/db\n│       └── tsconfig.json\n├── packages/\n│   ├── ui/\n│   │   ├── src/\n│   │   │   ├── Button.tsx\n│   │   │   └── index.ts\n│   │   └── package.json\n│   ├── utils/\n│   │   ├── src/\n│   │   │   ├── format.ts\n│   │   │   └── index.ts\n│   │   └── package.json\n│   ├── db/\n│   │   ├── src/\n│   │   │   ├── client.ts\n│   │   │   └── schema.ts\n│   │   └── package.json\n│   └── config/\n│       ├── tsconfig.base.json\n│       ├── eslint.config.mjs\n│       └── package.json\n├── pnpm-workspace.yaml\n├── turbo.json\n├── package.json\n└── .github/\n    └── workflows/\n        └── ci.yml

CI: only build what changed

Instead of running every test suite on every commit, filter down to the packages which actually changed:

# .github/workflows/ci.yml\nname: CI\non:\n  pull_request:\n    branches: [main]\n\njobs:\n  build-and-test:\n    runs-on: ubuntu-latest\n    steps:\n      - uses: actions/checkout@v4\n        with:\n          fetch-depth: 0  # needed for change detection\n\n      - uses: pnpm/action-setup@v4\n\n      - uses: actions/setup-node@v4\n        with:\n          node-version: 22\n          cache: 'pnpm'\n\n      - run: pnpm install --frozen-lockfile\n\n      - run: pnpm turbo build lint test --filter=...[origin/main]

--filter=...[origin/main] tells Turborepo to run tasks only for the packages which changed since origin/main. Together with caching, this is the thing which keeps CI fast as the repo grows.

Features you can skip for now

Few words about features which get a lot of marketing and matter less than the marketing suggests. Remote caching (both Turborepo and Nx offer it) sounds great, but the hit rate is usually lower than you would hope, and local caching already gives you most of the profit. Nx's code generators are handy for scaffolding, except you still maintain the code which they produce by hand, and a template directory plus a short shell script often does the same job. Strict module-boundary enforcement, like Nx's enforce-module-boundaries, is something which teams turn on too early and then spend time fighting. Add it the day when someone actually imports something they shouldn't.

Where problems usually appear

Circular dependencies. Package A depends on B, which depends back on A. TypeScript will sometimes allow this, and then the build breaks with an error which doesn't point to the real cause. Pull the shared code out into a third package.

The catch-all utils package. Everyone is tempted to dump shared code into one @myorg/utils, and it always turns into a mess. So split by domain from the start: @myorg/date-utils, @myorg/validation, and so on.

A dependency graph which is wrong. If your build tasks don't declare their dependencies correctly in turbo.json, you get failures which come and go between runs. So get dependsOn right.

When to skip the monorepo

Monorepo has a cost, so it is not always worth paying. A single project with no shared code gets no profit from a monorepo. Projects on completely different toolchains with nothing in common, say a Go backend and a React frontend, are better to keep apart. And if nobody on the team has time to look after the tooling, well-kept separate repos are better than a monorepo which nobody maintains. A neglected monorepo is worse than no monorepo.

If you do want one, the simplest path:

mkdir my-monorepo && cd my-monorepo\npnpm init\nmkdir -p packages/shared apps/web

So set up the workspace, add a shared package, connect it to an app with workspace:*, and watch a change in the shared package show up in the app. Turborepo, shared configs, and CI filtering come later.

As a conclusion, I would strongly recommend to start with pnpm and Turborepo, keep packages split by domain, and add the heavier features only when you actually need them.

\n","headings",[48,49,50,51,52,53,54,55,56,57,58],{"_59":82,"_61":83,"_63":12},{"_59":80,"_61":81,"_63":12},{"_59":78,"_61":79,"_63":12},{"_59":76,"_61":77,"_63":12},{"_59":74,"_61":75,"_63":12},{"_59":72,"_61":73,"_63":12},{"_59":70,"_61":71,"_63":12},{"_59":68,"_61":69,"_63":12},{"_59":66,"_61":67,"_63":12},{"_59":64,"_61":65,"_63":12},{"_59":60,"_61":62,"_63":12},"id","when-to-skip-the-monorepo","text","When to skip the monorepo","depth","where-problems-usually-appear","Where problems usually appear","features-you-can-skip-for-now","Features you can skip for now","ci-only-build-what-changed","CI: only build what changed","what-this-looks-like-in-a-real-repo","What this looks like in a real repo","wiring-packages-to-each-other","Wiring packages to each other","running-tasks-turborepo-or-nx","Running tasks: Turborepo or Nx","internal-packages-don-t-need-a-build","Internal packages don't need a build","one-tsconfig-to-extend","One tsconfig to extend","pick-the-package-manager-first","Pick the package manager first","what-you-actually-get-out-of-it","What you actually get out of it","title","Monorepos in JavaScript & TypeScript: A Practical Guide","description","How I structure, build, and maintain JavaScript/TypeScript monorepos.","date","2025-11-12","keywords",[98,99,100,101,102,103,104,105],"author","Denys Bashkatov","tags",[28,37,15],"social",true,"monorepo","javascript","typescript","npm workspaces","turborepo","nx","pnpm","package management","pages",[108],{"_40":109,"_84":110},"about","About me"]

Tech Notes

Tech tips and new discoveries

Monorepos in JavaScript & TypeScript: A Practical Guide