Why MonoRepo with pnpm Boosts Frontend Efficiency and Simplifies Dependency Management

MonoRepo Application

Before discussing the project structure, it is important to understand two concepts: MultiRepo and MonoRepo.

MultiRepo is a distributed code management approach that splits a project into separate repositories based on functionality or other dimensions.

MonoRepo stores multiple projects in a single repository.

In the "boss‑circle" project, the front‑end code consists of an H5 user layer and a Node BFF layer, originally maintained in two separate repositories. This caused developers to start and stop two projects during debugging, and required two separate release processes, which reduced efficiency.

Switching to a MonoRepo solved these issues by allowing shared dependencies and configurations such as typescript, eslint, and githook. The new structure looks like:

packages
└─ boss-circle-client
└─ boss-circle-server
└─ jsbridge-hook
└─ code-gen
pnpm-workspace.yaml

Besides the two business projects, the repository also contains two npm packages: code-gen (a CLI template generator) and jsbridge-hook (a bridge library used heavily in the client).

MonoRepo itself does not manage dependencies, but when combined with pnpm's workspace feature it provides effective dependency and version control during both development and release phases. The team chose pnpm workspaces over heavier tools like Lerna or Turbo.

pnpm

Package managers have evolved from npm to yarn and now pnpm. Early npm versions stored all dependencies in nested node_modules folders, leading to deep paths, duplicated packages, and inability to share module instances.

Flattened dependency strategies introduced in npm3 and yarn reduced duplication but still suffered from multiple versions and ghost dependencies.

pnpm Introduction

pnpm offers three main advantages:

Highly efficient disk‑space usage.

Very fast installation speed.

No ghost‑dependency problems.

It achieves this through hard links and symbolic links. Packages are stored once in a global .pnpm-store and linked into each project, avoiding repeated copies. Different versions share unchanged files via hard links, writing only new or changed files.

Only directly installed dependencies appear in node_modules as symbolic links to the store, preventing indirect (ghost) dependencies from being unintentionally available.

Hard links connect the store files to the project, while symbolic links expose only the explicitly declared packages, eliminating ghost dependencies and saving disk space.

node_modules
├── foo -> ./.pnpm/[email protected]/node_modules/foo
└── .pnpm
    ├── [email protected]
    │   └── node_modules
    │       └── bar -> <store>/bar
    └── [email protected]
        └── node_modules
            ├── foo -> <store>/foo
            └── bar -> ../../[email protected]/node_modules/bar

Summary

pnpm combines symbolic links and hard links with an incremental update strategy to eliminate ghost dependencies, achieve high disk‑space efficiency, and provide fast installations. For a simple MonoRepo setup, using pnpm's workspace feature enables straightforward multi‑package dependency and version management, which can be extended with custom release scripts to complete the project workflow.