How to Update Apache Superset Dependencies in the Superset-sh Bun Monorepo

Run bun add <package>@latest -w from the repository root to upgrade a specific dependency, then execute bun install to regenerate the monorepo lockfile, and validate the changes with bun run typecheck && bun run test to ensure workspace integrity.

The superset-sh/superset repository is a Bun-powered Turborepo that manages multiple independent packages—including ui, api, and desktop—across a unified workspace. To update Apache Superset dependencies safely, you must coordinate version bumps across individual package.json files, regenerate the central bun.lock file, and execute the repository-wide validation pipeline. This workflow ensures that dependency updates in one workspace do not introduce type errors or test failures in dependent packages.

Understanding the Monorepo Structure

The Superset-sh repository organizes code into distinct workspaces defined in the root package.json. The workspaces array declares three glob patterns: packages/*, apps/*, and tooling/*. Each matching directory contains its own package.json with independent dependency trees.

For example, the UI package resides at packages/ui/package.json and declares its own runtime and development dependencies. When you update Apache Superset dependencies, you are modifying these individual workspace manifests while the root bun.lock file maintains the resolved graph for the entire repository.

Updating Dependencies in Superset-sh

Upgrading a Single Dependency

To bump a specific package to its latest version across the monorepo, use the bun add command with the -w flag from the repository root. The -w flag instructs Bun to treat the operation in a workspace context, ensuring the root lockfile updates correctly.

bun add react@latest -w

Alternatively, navigate to the specific workspace directory and run the command without the flag:

cd packages/ui
bun add react@latest

Both methods update the target workspace's package.json, but running from the root with -w is the recommended approach for consistency.

Bulk Upgrading Workspace Dependencies

To upgrade every dependency within a specific workspace to its latest compatible version according to the declared semver ranges, use the bun upgrade command inside the workspace directory.

cd packages/ui
bun upgrade

This command respects the ^ and ~ prefixes in your package.json and fetches the newest versions that satisfy those constraints. It is useful for routine maintenance of a single package without affecting the entire monorepo.

Regenerating the Lockfile

After modifying any workspace dependencies, you must regenerate the central lockfile to synchronize the entire dependency graph. Execute bun install strictly from the repository root to ensure Bun updates the bun.lock file for all workspaces simultaneously.

bun install

Running this command from a subdirectory would create a separate lockfile for that workspace alone, breaking the monorepo's dependency resolution. The root package.json defines the workspace boundaries, and bun install uses these globs to construct the unified bun.lock.

Validating Dependency Updates

Type Checking Across Workspaces

Dependency updates can introduce breaking TypeScript changes. Run the Turborepo type-checking pipeline to verify that all workspaces still compile correctly.

bun run typecheck

This command executes turbo typecheck across every package defined in turbo.jsonc. If a dependency upgrade altered type definitions or removed deprecated APIs, this step will surface the errors before they reach production.

Linting and Code Quality

Ensure code style consistency and catch potential issues introduced by new dependency versions by running the linting pipeline.

bun run lint

This command invokes the shell script at scripts/lint.sh, which typically runs Biome or ESLint across the repository. Follow this with the formatting command to auto-fix any style violations:

bun run format

Running the Test Suite

Execute the full test suite to confirm that dependency updates did not break runtime behavior.

bun run test

This triggers turbo test as defined in the root package.json scripts. The CI pipeline defined in .github/workflows/ci.yml runs these exact commands, so passing them locally ensures your changes will pass remote checks. If tests fail, revert the specific dependency bump or adjust the calling code to match the new API.

Key Files in the Dependency Workflow

Understanding these specific files helps you navigate the Superset-sh codebase when updating dependencies:

• package.json (root): Declares the workspace glob patterns (packages/*, apps/*, tooling/*) and defines repository-wide scripts like typecheck, test, and lint.
• packages/*/package.json: Individual workspace manifests where you declare specific dependencies. For example, packages/ui/package.json contains the React peer dependency declarations.
• bun.lock: The central lockfile that Bun regenerates when you run bun install from the root. Never edit this file manually.
• turbo.jsonc: Defines the Turborepo pipeline tasks (dev, build, test, typecheck) that run across workspaces.
• scripts/lint.sh: The executable script triggered by bun run lint that enforces code quality rules.
• .github/workflows/ci.yml: The GitHub Actions workflow that automatically runs type-checking, linting, and tests on pull requests.

Summary

• Use bun add <pkg>@latest -w from the repository root to upgrade specific dependencies across the monorepo.
• Execute bun install strictly from the root to regenerate the bun.lock file for all workspaces.
• Run bun run typecheck, bun run lint, and bun run test to validate that updates did not break TypeScript contracts, coding standards, or runtime behavior.
• Commit both package.json changes and bun.lock to ensure consistent dependency resolution for other developers and CI pipelines.

Frequently Asked Questions

What is the difference between bun add and bun upgrade?

Use bun add <package>@latest when you want to install a specific package or change its version in package.json. Use bun upgrade inside a workspace directory to bump all existing dependencies to their latest compatible versions based on the semver ranges already declared in that workspace's package.json.

Why must I run bun install from the repository root?

Running bun install from the root ensures Bun recognizes the workspace configuration defined in the root package.json and updates the central bun.lock file for all workspaces simultaneously. Running it from a subdirectory creates an isolated lockfile for that workspace only, breaking dependency synchronization across the monorepo.

How do I handle peer dependency conflicts when updating?

When updating packages like React that are declared as peer dependencies in workspaces such as packages/ui/package.json, ensure the version you install matches the peerDependencies constraints across all consuming workspaces. If conflicts arise, update the peer dependency declarations in the relevant package.json files to match the new version before running bun install.

Can I update dependencies for a single workspace only?

Yes. Navigate to the specific workspace directory (for example, cd packages/ui) and run bun add <package>@latest without the -w flag. This updates only that workspace's package.json. However, you must still run bun install from the repository root afterward to synchronize the changes into the shared bun.lock file.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}