tsdown workspace mode resolves the suite root config as a build target and aborts the run (0.22.2)

[Bill-H9986]

tsdown workspace mode resolves the suite root config as a build target and aborts the whole run

tsdown version: 0.22.2 (rolldown 1.1.1)
Node: v24.19.0 (also reproduced on v24.18.0)
OS: Linux (docker node:24-bookworm-slim) and Windows 11 — byte-identical failure on both
Package manager: pnpm 11.7.0

Summary

With a root tsdown.config.ts that declares workspace and entry, the workspace run aborts during config
resolution — before any package builds — with:

ERROR  Error: [@scope/root-package] Cannot find entry: ["lib/types/{index,invariant,startup}.js"]
    at resolveEntry (tsdown/dist/options-*.mjs:83:34)
    at async resolveUserConfig (…:740:40)
    at async Promise.all (index 25)
    at resolveConfig (tsdown/dist/build-*.mjs:95:19)

The label is the root package, and the entry is the root config's own entry template — i.e. the suite root
config itself is being resolved as if it were a build target. A repository root is a declaration, not a package with
lib/types/index.js, so this can never succeed.

Minimal reproduction

sh reproduce.sh        # creates ./tsdown-ws-repro, installs tsdown@0.22.2, runs three variants

The generated project is the smallest shape that carries the same structure:

package.json                 { "name": "@repro/root", "private": true, "type": "module" }
pnpm-workspace.yaml          packages/*/*  +  apps/*
tsdown.config.ts             workspace: ['packages/*/*', 'apps/*']
                             entry: ['lib/types/{index,invariant,startup}.js']
packages/util/thing/         @repro/thing — has src/index.ts, and lib/types/index.js is pre-created
apps/web/                    @repro/web-frontend — a Vite-style app with no lib/types entry

Observed

Variant	Result
A — every discovered package has lib/types/index.js	✅ ✔ Build complete for both packages
B — apps/web lacks that entry (the real-world case)	❌ Error: [@repro/web-frontend] Cannot find entry: ["lib/types/{index,invariant,startup}.js"]
C — workspace: { include: ['packages/*/*'] } (exclude the package that lacks entries)	❌ failure moves to the root: [@repro/root] Cannot find entry
D — root config returns [] for the host face	❌ Error: undefined No input files, try "tsdown <your-file>" or create src/index.ts
E — root config returns { entry: '' } (the SKIP_WORKSPACE_BUILD shape used by packages/client/tsdown.client.ts)	❌ No input files (the empty entry fails the filter below, so the default branch runs)

Root cause pointer

dist/build-*.mjs:

95: const configs = (await Promise.all(rootConfigs.map(async (rootConfig) => {
96:   const { configs: workspaceConfigs, deps: workspaceDeps } = await resolveWorkspace(rootConfig, inlineConfig, rootDeps);
98:   const configs = (await Promise.all(workspaceConfigs.filter((config) => !config.workspace || config.entry)
        .map((config) => resolveUserConfig(config, inlineConfig, workspaceDeps)))).flat()…

Line 98's filter keeps a config when !config.workspace || config.entry. The suite root config satisfies
config.entry (it is the template string), so it passes the filter and is handed to resolveUserConfig, which
resolves entry against the root cwd and throws at resolveEntry (line 83). Setting the root entry to an
empty string makes config.entry falsy, so the filter drops it — and the run then fails one branch later with
No input files, because resolveEntry falls back to <cwd>/src/index.ts, which a suite root does not have.

Expected

The suite root config should not be resolved as a build target. Either exclude it explicitly during workspace
expansion, or make the existing "skip this package" convention work for it (client-only packages are skipped today
via a config whose entry is empty — the docs in packages/client/tsdown.client.ts describe the intent as
"Workspace mode replaces an empty config array with the root defaults. A falsey entry instead removes this package
before entry resolution.").

Real-world impact

deepseek-harness (private fork) at tag dsh-v0.1.5-rc.2:

• pnpm run build:lib:host = tsc -b tsconfig.host.json && tsdown --env.DSH_BUILD_FACE host
• tsc -b passes with 0 errors; tsdown --env.DSH_BUILD_FACE host fails exactly as above, leaving 81 packages in
  the bundle closure without lib/ artifacts, so the downstream pnpm deploy cannot materialize the runtime.

Workaround in the fork today: none that we could find from the config surface (seven variants tried, A–E above plus
patching the discovery list and moving the config out of the root). A patch to resolveConfig/line 98 that skips the
root suite config works around it.

[PerryLink]

Short answer: everything you cited that lives in this repo checks out, and I could go one better than "unverified" on the tsdown side — this checkout's node_modules carries tsdown 0.22.2 (the exact version your fork builds with, and what the repo itself pins), so I read the real filter code rather than your transcription. Your reading is correct.

In-repo facts:

• Root config, master: tsdown.config.ts:19-22 — host face: workspace: ['vendor/*', 'packages/*/*', 'apps/cli', 'apps/desktop', 'apps/desktop-host'] with entry: ['lib/types/{index,invariant,startup}.js']; client face sets entry: ''.
• The skip convention, with its intent spelled out: packages/client/tsdown.client.ts:77-81 — "Workspace mode replaces an empty config array with the root defaults. A falsey entry instead removes this package before entry resolution." plus const SKIP_WORKSPACE_BUILD: UserConfig = { entry: '' }.

tsdown 0.22.2, verified in the installed dist (node_modules/tsdown/dist/build-BxT2lm9L.mjs):

• Line 98 is byte-for-byte your quote: const configs = (await Promise.all(workspaceConfigs.filter((config) => !config.workspace || config.entry).map((config) => resolveUserConfig(config, inlineConfig, workspaceDeps)))).flat().filter((config) => !!config);
• resolveWorkspace (lines 48-85) globs your include patterns and then merges each discovered package's config over the root declaration (mergeConfig(normalized, config) at :82) — which is exactly how your root entry template reaches every member. So the filter keeps anything that carries a truthy entry, your root declaration included, and resolveEntry then resolves that template against a cwd that has no lib/types. Your failure chain is consistent with the code I can see; the precise reason variants C/E surface the root label I couldn't reproduce without your repro script, so that part remains your analysis.
• Version note: root package.json:238 pins "tsdown": "^0.22.2", so this isn't a regression you can dodge by pinning; and the repo's own flow runs tsc -b first (package.json:24), so every member here has the lib/types entries by the time tsdown runs — your fork's apps/web-style members are the trigger. (I didn't run the repo's full build — it writes lib/ artifacts into the checkout and I didn't want to dirty it — so "the repo builds green" is my assumption, not something I verified.)

Which workaround fits:

• Your line-98 patch is the only variant that works without touching member configs, and it matches the in-repo convention's intent — the falsey-entry skip removes a config before entry resolution. But per your variant E, that convention cannot rescue the root declaration itself on 0.22.2 (empty entry → falsy → the filter drops it, yet the run still dies one branch later with "No input files"), so the convention only covers member packages. That's worth stating in the tsdown issue: the root declaration needs its own exclusion, which the current filter has no way to express.
• Excluding via workspace: { include: [...] } (your variant C) can't work either — the root declaration is not a discovery target, so include patterns only change which members inherit it, which is why the failure moves instead of disappearing.

If you're willing to share your repro script or the exact patch shape you ended up with, I'd be happy to sanity-check it against this tree.