en

Workspace setup

Single-project vs monorepo, and how PCPM discovers your projects.

A “workspace” in PCPM is the boundary for a single pcpm.lock. Everything inside one workspace shares a lockfile, a store, and a pcpm.json.

There are two flavours:

  • Single-project — one .csproj or .sln, one lockfile. pcpm init in the project root is enough. No pcpm-workspace.yaml is written.
  • Monorepo — many projects, one lockfile. pcpm-workspace.yaml lives in the repo root and tells PCPM which projects to include.

Single project

The simplest case. You have a .csproj (or a .sln that points at one), and PCPM treats the directory as a one-project workspace.

my-app/
├── my-app.csproj
├── Program.cs
├── pcpm.json                    # created by pcpm init
└── Directory.Packages.props     # created or adopted by pcpm init

Run pcpm init in the project root. Done.

Multi-project solution (no monorepo)

If you have a .sln with several .csproj files, run pcpm init in the solution root. PCPM walks the .sln and treats every project as part of the workspace.

my-solution/
├── my-solution.sln
├── src/
│   ├── Api/Api.csproj
│   └── Worker/Worker.csproj
├── tests/
│   └── Api.Tests/Api.Tests.csproj
├── pcpm.json
└── Directory.Packages.props

All projects share one lockfile and one store. Adding a dependency from pcpm add writes <PackageReference /> to every project by default; use --project src/Api/Api.csproj to target a single one.

Monorepo

A monorepo in PCPM terms is “a repo with several projects, plus a pcpm-workspace.yaml that tells PCPM how to find them.” The YAML file is a project-glob manifest, similar in spirit to pnpm-workspace.yaml.

When do you need one?

You need pcpm-workspace.yaml if both of the following are true:

  1. You have more than one project that should share a lockfile.
  2. Your project layout doesn’t follow the default discovery rules.

Default discovery:

  • The directory tree is walked from the workspace root.
  • Any .csproj or .sln is picked up.
  • The directories bin/, obj/, node_modules/, and .git/ are excluded.

If your layout doesn’t match (e.g. projects are in apps/*/, or you want to exclude a particular subdirectory), write a pcpm-workspace.yaml.

Minimal example

# pcpm-workspace.yaml
packages:
  - "apps/*"
  - "libs/*"
  - "tools/cli/*.csproj"
exclude:
  - "**/*.Tests.csproj"

This tells PCPM to:

  • Look in apps/* and libs/* (one level deep, only directories).
  • Also pick up tools/cli/SomeApp.csproj (the path is explicit).
  • Skip any project that ends in .Tests.csproj.

Validating your workspace

pcpm list --workspace

Lists every project PCPM discovered, plus its package references. If a project is missing, check your globs. If an extra one is showing up, add it to exclude.

What’s in pcpm.json?

pcpm.json is the manifest PCPM writes when you run pcpm init. It’s small and human-friendly:

{
  "version": "1.0",
  "store": {
    "path": null,
    "auto": true
  },
  "feeds": [
    {
      "name": "nuget.org",
      "url": "https://api.nuget.org/v3/index.json"
    }
  ],
  "updateCheck": true,
  "lockfile": {
    "floating": "pin"
  }
}

You almost never need to edit this by hand. See Configuration for the full schema.

Edit this page on GitHub