Complete Guide to oblien/openship Dependencies: Runtime Packages Explained

The oblien/openship monorepo organizes runtime dependencies across a workspace architecture, with root-level utilities defined in package.json and specialized workspace packages like @repo/db, @repo/core, and @repo/adapters handling database persistence, schema validation, and external service integration.

The oblien/openship project is a modern monorepo that orchestrates multiple applications through Yarn-style workspaces. Understanding the dependency structure is essential for contributors tracing how external libraries like Drizzle ORM, AWS SDK, and Zod integrate into the platform's architecture. All production dependencies are declared in specific package.json files throughout the repository, linked via workspace references to ensure version consistency.

Root-Level Dependencies in package.json

The root package.json provides a thin layer of top-level utilities that power the entire OpenShip platform. These dependencies are available across all workspace packages and applications.

• @octokit/auth-oauth-device (^8.0.3) – Handles GitHub OAuth device-flow authentication for API calls
• api (^6.1.3) – Core API layer that powers the OpenShip service layer
• sonner (^2.0.7) – Toast-notification UI library for user feedback

These root dependencies establish the foundation for GitHub integration and core service functionality, while specific domain logic resides in dedicated workspace packages under packages/.

Workspace Package Dependencies

The monorepo splits functionality into discrete workspace packages, each declaring only the libraries required for its specific domain.

@repo/core: Schema Validation Layer

Located at packages/core/package.json, this package centralizes data validation across the entire platform.

• zod (^4.3.6) – Type-safe schema validation library used throughout the codebase for runtime type checking

This package acts as a shared dependency for other workspace modules, ensuring consistent validation logic between the database layer and API adapters.

@repo/db: Database and ORM

The packages/db/package.json defines the persistence layer, supporting both traditional PostgreSQL and embedded database engines.

• drizzle-orm (^0.45.1) – Type-safe ORM for PostgreSQL and PGlite operations
• pg (^8.20.0) – Official PostgreSQL client for Node.js
• @electric-sql/pglite (^0.3.15) – In-process SQLite-compatible PostgreSQL engine for lightweight deployments
• @repo/core (workspace:*) – Workspace reference to shared Zod validation utilities

This architecture allows OpenShip to run against full PostgreSQL instances in production while using PGlite for local development or edge deployments.

@repo/ui: UI Utility Libraries

The packages/ui/package.json contains styling utilities that support the React-based frontend applications.

• class-variance-authority (^0.7.1) – Utility for conditional class-name generation in components
• clsx (^2.1.1) – Tiny helper to concatenate class names conditionally
• tailwind-merge (^3.5.0) – Merges Tailwind CSS classes without style conflicts

These libraries enable consistent, type-safe styling across the Dashboard and other frontend apps in the apps/ directory.

@repo/adapters: External Service Integration

Located at packages/adapters/package.json, this package encapsulates all third-party service integrations.

• @aws-sdk/client-s3 (^3.668.0) – AWS S3 client for object storage operations
• @aws-sdk/lib-storage (^3.668.0) – High-level streaming upload helpers for S3
• @aws-sdk/s3-request-presigner (^3.668.0) – Generates presigned URLs for secure client-side uploads
• dockerode (^4.0.9) – Docker API wrapper for container management and orchestration
• ssh2 (^1.17.0) – SSH client for remote command execution on deployment targets
• ignore (^7.0.5) – Parses .gitignore-style ignore files for file operations
• oblien (^2.2.45) – Internal helper library providing miscellaneous utilities
• @repo/core (workspace:*) – Shared Zod validation utilities

This package isolates infrastructure concerns, allowing the main application code to interact with AWS, Docker, and remote servers through a unified interface.

How the Dependency Graph Fits Together

The oblien/openship monorepo uses workspace references ("workspace:*") to link internal packages, ensuring that all applications consume the same version of shared code.

1. Base Layer – @repo/core provides Zod validation used by both @repo/db and @repo/adapters
2. Infrastructure Layer – @repo/db and @repo/adapters depend on @repo/core and external service SDKs
3. Presentation Layer – @repo/ui supplies styling utilities to frontend applications
4. Application Layer – Apps in apps/* (Dashboard, API, Desktop, CLI, Email) import from workspace packages and assemble the complete platform

A single pnpm install or bun install resolves all workspace references to local directories, eliminating version drift between packages while deduplicating external dependencies like React 19 declared in peerDependencies.

Practical Usage Examples

Below are implementations showing how OpenShip consumes these dependencies in production code.

Using the Zod validator from @repo/core for deployment configuration:

import { z } from '@repo/core';

const DeploySchema = z.object({
  name: z.string(),
  version: z.string(),
  env: z.record(z.string()),
});

export type DeployConfig = z.infer<typeof DeploySchema>;

Generating presigned S3 URLs via @repo/adapters for direct client uploads:

import { getPresignedUrl } from '@repo/adapters';

async function uploadPackage(bucket: string, key: string) {
  const url = await getPresignedUrl({ bucket, key, expiresIn: 600 });
  return url;
}

Building a type-safe button component with class-variance-authority and tailwind-merge:

import { cva } from 'class-variance-authority';
import { twMerge } from 'tailwind-merge';
import clsx from 'clsx';

const buttonStyles = cva('px-4 py-2 rounded', {
  variants: {
    intent: {
      primary: 'bg-blue-600 text-white',
      secondary: 'bg-gray-200 text-gray-800',
    },
  },
  defaultVariants: { intent: 'primary' },
});

export function Button({ intent, className, children }: any) {
  const classes = twMerge(buttonStyles({ intent }), clsx(className));
  return <button className={classes}>{children}</button>;
}

Summary

• oblien/openship organizes code into a workspace-based monorepo with runtime dependencies split across root and package-level package.json files
• Root dependencies (@octokit/auth-oauth-device, api, sonner) handle GitHub OAuth, core API functionality, and UI notifications
• Database layer (@repo/db) combines Drizzle ORM with PostgreSQL and PGlite support for flexible deployment options
• Infrastructure adapters (@repo/adapters) integrate AWS S3, Docker, and SSH capabilities while depending on @repo/core for validation
• Workspace references (workspace:*) ensure all packages use consistent versions of shared libraries like Zod and React

Frequently Asked Questions

What package manager does oblien/openship use for dependency management?

The repository uses Yarn-style workspaces compatible with pnpm or bun to resolve dependencies. The workspace:* protocol links internal packages, while external dependencies are pinned to specific semantic versions in each package.json file.

Which database libraries power the OpenShip platform?

OpenShip uses drizzle-orm (^0.45.1) as its primary ORM, backed by the pg driver (^8.20.0) for PostgreSQL connections and @electric-sql/pglite (^0.3.15) for embedded database scenarios. All database schemas are validated using Zod (^4.3.6) from the @repo/core package.

How does OpenShip handle AWS S3 integration?

The @repo/adapters package bundles three AWS SDK v3 libraries: @aws-sdk/client-s3 for object operations, @aws-sdk/lib-storage for streaming uploads, and @aws-sdk/s3-request-presigner for generating temporary upload URLs. This encapsulation allows applications to interact with S3 through a unified adapter interface rather than importing AWS SDK directly.

Are development dependencies included in the OpenShip production bundle?

No, only dependencies listed under the "dependencies" field in each package.json are considered runtime dependencies. Development-only tools like TypeScript, Vitest, tsup, and Prettier are excluded from production builds as they reside in "devDependencies" and are not required for the application to execute.

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