# Different‑AI OpenWork Dependencies: Complete Package Reference for the Monorepo

> Discover the complete package dependencies for the Different AI OpenWork monorepo. Explore core packages like React, Electron, Hono, Zod, and OpenTelemetry powering this pnpm monorepo.

- Repository: [Different AI/openwork](https://github.com/different-ai/openwork)
- Tags: api-reference
- Published: 2026-08-05

---

**OpenWork uses a pnpm‑powered monorepo architecture where each workspace declares its own runtime dependencies, with core packages including React, Electron, Hono, Zod, OpenTelemetry, and the Model Context Protocol SDK.**

This guide maps every major dependency in the `different-ai/openwork` repository. Whether you're contributing to the desktop shell, the enterprise API, or the shared UI library, you'll find the exact packages, versions, and source file locations here.

## Core UI Package Dependencies

The `@openwork/ui` workspace provides reusable interface components. According to [[`packages/ui/package.json`](https://github.com/different-ai/openwork/blob/main/packages/ui/package.json)](https://github.com/different-ai/openwork/blob/dev/packages/ui/package.json), it defines:

- **`react`** – declared as a peer dependency (the host app brings its own version)
- **`@paper-design/shaders`** and **`@paper-design/shaders-react`** – shader-based visual effects

These dependencies enforce a clean separation: the UI library renders graphics but does not dictate the React version.

## Desktop Shell Dependencies

The Electron-based desktop application lives in `apps/desktop`. Its [[`package.json`](https://github.com/different-ai/openwork/blob/main/package.json)](https://github.com/different-ai/openwork/blob/dev/apps/desktop/package.json) bundles:

| Dependency | Purpose |
|------------|---------|
| `electron` | Core cross-platform runtime |
| `electron-updater` | Auto-update mechanism |
| `better-sqlite3` | Embedded, high-performance SQLite database |
| `drizzle-orm` | Type-safe SQL query builder |
| `yaml` | Configuration file parsing |
| `zod` | Runtime schema validation |
| `@opencode-ai/sdk` | Integration with the OpenCode AI service |
| `@openwork/paths` | Internal workspace package for path utilities (via `workspace:*` protocol) |

The `workspace:*` protocol ensures pnpm resolves `@openwork/paths` locally rather than from a registry, keeping internal dependencies in sync.

## Enterprise DEN API Dependencies

The backend API in `ee/apps/den-api` follows a **modern, observable, schema-first** design. Its [[`package.json`](https://github.com/different-ai/openwork/blob/main/package.json)](https://github.com/different-ai/openwork/blob/dev/ee/apps/den-api/package.json) lists:

**Web Framework & Documentation**
- `hono` – lightweight TypeScript web framework
- `@hono/mcp` – Model Context Protocol middleware
- `@hono/swagger-ui` – interactive API documentation

**Observability Stack (Complete OpenTelemetry)**
- `@opentelemetry/api`
- `@opentelemetry/sdk-node`
- `@opentelemetry/exporter-*` (various exporters for traces, metrics, logs)

**Authentication & Authorization**
- `better-auth` – core authentication framework
- `@better-auth/api-key` – programmatic access control
- `@better-auth/oauth-provider` – social login support

**Integration & Utilities**
- `zod` – request/response validation
- `@modelcontextprotocol/sdk` – MCP client/server primitives
- `stripe` – payment processing
- `sharp` – high-performance image transformations

This stack makes the DEN API **cloud-native by default**: every route is traced, every request is validated, and every auth flow is standardized.

## Enterprise MCP Client Dependencies

The standalone MCP client package at [[`packages/enterprise-mcp-client/package.json`](https://github.com/different-ai/openwork/blob/main/packages/enterprise-mcp-client/package.json)](https://github.com/different-ai/openwork/blob/dev/packages/enterprise-mcp-client/package.json) minimizes its footprint:

- **`@modelcontextprotocol/sdk`** – protocol implementation
- **`zod`** – schema contracts for remote procedures

This lean design lets other workspaces consume MCP capabilities without pulling in the full DEN API.

## Shared & Development Dependencies

Across all workspaces, certain tools appear repeatedly:

| Tool | Role | Typical Location |
|------|------|----------------|
| `zod` | Universal schema validation | UI, desktop, API packages |
| `typescript` | Static type checking | Root + every workspace |
| `tsx` | Fast TypeScript execution (dev) | Multiple [`package.json`](https://github.com/different-ai/openwork/blob/main/package.json) scripts |
| `tsup` | Zero-config bundler | Packages building for distribution |
| `turbo` | Task orchestration & caching | [`Root package.json`](https://github.com/different-ai/openwork/blob/dev/package.json) |
| `@types/node` | Node.js type definitions | Root development environment |
| `@openwork/types` | Internal shared type definitions | Consumed via `workspace:*` |

## Architecture Patterns in the Dependency Graph

### Workspace-Local Linking

Internal packages use `workspace:*` versions. Example from [`apps/desktop/package.json`](https://github.com/different-ai/openwork/blob/main/apps/desktop/package.json):

```json
{
  "dependencies": {
    "@openwork/paths": "workspace:*"
  }
}

```

pnpm resolves this to the local `packages/paths` directory, eliminating version drift.

### Schema-First Design

`zod` appears in every runtime package. A typical validation pattern:

```typescript
// Any workspace using Zod
import { z } from 'zod'

export const ConfigSchema = z.object({
  apiUrl: z.string().url(),
  timeout: z.number().positive().default(5000)
})

export type Config = z.infer<typeof ConfigSchema>

```

### Native Module Rebuilding

`better-sqlite3` requires platform-specific compilation. The desktop shell handles this via `electron-rebuild`, triggered in post-install hooks.

## Quick Reference: Key Source Files

| File Path | What It Contains |
|-----------|----------------|
| [[`package.json`](https://github.com/different-ai/openwork/blob/main/package.json)](https://github.com/different-ai/openwork/blob/dev/package.json) | Root dev tools: TypeScript, Turbo, pnpm workspace config |
| [[`packages/ui/package.json`](https://github.com/different-ai/openwork/blob/main/packages/ui/package.json)](https://github.com/different-ai/openwork/blob/dev/packages/ui/package.json) | UI runtime: React peers, Paper Design shaders |
| [[`apps/desktop/package.json`](https://github.com/different-ai/openwork/blob/main/apps/desktop/package.json)](https://github.com/different-ai/openwork/blob/dev/apps/desktop/package.json) | Desktop shell: Electron, SQLite, Drizzle, internal paths |
| [[`ee/apps/den-api/package.json`](https://github.com/different-ai/openwork/blob/main/ee/apps/den-api/package.json)](https://github.com/different-ai/openwork/blob/dev/ee/apps/den-api/package.json) | Enterprise API: Hono, OpenTelemetry, Better-Auth, Stripe, MCP |
| [[`packages/enterprise-mcp-client/package.json`](https://github.com/different-ai/openwork/blob/main/packages/enterprise-mcp-client/package.json)](https://github.com/different-ai/openwork/blob/dev/packages/enterprise-mcp-client/package.json) | MCP client: protocol SDK, Zod |

## Practical Code Examples

### Using the UI Package with Workspace Imports

```typescript
// In a consuming application
import { ShaderBackground } from '@openwork/ui/react'
import { z } from 'zod'

const PropsSchema = z.object({ intensity: z.number().min(0).max(1) })

export function App() {
  return <ShaderBackground intensity={0.7} />
}

```

### Bootstrapping the Desktop Development Environment

```bash

# One-time setup

pnpm install

# Start Electron with hot reload

pnpm dev:desktop  # Maps to turbo dev --filter=@openwork/desktop

```

### Hono Route with OpenTelemetry in the DEN API

```typescript
import { Hono } from 'hono'
import { trace, context } from '@opentelemetry/api'

const app = new Hono()

app.post('/query', async (c) => {
  const tracer = trace.getTracer('den-api')
  const span = tracer.startSpan('process-query')
  
  try {
    const body = await c.req.json()
    // ... business logic
    return c.json({ results: [] })
  } finally {
    span.end()
  }
})

export default app

```

### MCP Client Invocation

```typescript
import { createMcpClient } from '@openwork/enterprise-mcp-client'

const client = createMcpClient({
  baseUrl: process.env.MCP_URL!,
  apiKey: process.env.MCP_API_KEY!
})

// Call a remote tool defined by an MCP server
const result = await client.callTool('analyze-code', {
  repository: 'different-ai/openwork',
  path: 'apps/desktop'
})

```

## Summary

- **Monorepo tool**: pnpm with `workspace:*` protocol for internal linking
- **Frontend stack**: React + Paper Design shaders in `@openwork/ui`
- **Desktop runtime**: Electron with `better-sqlite3`, Drizzle ORM, and auto-updates
- **Backend framework**: Hono with OpenTelemetry instrumentation throughout
- **Authentication**: Better-Auth for OAuth, API keys, and SCIM
- **Protocol layer**: Model Context Protocol SDK for AI tool integration
- **Validation**: Zod everywhere for type-safe runtime contracts
- **Observability**: Full OpenTelemetry suite (API, SDK, exporters) in enterprise deployments

## Frequently Asked Questions

### What package manager does OpenWork use?

OpenWork uses **pnpm** exclusively. The root [`package.json`](https://github.com/different-ai/openwork/blob/main/package.json) defines workspace globs, and the [`pnpm-workspace.yaml`](https://github.com/different-ai/openwork/blob/main/pnpm-workspace.yaml) file (implied by the monorepo structure) coordinates cross-package dependencies. Internal packages reference each other with `workspace:*` versions.

### How are internal dependencies like `@openwork/paths` resolved?

pnpm treats `workspace:*` as a local file reference. When `apps/desktop` declares `"@openwork/paths": "workspace:*"`, pnpm symlinks directly to `packages/paths` without publishing to npm. This guarantees version consistency and instant propagation of changes.

### Why does the DEN API include both Hono and OpenTelemetry?

**Hono** provides the HTTP routing and middleware layer; **OpenTelemetry** provides cross-cutting observability. They operate at different levels—Hono handles request/response cycles, while OpenTelemetry traces, metrics, and logs capture performance and behavior data. The combination yields a lightweight, instrumented API server suitable for production AI workloads.