Independent Modules and Libraries in the makeplane/plane Packages Directory

The packages directory in the makeplane/plane repository contains 15 independent, versioned libraries—including utilities, UI components, state management stores, and logging middleware—that each maintain their own package.json and can be imported separately via the @plane/* namespace.

The Plane project management platform is organized as a monorepo where functionality is decomposed into discrete, maintainable units. Within the packages directory, independent modules encapsulate specific concerns ranging from date formatting to rich-text editing, allowing teams to version, publish, and consume each package separately while maintaining strict type safety across the entire codebase.

Package Architecture Overview

The Plane monorepo follows a strict modular architecture where every subdirectory in packages/ represents a self-contained library. Each module contains its own package.json, TypeScript source files, and build configuration, enabling independent versioning and selective imports throughout the application.

Key architectural principles include:

• Self-contained builds: Every package compiles independently with its own entry point, typically src/index.ts or a configuration root like tsconfig.json.
• Workspace protocol: Internal dependencies reference each other using workspace:* imports.
• Unified tooling: Turbo and PNPM orchestrate the build pipeline while preserving package isolation.

Core Packages and Responsibilities

The packages directory houses 15 specialized modules organized by functional concern:

Infrastructure and Configuration

• @plane/typescript-config: Shared TypeScript compiler settings located at packages/typescript-config/tsconfig.json.
• @plane/tailwind-config: Centralized Tailwind CSS themes and utilities in packages/tailwind-config/tailwind.config.cjs.
• @plane/types: Global TypeScript definitions exported from packages/types/src/index.ts.
• @plane/constants: Shared enums and workspace settings defined in packages/constants/src/workspace.ts.

UI and Interaction

• @plane/ui: React component library with exports from packages/ui/src/index.ts and component implementations like packages/ui/src/components/button.tsx.
• @plane/hooks: Reusable React hooks including the hash scroll implementation in packages/hooks/src/use-hash-scroll.ts.
• @plane/editor: Rich-text editor with markdown parsing capabilities based in packages/editor/src/lib.ts.

State and Logic

• @plane/shared-state: MobX-based global stores for work-items and filters, defined in packages/shared-state/src/store.ts.
• @plane/services: API client layer and business logic connectors exported from packages/services/src/index.ts.
• @plane/propel: Third-party integrations (Zapier, Slack) configured in packages/propel/src/index.ts.

Utilities and Tooling

• @plane/utils: General-purpose helpers including date handling, color utilities, and markdown parsing, exported from packages/utils/src/index.ts.
• @plane/logger: Centralized request/response tracing and error formatting middleware in packages/logger/src/middleware.ts.
• @plane/decorators: TypeScript decorators for REST and WebSocket endpoints, such as the Rest decorator in packages/decorators/src/rest.ts.
• @plane/i18n: Internationalization utilities and language type definitions in packages/i18n/src/types/language.ts.
• @plane/codemods: Automated migration scripts including the Vitest configuration utility and directive removal tools in packages/codemods/src/remove-directives.ts.

How the Packages Work Together

Internal Dependency Management

Packages reference sibling modules using the PNPM workspace protocol. For example, the UI library imports color helpers from the utilities package, while the shared-state package consumes constants from @plane/constants:

// Inside @plane/ui components
import { parseColor } from '@plane/utils';

// Inside @plane/shared-state
import { WORKSPACE_SETTINGS } from '@plane/constants';

This workspace:* protocol ensures that changes in one package immediately propagate to dependents during development without requiring intermediate publishes.

Independent Publishing Pipeline

Because each package maintains its own package.json with explicit versioning, the Plane team can publish individual modules to npm without releasing the entire monorepo. External consumers can install only specific functionality—such as @plane/utils for date formatting—without pulling in the full UI library or application code.

Shared Build Configuration

Despite their independence, all packages share a unified build pipeline managed by Turbo and PNPM. This ensures consistent compilation targets, type checking, and code style across the modular architecture while preserving the ability to build packages in parallel with cached artifacts.

Practical Implementation Examples

Utility Functions

Import date formatting utilities from the specialized @plane/utils subpath:

import { formatDate } from '@plane/utils/date';

const today = formatDate(new Date());
// → "2024-04-01"

State Management

Access global MobX stores for workspace management:

import { workspaceStore } from '@plane/shared-state';

workspaceStore.setCurrent('my-workspace-id');

Logging Middleware

Instrument API calls with the centralized logger:

import logger from '@plane/logger';

export async function fetchData(url: string) {
  logger.info('Fetching data', { url });
  const res = await fetch(url);
  return res.json();
}

UI Components

Consume themed React components from the design system:

import { Button } from '@plane/ui';

export function MyPage() {
  return <Button onClick={() => alert('Clicked!')}>Click me</Button>;
}

API Decorators

Apply REST endpoint decorators to controllers using the decorators package:

import { Rest, Get } from '@plane/decorators';

@Rest('/projects')
class ProjectController {
  @Get('/')
  list() { /* ... */ }
}

Summary

• The packages directory contains 15 independent modules that function as separate libraries within the Plane monorepo.
• Each package maintains its own package.json, TypeScript configuration, and build pipeline, enabling selective publishing and versioning.
• Internal dependencies use the workspace:* protocol to reference sibling packages like @plane/utils and @plane/constants.
• Key packages include @plane/ui for components, @plane/shared-state for MobX stores, @plane/editor for rich-text handling, and @plane/decorators for API endpoint definitions.
• All modules share unified tooling via Turbo and PNPM while retaining the flexibility to be imported individually by external consumers.

Frequently Asked Questions

Can I use individual Plane packages outside the makeplane/plane monorepo?

Yes. Each package in the packages directory is designed for independent consumption. They can be published to npm and installed separately using their @plane/* namespace, allowing external projects to utilize specific functionality like the editor or utilities without importing the entire application codebase.

How do packages in the Plane repository reference each other?

Internal packages reference siblings using the PNPM workspace protocol (workspace:*) in their package.json dependencies. For example, @plane/ui imports utilities via import { helper } from '@plane/utils', which resolves to the local package source rather than a registry version, ensuring immediate integration of cross-package changes during development.

What build tools manage the independent modules in the Plane packages directory?

The Plane monorepo uses Turbo for orchestrating parallel builds and PNPM for workspace management. This combination allows caching of build artifacts across independent packages while maintaining strict isolation between module boundaries and ensuring consistent TypeScript compilation across all 15 libraries.

Are all packages in the makeplane/plane packages directory production code?

Most packages are production libraries, though some serve development-specific purposes. For example, @plane/codemods provides Vitest configuration scripts and automated migration tools, while @plane/typescript-config and @plane/tailwind-config supply shared configuration rather than runtime code. Each nonetheless follows the same modular structure with independent build configurations.

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