Host build fails: tsdown workspace cannot find entry lib/types/{index,invariant,startup}.js

[JiangYueYun]

Environment

• Repo: deepseek-ai/deepseek-harness (current master)
• OS: Windows
• pnpm: 11.7.0
• tsdown: 0.22.2

Repro

pnpm run build:lib:host

Expected

Host lib build completes.

Actual

The Host pass fails during tsdown's workspace resolution:

ERROR  Error: [@deepseek-ai/dsh-root] Cannot find entry: ["lib/types/{index,invariant,startup}.js"]
    at resolveEntry (node_modules/.pnpm/tsdown@0.22.2_.../node_modules/tsdown/dist/options-DWGUHu4D.mjs:83:34)
    at async resolveUserConfig (.../options-DWGUHu4D.mjs:740:40)
    at async Promise.all (index 31)

Root cause

The repo root @deepseek-ai/dsh-root is a solution-only aggregate (tsconfig.host.json sets noEmit: true) — it has no lib/types output. But the current workspace array (['vendor/*', 'packages/*/*', 'apps/cli', 'apps/desktop', 'apps/desktop-host']) is applied as tsdown's include glob, so every package.json under those globs enters the workspace. Root config's entry (lib/types/{index,invariant,startup}.js) is then merged (via mergeConfig) into each package; packages that neither declare their own tsdown.config.ts nor own a tsc-emitted lib/types cannot resolve that inherited entry and throw Cannot find entry.

Suggested fix

Replace the hand-written whitelist with tsdown's auto discovery plus a runtime-probed exclude list: probe every package.json (excluding node_modules/dist/test/tmp) and exclude any package that has neither tsdown.config.ts nor lib/types. Restate tsdown's default exclusions alongside the probe, since tsdown replaces them wholesale when exclude is supplied (otherwise glob recurses into node_modules and the build hangs).

Patch attached (git am-able):

0001-fix-build-exclude-unbundleable-packages-from-tsdown-.patch

PTAL whether this direction is acceptable. Happy to iterate.

---

Patch

From b024f4673029e0cba47cd26d727a2a7965b206c4 Mon Sep 17 00:00:00 2001
From: jely <noreply@example.com>
Date: Thu, 10 Sep 2026 10:19:29 +0800
Subject: [PATCH] fix(build): exclude unbundleable packages from tsdown
 workspace

The root @deepseek-ai/dsh-root package is a solution-only aggregate with no
lib/types output, yet the workspace array globbed every package.json and fed
each one an inherited entry of lib/types/{index,invariant,startup}.js, which
packages without a tsdown.config.ts or tsc-emitted lib/types could not resolve,
failing the Host build with "Cannot find entry".

Replace the hand-written workspace whitelist with tsdown's `auto` discovery
plus a runtime-probed exclude list: every package that neither declares its own
tsdown.config.ts nor owns a lib/types input is excluded. tsdown replaces its
default node_modules/dist/test/tmp exclusions wholesale when exclude is
supplied, so those four patterns are restated alongside the probe so glob does
not recurse into node_modules.
---
 tsdown.config.ts | 62 +++++++++++++++++++++++++++++++++++++++++++++---
 1 file changed, 59 insertions(+), 3 deletions(-)

diff --git a/tsdown.config.ts b/tsdown.config.ts
index 2f24d4910e..08c05b2321 100644
--- a/tsdown.config.ts
+++ b/tsdown.config.ts
@@ -1,4 +1,6 @@
 import { defineConfig } from 'tsdown'
+import { existsSync, globSync } from 'node:fs'
+import { dirname, join, resolve, sep } from 'node:path'
 import { typertPlugin } from './packages/typert/generator/lib/types/tsdown-plugin.js'
 
 function isBuildFaceClient(value: unknown): boolean {
@@ -7,6 +9,56 @@ function isBuildFaceClient(value: unknown): boolean {
   throw new Error(`tsdown: --env.DSH_BUILD_FACE must be host or client, received ${String(value)}`)
 }
 
+/**
+ * Locate the repository root by walking up from `start` for the workspace
+ * marker. Neither process.cwd() nor import.meta.url is reliable here: the
+ * config can be evaluated from another directory, and a bundler's loader may
+ * rewrite module URLs. The marker is therefore the source of truth.
+ */
+function findRepositoryRoot(start: string): string {
+  const rootMarker = 'pnpm-workspace.yaml'
+  let current = resolve(start)
+  for (let depth = 0; depth < 64; depth += 1) {
+    if (existsSync(join(current, rootMarker))) return current
+    const parent = dirname(current)
+    if (parent === current) break
+    current = parent
+  }
+  return resolve(start)
+}
+
+/** Whether a package declares a tsdown config or owns tsc-emitted input. */
+function hasBuildInput(directory: string): boolean {
+  return existsSync(join(directory, 'tsdown.config.ts')) || existsSync(join(directory, 'lib', 'types'))
+}
+
+/**
+ * List the workspace `exclude` patterns. tsdown replaces its default
+ * `node_modules`/`dist`/`test`/`tmp` exclusions wholesale when one is supplied,
+ * so they are restated here, followed by every package directory that has no
+ * tsdown build input (no `tsdown.config.ts` and no tsc-emitted `lib/types`),
+ * each emitted as a root-relative `/**` pattern. Every probe is guarded, so an
+ * unreadable tree degrades to just the defaults rather than failing config
+ * loading.
+ */
+function discoverUnbundleablePackages(root: string): string[] {
+  const defaultExcludes = ['**/node_modules/**', '**/dist/**', '**/test?(s)/**', '**/t?(e)mp/**']
+  let manifests: string[]
+  try {
+    manifests = globSync('**/package.json', { cwd: root, exclude: defaultExcludes })
+  } catch {
+    return [...defaultExcludes]
+  }
+  return [
+    ...defaultExcludes,
+    ...manifests
+      .filter(file => file !== 'package.json')
+      .map(file => resolve(root, dirname(file)))
+      .filter(directory => !hasBuildInput(directory))
+      .map(directory => `${directory.slice(root.length + 1).split(sep).join('/')}/**`),
+  ]
+}
+
 /**
  * The ordinary workspace build consumes JavaScript emitted by the Host
  * TypeScript project and runs Typert. The Client pass selects packages that
@@ -15,10 +67,14 @@ function isBuildFaceClient(value: unknown): boolean {
  */
 export default defineConfig(({ env }) => {
   const client = isBuildFaceClient(env?.DSH_BUILD_FACE)
+  const root = findRepositoryRoot(process.cwd())
+  const excludedPatterns = discoverUnbundleablePackages(root)
+
   return {
-    workspace: client
-      ? ['vendor/*', 'packages/*/*', 'apps/cli']
-      : ['vendor/*', 'packages/*/*', 'apps/cli', 'apps/desktop', 'apps/desktop-host'],
+    workspace: {
+      include: 'auto',
+      exclude: excludedPatterns,
+    },
     entry: client ? '' : ['lib/types/{index,invariant,startup}.js'],
     outDir: 'lib',
     format: ['esm'],

[PerryLink]

Confirmed against the current source (0.1.5-rc.1) - your root cause holds, and here are the two exact places it comes from.

1. The failing entry belongs to the root workspace aggregate, not to a package. The repository-root tsdown.config.ts declares

   entry: client ? '' : ['lib/types/{index,invariant,startup}.js']
   

   which is exactly the string in your error, and the error is prefixed [@deepseek-ai/dsh-root].

2. That entry cannot resolve on a fresh checkout, because the root project emits nothing. The root manifest is @deepseek-ai/dsh-root, and tsconfig.host.json sets compilerOptions.noEmit: true; there is no lib/types directory in the tree.

So build:lib:host (tsc -b tsconfig.host.json && tsdown --env.DSH_BUILD_FACE host) runs the Host type build without emitting, then asks tsdown for root entries that step was never going to produce. On a tree where types were emitted earlier by another step, the same command can succeed - which would explain why this is not reported by everyone.

Two things worth settling before a fix:

• whether the root aggregate is only meant to be built through the full build:lib path (host then client). If so, build:lib:host alone is expected to fail and the fix is a guard or a clearer error message rather than a config change;
• or whether the root entry list is simply stale for the host face and should be dropped there.

Disclosure of scope: I verified the configuration and the missing directory statically on 0.1.5-rc.1; I have not run the full build on Windows.

[JiangYueYun]

Thanks — you read the string's origin correctly: that entry is declared by the repository-root
config, and the root project emits nothing. You also flagged that you had not run this on
Windows, so here is that run, the full way I obtained it, and a revised patch in the next
comment.

A correction to my own report

I wrote that a package fails when it neither declares its own tsdown.config.ts nor owns a
tsc-emitted lib/types.

• That class does exist, and it does fail — reporting its own package name.
• It is not what failed here: the label in this report is [@deepseek-ai/dsh-root].
• My patch does not fix that class either; it still fails under its own name.

What failed here is a different class: a directory matched by the include globs that has no
package.json at all. With no manifest of its own, tsdown takes the config name from the
repository manifest, which is where the [@deepseek-ai/dsh-root] label comes from.

Relationship to my first comment and patch

The environment, repro and expected/actual sections of my first comment still stand, and the
error string still comes from this config. Two things change: which member actually fails, and
the patch itself — v2 shares no code with v1, so nothing below should be read as a variation of
the first diff. Please ignore the attachment in my first comment.

v1	v2
findRepositoryRoot() walking up to pnpm-workspace.yaml	dropped: the include patterns are relative to the working directory, as upstream already assumed
hasBuildInput() — tsdown.config.ts or lib/types	dropped: membership no longer depends on build state
discoverUnbundleablePackages() — glob every **/package.json, exclude the ones without a build input	replaced by directoriesWithoutManifest() — probes only the directories the include patterns match, and only for a package.json
workspace: { include: 'auto', exclude }	workspace: { include: includeArray, exclude: excludeArray } — the explicit globs stay
restating tsdown's default node_modules/dist/test/tmp exclusions once exclude is supplied	kept, for the same reason as v1 (defaultWorkspaceExcludes)
the root-cause paragraph of my first comment	corrected: the failing member is a directory with no package.json; the manifest-bearing-but-unbuildable class exists, but it is not what failed here

How this was verified

Environment: Windows 11 Pro (26200), Node v24.16.0, pnpm 11.7.0, TypeScript 6.0.3, tsdown
0.22.2. I used a fresh clone of current master, c291e7961a (your static check was on
0.1.5-rc.1), with pnpm install --frozen-lockfile. Every step below uses the tree's own config
unless a step says otherwise.

By "complete build" I mean pnpm run build: the node-gyp addon (build:native-system), the
Host and Client libs (build:lib), and the web build (build:web). It took 131 seconds on the
untouched tree and 134 seconds with the patch.

0. Clone cleanliness. The clone contains no manifest-less directory. That is not luck: a
   git clone copies only tracked content, and the stale directories in my working tree were
   untracked (git ls-files reports zero tracked files in each of them). I assert it before
   building — git status --porcelain is empty, and no directory under packages/*/* lacks a
   package.json.
1. Patch. git apply; I asserted the patched file is the revision I reviewed (sha256),
   ends with a single LF, and leaves git diff --check clean.
2. Regression. pnpm run clean, then create one empty directory that the include globs
   match (packages/experimental/zzz-ghost-probe/), confirm it is there, then pnpm run build
   → exit 0, no Cannot find entry anywhere in the output, and the directory never appears in
   it. Bundled artifacts: 424 files, identical to the untouched baseline in step 5.
3. Control. git checkout -- tsdown.config.ts (untouched config), same empty directory,
   pnpm exec tsdown --env.DSH_BUILD_FACE host → exit 1 with the reported error.
4. Label contrast. In that same directory, add a package.json with only a name and no
   build input, and run the same command → exit 1, different label.
5. Untouched baseline. pnpm run clean && pnpm run build with the upstream config → exit 0,
   424 bundled artifacts, and the repository root has no lib/types before or after. This is
   the run the 131 seconds and the artifact comparison above refer to.
6. Gates. With the patch applied and the empty directory still present:
   pnpm run typecheck → 0; pnpm run lint → 0, no findings; pnpm run hygiene → see the
   scope note.

Two notes on method, so this is reproducible:

• I ran the patched legs first and re-ran the untouched baseline afterwards in the same clone,
  because my first baseline attempt still had the patch applied and produced no usable
  comparison. The two artifact lists were compared only once both existed.
• The directory has to be created after pnpm run clean, because clean deletes package
  directories whose remaining entries are all known residue. My first attempt created it before
  clean; it was removed and the comparison was meaningless.

Q1: is build:lib:host only meant to run through the full build:lib path?

No. On a clean clone at this commit it succeeds on its own — untouched config, after
pnpm install --frozen-lockfile:

PS> pnpm run clean; pnpm run build:lib:host
exit 0                                                  # 249 packages report "Build complete"
PS> Test-Path lib\types                                 # False — the repository root never emits
PS> Test-Path packages\core\agent\lib\types\index.js    # True  — the Host tsc pass emits per package

The root never emitting is not a problem: the Host tsc pass writes lib/types inside each
package before tsdown runs, and each member resolves the inherited entry there.

Nor is this specific to that command. With manifest-less directories present, the documented
full build fails identically, before it reaches the Client or web stages:

PS> pnpm run build                                      # native addon, Host+Client libs, web
ERROR  Error: [@deepseek-ai/dsh-root] Cannot find entry: ["lib/types/{index,invariant,startup}.js"]
exit 1                                                  # 18 s; build runs no clean, so the directories stay

build:lib:host is also a required step rather than an optional fragment: typecheck, lint,
lint:fix and doc-typecheck all begin with it (package.json lines 45/47/49/93), and CI runs
pnpm run typecheck directly (ci-master.yml:384). Treating it as expected to fail would leave
those checks broken, so this needs a fix rather than a guard or a clearer message.

Q2: is the root entry list stale for the host face?

No. The repository root is never a workspace member, and that entry is the only entry
every member receives. resolveWorkspace drops the repository-root manifest (its auto branch
filters file !== "package.json"), and the include globs never match the repository root. The
entry is declared once here and inherited by every member through
mergeConfig(normalized, config), then resolved against that member's own tsc-emitted
lib/types — which is why the build above succeeds with no root lib/types. Dropping it would
leave the Host pass with no entries.

What actually fails: a directory without a package.json

$ mkdir packages/experimental/zzz-ghost-probe        # empty, no manifest
$ pnpm exec tsdown --env.DSH_BUILD_FACE host         # untouched config
ERROR  Error: [@deepseek-ai/dsh-root] Cannot find entry: ["lib/types/{index,invariant,startup}.js"]         # exit 1

$ echo '{"name":"@deepseek-ai/dsh-ghost-probe","version":"0.0.0","private":true}' > packages/experimental/zzz-ghost-probe/package.json
$ pnpm exec tsdown --env.DSH_BUILD_FACE host
ERROR  Error: [@deepseek-ai/dsh-ghost-probe] Cannot find entry: ["lib/types/{index,invariant,startup}.js"]  # exit 1

The label follows the nearest manifest: readPackageJson(cwd) walks up to the repository
manifest when the directory has none of its own. So [@deepseek-ai/dsh-root] means the failing
member has no package.json, and removing the directory restores the build.

Why this is not about earlier type emission

Both runs below used the same clone:

# never built before: fresh clone, no lib/types anywhere in the tree
$ pnpm run clean && pnpm run build                              # exit 0

# fully built tree, then one manifest-less directory in the include set
$ pnpm exec tsdown --env.DSH_BUILD_FACE host                    # exit 1
ERROR  Error: [@deepseek-ai/dsh-root] Cannot find entry: ["lib/types/{index,invariant,startup}.js"]

So what decides success here is not whether types were emitted earlier; it is whether the
include globs match a directory that is not a package.

The 12 directories on my machine

My checkout had 12 of them under packages/*/*: untracked, zero tracked files, left over from
package renames (web-react, schema-form, code-runtime-python, session-persistence-sqlite,
host/apiproxy, …). They were the only directories in the include set without a manifest, so one
of them was the failing member on my machine. I have deleted them; the reproduction above uses a
synthetic one. Git does not delete a directory it cannot remove, and on Windows a locked directory
commonly survives a checkout, which is my best explanation for why they were still there — I did
not verify that mechanism.

Why v2 looks like this

v1 switched to workspace: 'auto' plus a runtime probe. I dropped both:

• auto also admits apps/web (which still has no lib/types after build:lib:host),
  benchmarks, website, native/ and python/, so keeping the bundled set unchanged would
  require a second exclusion list.
• The probe decided membership from whether lib/types existed, which makes the workspace depend
  on whether a build had already emitted.

v2 keeps the explicit globs and excludes the directories those globs match that own no
package.json: a directory has to be a package to join the workspace. workspace: true stays
rejected, consistent with the earlier ruling in 822a0c4 ("fix(build): exclude Vite app from
package bundling").

v2 does not cover the manifest-bearing-but-unbuildable class. Within this repository's current
include set that class does not exist today: I enumerated packages/*/*, vendor/* and
apps/{cli,desktop,desktop-host}, and every directory that has a manifest either declares its
own tsdown.config.ts or receives lib/types from tsc -b tsconfig.host.json — not one is
missing both. (apps/web still has no lib/types after build:lib:host, but the include
patterns do not match it.) Protecting that class belongs with the follow-up at the end: fail
loudly on "discovered but unbundleable" instead of excluding it silently.

The complete diff (nothing here comes from my first patch; the git am-able file follows in the
next comment):

@@ -1,4 +1,6 @@
 import { defineConfig } from 'tsdown'
+import { existsSync, globSync } from 'node:fs'
+import { join, sep } from 'node:path'
 import { typertPlugin } from './packages/typert/generator/lib/types/tsdown-plugin.js'
 
 function isBuildFaceClient(value: unknown): boolean {
@@ -7,6 +9,24 @@ function isBuildFaceClient(value: unknown): boolean {
   throw new Error(`tsdown: --env.DSH_BUILD_FACE must be host or client, received ${String(value)}`)
 }
 
+/** tsdown's documented workspace exclusions; supplying `exclude` replaces all of them. */
+const defaultWorkspaceExcludes = ['**/node_modules/**', '**/dist/**', '**/test?(s)/**', '**/t?(e)mp/**']
+
+/**
+ * The directories the include globs match that own no package.json. tsdown globs
+ * an include array with `onlyDirectories`, so a directory left behind by a
+ * renamed package becomes a workspace package, inherits this config's `entry`,
+ * and fails the whole pass with `Cannot find entry` named after this config.
+ *
+ * @param patterns - Workspace include patterns.
+ * @returns Root-relative `/**` exclusions for those directories.
+ */
+function directoriesWithoutManifest(patterns: readonly string[]): string[] {
+  return globSync(patterns, { withFileTypes: true })
+    .filter(entry => entry.isDirectory() && !existsSync(join(entry.parentPath, entry.name, 'package.json')))
+    .map(entry => `${join(entry.parentPath, entry.name).split(sep).join('/')}/**`)
+}
+
 /**
  * The ordinary workspace build consumes JavaScript emitted by the Host
  * TypeScript project and runs Typert. The Client pass selects packages that
@@ -15,10 +35,18 @@ function isBuildFaceClient(value: unknown): boolean {
  */
 export default defineConfig(({ env }) => {
   const client = isBuildFaceClient(env?.DSH_BUILD_FACE)
+  // Explicit globs keep bundling to vendored Cordis, the TypeScript package tree and the
+  // Node assemblies; `workspace: true` would also admit apps/web, benchmarks, website,
+  // native/ and python/, which ship through other builds.
+  const includeArray = client
+    ? ['vendor/*', 'packages/*/*', 'apps/cli']
+    : ['vendor/*', 'packages/*/*', 'apps/cli', 'apps/desktop', 'apps/desktop-host']
+  const excludeArray = [...defaultWorkspaceExcludes, ...directoriesWithoutManifest(includeArray)]
   return {
-    workspace: client
-      ? ['vendor/*', 'packages/*/*', 'apps/cli']
-      : ['vendor/*', 'packages/*/*', 'apps/cli', 'apps/desktop', 'apps/desktop-host'],
+    workspace: {
+      include: includeArray,
+      exclude: excludeArray,
+    },
     entry: client ? '' : ['lib/types/{index,invariant,startup}.js'],
     outDir: 'lib',
     format: ['esm'],

The repository already has a check for this

pnpm run constraints reports packages/experimental/zzz-ghost-probe: expected a package here (no package.json found), and it is one of check:ci's static gates (run-gates.ts:302). It
just does not run on the build:lib:host path that developers, typecheck and lint use, which
is why tsdown's error is what people meet first.

pnpm run clean deletes such a directory only when every remaining entry is known residue. With
unknown entries — a leftover holding empty src/ and tests/, the shape three of my twelve had —
it refuses and fails:

$ pnpm run clean
clean: refusing to remove package directories without package.json; unknown entries remain:
  packages/experimental/zzz-ghost-files/src
  packages/experimental/zzz-ghost-files/tests
exit 1

So "just run clean" does not always help, and it deletes nothing at all in that case.

Scope and caveats

Verified on Windows only: pnpm run build, typecheck, lint, and the stale-directory
experiments above. Not verified: the Linux CI lanes, test:coverage or doc-sync.

pnpm run hygiene is not green in my environment for two reasons unrelated to this diff:
constraints fails only while the synthetic directory is in the tree (that is the guard above;
it passes once the directory is removed), and verify-cordis-config fails on the untouched tree
as well (apps/cli/tests/profiles/acp/cordis.yml: root must be a Loader entry array), which I
have not investigated.

Upstream

rolldown/tsdown#1067 describes the same mechanism; #1068 appends the resolved cwd to the
message, which helps diagnosis but not behaviour.

PTAL.

[JiangYueYun]

One thing to make explicit: this repository consumes tsdown from npm ("tsdown": "^0.22.2", run as
node_modules/.bin/tsdown inside pnpm run build); the root tsdown.config.ts only feeds it the
include patterns. The defect is in tsdown's own workspace resolution, so it cannot be fixed from here
except by the config patch above.

The same fix belongs in tsdown itself — src/config/workspace.ts in rolldown/tsdown, the file
compiled into the dist code we run. It skips the include-matched directories that own no
package.json, and says so instead of passing over them quietly:

WARN  workspace include matched 2 directories without a package.json; skipping: packages/experimental/a, packages/experimental/b

   } else {
-    packages = (
+    const matched = (
       await glob(packages, {
         ignore: exclude,
         cwd: rootCwd,
         onlyDirectories: true,
         absolute: true,
         expandDirectories: false,
       })
     ).map((file) => slash(path.resolve(file)))
+
+    const skipped: string[] = []
+    packages = []
+    for (const directory of matched) {
+      if (await fsExists(path.join(directory, 'package.json'))) {
+        packages.push(directory)
+      } else {
+        skipped.push(slash(path.relative(rootCwd, directory)))
+      }
+    }
+    if (skipped.length > 0) {
+      globalLogger.warn(
+        `workspace include matched ${skipped.length} director${skipped.length === 1 ? 'y' : 'ies'} without a package.json; skipping: ${skipped.toSorted().join(', ')}`,
+      )
+    }
   }

It needs fsExists from ../utils/fs.ts and globalLogger from ../utils/logger.ts. With it,
tsdown's two discovery branches agree, and a directory that is not a package is reported rather than
silently dropped.

It reaches this repository once upstream releases it and tsdown is bumped; until then the config
patch above stays. Checked in tsdown's own suite: the new case in tests/e2e.test.ts fails without
the change and passes with it, and eslint --max-warnings 0 plus tsc --noEmit are clean.

[JiangYueYun]

Upstream fix is now proposed: rolldown/tsdown#1069 — fix(workspace): skip include-matched directories without a package.json.

workspace.include is expanded with onlyDirectories: true, so a matched directory that owns no package.json becomes a workspace entry, inherits this config's entry and name, and then fails entry resolution under the root's name. The PR keeps only the directories that own a manifest — as include: 'auto' already does — and reports the rest instead of passing over them quietly:

WARN  workspace include matched 2 directories without a package.json; skipping:
  - packages/experimental/a
  - packages/experimental/b

Evidence: in tsdown's own suite the case added in tests/e2e.test.ts fails on main and passes with the change, with eslint --max-warnings 0 and tsc --noEmit clean; against this repository, with tsdown.config.ts unmodified and two manifest-less directories under packages/*/*, the patched tsdown builds 249 packages and prints that warning, while the installed tsdown@0.22.2 still fails with [@deepseek-ai/dsh-root] Cannot find entry: ["lib/types/{index,invariant,startup}.js"].

Version boundary: this repository pins tsdown@^0.22.2, and the change targets tsdown's main (the patched file is identical in v0.23.0), so it lands here once a release carrying it is inside our range. Until then the config workaround in the first comment stays, and it is removed with the dependency bump.