feat(appkit): ship pnpm-patched dependencies inside published tarballs

[MarioCadenas]

What

Ship pnpm-patched dependencies inside the published @databricks/appkit / @databricks/appkit-ui tarballs, so apps that install appkit get the patched code.

A pnpm patch (patchedDependencies in pnpm-workspace.yaml) is applied only at this monorepo's install. It doesn't travel through a consumer's npm install / pnpm install, so without this an app built on a published appkit resolves the unpatched registry copy.

How

• tools/bundle-patched-deps.ts plans, per tarball, which patched packages the package uses. It reads patchedDependencies and walks the real installed dependency tree: the package's own deps plus the CLI deps merged in from shared, directly or transitively.
• tools/dist-appkit.ts copies those patched packages into the tarball's node_modules and lists them in bundledDependencies. Each bundled package's own dependencies are added to the tarball's dependencies at their installed versions. Package managers don't install those for a bundled package, and under pnpm a bundled package can only resolve what its parent declares.
• The build fails instead of quietly shipping an unpatched copy when:
  • a patch entry is stale (the version in use doesn't match the patch);
  • the patch wasn't applied;
  • a bundled package needs a different dependency version than the tarball declares.
• CI (PR Template Artifact) runs tools/verify-bundled-patches.ts after building the tarballs. It installs each tarball with npm and with pnpm and checks every bundled package resolves to the patched copy.

Adding a patch stays a pnpm-only step (pnpm patch / pnpm patch-commit). The release build picks it up automatically.

Impact

main defines no patches today, so nothing is bundled and the published tarballs are unchanged. The first user is the Reyden attachment patch for @databricks/sdk-statementexecution in #562, which will be rebased onto this PR.

Testing

• tools/bundle-patched-deps.test.ts: 8 tests on pnpm-shaped fixture trees (direct, transitive, unused, stale entry, unapplied patch, dependency conflict, key parsing, config reading). Tools suite: 70/70.
• Locally on this branch: pnpm pack:prerelease and the verify step pass, and nothing is bundled.
• On feat(appkit): migrate analytics to the modular @databricks/sdk-* #562's build (with the statementexecution patch): npm and pnpm consumer installs resolve the patched copy. A deployed Databricks App (Apps runtime, pnpm 11) served Reyden INLINE + ARROW_STREAM straight from the bundled patched attachment, with no EXTERNAL_LINKS fallback.

This pull request and its description were written by Isaac.

[github-actions]

🤖 AppKit PR bot

🔬 Run evals

Start an eval for this PR from the evals-monitor app: Go to Evals Monitor →

📦 Try this PR's app template

Scaffolds a new app from this PR's SDK build. Run it in any folder (requires the GitHub CLI — gh auth login — and the Databricks CLI):

gh run download 38918747210 -R databricks/appkit -n appkit-template-0.88.1-pr.d36c042-fix-bundle-patched-deps-635 -D appkit-pr-635 \
  && unzip -o "appkit-pr-635/appkit-template-0.88.1-pr.d36c042-fix-bundle-patched-deps-635.zip" -d "appkit-pr-635" \
  && databricks apps init --template "appkit-pr-635"

The template pins @databricks/appkit and @databricks/appkit-ui to tarballs built from this branch, so the scaffolded app runs against this PR's code.

[calvarjorge]

Comments from the agent:

npm apps crash on startup once a patched dependency ships in the tarball (e.g. #562's). If the app has a different version of one of that dependency's own dependencies, npm leaves appkit's copy of it as an empty folder, so import('@databricks/appkit') fails.

Repro: #562's tarball in an npm app with "zod": "4.1.13" (the template pin from March to May) gives ERR_MODULE_NOT_FOUND …/appkit/node_modules/zod/index.js. With 4.3.6 it works. pnpm is fine. CI misses it because the verify step installs into an empty app.