Skip to content
Fran Gonzalez
← Back to blog
(updated Jun 27, 2026)·Clanker·3 min read

Dagger's TypeScript SDK doesn't understand pnpm catalog:

Dagger modules install in isolation with a generated pnpm-workspace.yml that has no catalog. The project root's workspace file is never read.

Today I Learned#dagger#pnpm#ci
Some matmuls wrote this slop, sorry. My goal with this content is to document some work I (a real human bean) do while poking the Clanker, and try to learn something along the way.

Dagger’s TypeScript SDK installs module dependencies with yarn by default. Switching to pnpm via packageManager still fails for catalog: references, because Dagger generates its own pnpm-workspace.yml that never includes the project’s catalog definitions.

What I Learned

I added a Dagger module’s ci/package.json to the pnpm workspace and switched its TypeScript pin from "^5.3.2" to "catalog:". The workspace’s pnpm-workspace.yaml defined the catalog:

# pnpm-workspace.yaml (at repo root)
catalog:
  typescript: "6.0.3"

pnpm install resolved it locally. Dagger’s CI run in GitHub Actions failed:

error Couldn't find any versions for "typescript" that matches "catalog:"

Why it fails

Two layers of isolation combine to break the catalog protocol.

First, Dagger’s module runtime copies the module directory into a container and never includes the workspace root. The project’s pnpm-workspace.yaml is absent from the container.

Second, even when packageManager is set to pnpm, the Dagger TypeScript SDK generates its own pnpm-workspace.yml inside the module root:

packages:
  - "./sdk"

This generated file exists solely to resolve @dagger.io/dagger as a local vendored dependency. It has no catalog definitions, no overrides, none of the project’s workspace settings. The module’s package.json is evaluated against this generated workspace, not the project workspace. You can add files to the module context with dagger.json’s include field, but the generated workspace takes precedence over any project workspace file you include.

So "catalog:" is unresolvable regardless of which package manager Dagger uses. The catalog protocol is a pnpm workspace feature, and the workspace that Dagger provides to the module is not the project’s workspace.

The fix

Two changes to ci/package.json. Use a literal version instead of catalog:, and switch Dagger from its default yarn to pnpm so the version string is unambiguous:

// ci/package.json
{
  "packageManager": "pnpm@11.7.0",
  "dependencies": {
    "typescript": "6.0.3",
  },
}

The packageManager field tells Dagger’s TypeScript SDK to use pnpm. The literal 6.0.3 stays in sync with the catalog value by hand. The module stays out of the pnpm workspace packages: list; Dagger modules are not workspace members.

This is a known limitation, not a permanent design choice

The vendored SDK is an implementation detail being actively reworked. A GitHub discussion from another user with the same pnpm monorepo setup confirms the Dagger team described the current approach as a “quick solution.” They are working on decoupling the SDK client bindings from the client library so the library can live as a regular npm dependency (#8688, #9538). Once that lands, a Dagger module’s package.json could participate in the project workspace like any other package, and catalog: might become resolvable.

References

This post was written with AI assistance.