chore: migrate from tsup to tsdown

[jan-kubica]

Summary

• Replace tsup with tsdown (its successor) for the build step
• tsdown handles .d.ts generation natively, so the separate tsc -p tsconfig.build.json step is no longer needed
• Adds sourcemap output

Changes

• tsup.config.ts renamed to tsdown.config.ts, updated imports and options
• Build script simplified from tsup && tsc -p tsconfig.build.json to tsdown
• devDependencies: tsup replaced with tsdown

---

[greptile-apps]

Greptile Summary

This PR migrates the build toolchain from tsup to its successor tsdown, simplifying the build script by eliminating the separate tsc -p tsconfig.build.json declaration-generation step and adding sourcemap output. The change is straightforward but introduces one significant issue.

Key findings:

• bun-types may pollute published declaration files — The deleted tsconfig.build.json contained "types": [], which explicitly prevented Bun's global ambient type declarations from leaking into the generated .d.ts files. The root tsconfig.json declares "types": ["bun-types"], so tsdown's dts: true will now run with Bun types active. Any source symbol that references a Bun-augmented global (even through inference) will produce a declaration that is unresolvable for consumers without bun-types installed. A tsconfig option pointing to a build-specific tsconfig, or inline dts.compilerOptions: { types: [] }, is needed to restore the previous isolation.
• The bundle: false option carried over from the tsup config — note that the previous review thread already flagged that tsdown's canonical equivalent is unbundle: true per the official migration guide; this PR does not yet address that.
• sourcemap: true is a clean additive improvement.

Confidence Score: 2/5

• Not safe to merge — the removal of tsconfig.build.json's "types": [] guard risks leaking bun-types global augmentations into published declaration files, and the unbundle: true issue flagged in a previous review round remains unaddressed.
• Two compounding issues exist: (1) the bun-types type-pollution risk introduced by deleting tsconfig.build.json without compensating in the tsdown dts config, and (2) the still-unresolved bundle: false vs unbundle: true semantic mismatch that was already flagged. Either issue alone could cause the published package to be broken or unusable for consumers.
• tsdown.config.ts requires the most attention — it needs both unbundle: true and a dts tsconfig that excludes bun-types.

Important Files Changed

Filename	Overview
tsdown.config.ts	Migrates build config from tsup to tsdown: adds dts: true (replacing the deleted tsconfig.build.json step) and sourcemap: true. However, deleting tsconfig.build.json removes the "types": [] guard that prevented bun-types from leaking into published declaration files. The bundle: false option is also carried over but in tsdown the correct unbundle-mode option is unbundle: true.
package.json	Build script simplified from tsup && tsc -p tsconfig.build.json to tsdown; dev dependency swapped from tsup to tsdown@^0.12.4. Change is correct and self-consistent.
tsconfig.build.json	Deleted as part of migration — its declaration: true / emitDeclarationOnly: true role is now handled by tsdown's dts: true. The critical "types": [] compiler option it contained, which prevented bun-types from polluting published declarations, is not replicated anywhere in the new setup.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[bun run build] --> B[tsdown]
    B --> C[collectEntries src]
    C --> D[All .ts files excluding .test.]
    D --> E{bundle: false\nshould be unbundle: true}
    E -->|Bundled - WRONG| F[Single bundle output\nbreaks exports map]
    E -->|Unbundled - CORRECT| G[Per-file .js output in dist/]
    G --> H{dts: true uses root tsconfig.json}
    H -->|bun-types active - RISK| I[.d.ts files with bun-types leak]
    H -->|types empty - NEEDED| J[Clean .d.ts files safe for consumers]
    G --> K[sourcemap: true generates .js.map files]

Loading

_{Reviews (2): Last reviewed commit: "fix: restore bundle: false and simplify ..." | Re-trigger Greptile}

[devin-ai-integration]

Devin Review found 3 potential issues.

View 2 additional findings in Devin Review.

[devin-ai-integration]

🔴 bun.lock not updated after replacing tsup with tsdown

The package.json replaces the tsup devDependency with tsdown, but the bun.lock file was not regenerated and still references tsup (no tsdown entry exists). CI runs bun install --frozen-lockfile (ci.yml:56, ci.yml:68), which will fail because the lockfile is out of sync with package.json. This also means tsdown is never installed, so bun run build (which now invokes tsdown) will fail at both CI and publish time.

Prompt for agents

Run `bun install` (or `bun add -d tsdown` and `bun remove tsup`) to regenerate the bun.lock file so it reflects the dependency change from tsup to tsdown. The updated bun.lock must be committed alongside package.json.

---

Was this helpful? React with 👍 or 👎 to provide feedback.

[devin-ai-integration]

🚩 sourcemap: true is a new addition that increases package size

The old config had bundle: false but no sourcemap generation. The new config adds sourcemap: true, which will create .js.map files in dist/. These files will be included in the npm package (no .npmignore or files field excludes them). For a library with 200+ entry points, this could noticeably increase the package tarball size. This may be intentional, but is worth considering.

---

Was this helpful? React with 👍 or 👎 to provide feedback.

[greptile-apps]

bun-types may leak into published declaration files

The deleted tsconfig.build.json explicitly set "types": [] to prevent Bun-specific ambient type declarations from being included in the generated .d.ts files. With that file gone, tsdown's dts: true will use the root tsconfig.json by default, which declares "types": ["bun-types"].

bun-types adds global augmentations (e.g., Bun.*, modified console, fetch overloads, etc.). If any source file references these globals — even indirectly through return-type inference — those references will end up in the published .d.ts files. Consumers who don't have bun-types installed will then encounter type errors.

The tsdown CLI exposes a --tsconfig flag (and a tsconfig config option) for exactly this purpose. To preserve the previous isolation, you can either supply a dedicated build tsconfig or specify the compiler options inline:

export default defineConfig({
  entry: collectEntries("src"),
  format: ["esm"],
  bundle: false,
  dts: {
    compilerOptions: {
      types: [],
    },
  },
  clean: true,
  target: "es2022",
  outDir: "dist",
  sourcemap: true,
});

Alternatively, keep a minimal tsconfig.build.json and reference it via tsconfig: "tsconfig.build.json" in the config.