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

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/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/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/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/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 scripts
tsup	Zero-config bundler	Packages building for distribution
turbo	Task orchestration & caching	Root 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:

{
  "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:

// 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/dev/package.json)	Root dev tools: TypeScript, Turbo, pnpm workspace config
[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/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/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/dev/packages/enterprise-mcp-client/package.json)	MCP client: protocol SDK, Zod

Practical Code Examples

Using the UI Package with Workspace Imports

// 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

# 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

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

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 defines workspace globs, and the 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.

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