@crossdelta/platform-sdk

中文文档
0.26.15发布于 2026/11/04MITTypeScriptESM + CJS近 30 天下载 5321

Platform toolkit for event-driven microservices — keeping code and infrastructure in lockstep.

原始使用文档
文档目录8 节
  1. 🚀 Quick Start
  2. 🎯 5-Minute Tutorial
  3. 🧰 Commands
  4. 🧩 Works with coding agents
  5. 🚢 Deployment
  6. ⚙️ Requirements
  7. 🔍 Under the Hood
  8. License

pf

Platform SDK

The platform toolkit for backend + infrastructure.

pf scaffolds real-world platforms: backend services, event-driven messaging, infrastructure. All wired together and kept in sync.


npm version   TypeScript   Bun   MIT License

Quick Start • Tutorial • Commands • Deployment


🚀 Quick Start

# With Bun
bun add -g @crossdelta/platform-sdk

# With npm
npm install -g @crossdelta/platform-sdk

# Or auto-install (macOS/Linux/WSL)
curl -fsSL https://unpkg.com/@crossdelta/platform-sdk@latest/install.sh | bash

Windows users: Use WSL for the best experience.

Then create your first platform:

pf new workspace my-platform -y && cd my-platform
pf dev

✅ Turborepo monorepo with Biome linting
✅ NATS + JetStream for event-driven messaging
✅ Pulumi infrastructure ready for deployment
✅ Auto-generated .env.local with service ports

🎯 5-Minute Tutorial

Add two services and wire an event between them:

# 1. Create two services
pf new hono-micro services/orders
pf new hono-micro services/notifications

# 2. Wire an event from orders → notifications
pf cloudevents add order.created --service services/notifications

# 3. Restart to pick up new services
pf dev

# 4. Publish a test event, watch notifications react
pf cloudevents publish order.created

What just happened
📦 Two services with health checks and Pulumi configs
📝 One event contract in packages/contracts/
🔗 One handler that auto-discovers the event
✨ No manual wiring. No config drift. Everything is explicit.

🧰 Commands

CommandWhat it does
pf dev🚀 Start development infrastructure (NATS) + all services in watch mode
pf new hono-micro <path>⚡ Create a Hono service (lightweight, Bun-optimized)
pf new nest-micro <path>🏢 Create a NestJS service (full-featured, decorators)
pf new workspace [name]🏗️ Create a new workspace with infrastructure setup
pf cloudevents add <type> --service <path>🔗 Add contract + handler + wire stream
pf cloudevents list📋 List available events and consumers
pf cloudevents publish <type>📤 Publish mock event to NATS
pf setup completion🔧 Install shell autocompletion (zsh/bash)
pf test🧪 Run tests across the monorepo
pf build📦 Build all packages and services
pf lint✨ Lint and format with Biome
pf audit🔒 Run security audit on dependencies
pf pulumi <args>☁️ Run Pulumi in the workspace's infra/ directory, e.g. pf pulumi up

Your workspace can add its own commands: an entry under pf.commands in the root package.json (optionally with cwd and command), or any root scripts entry, runs as pf <name>. Plugins listed under pf.plugins add command groups, as @crossdelta/cloudevents does for pf cloudevents. The plugin interface is described in docs/plugins.md in the package source.


🧩 Works with coding agents

@crossdelta/pf-mcp is a Model Context Protocol server for the Platform SDK. It exposes four tools:

ToolWhat it does
scan_workspaceScan the workspace for services, contracts, and configuration
generate_serviceGenerate a plan for a new microservice (dry-run by default)
plan_reviewValidate a generation plan before applying
apply_changesApply the changes from a generation plan

The server plans the structure; the agent writes the content. A service is created in this order: the agent calls generate_service with a prompt, receives a plan with files and a planHash, writes the code for those files, optionally calls plan_review, asks you to confirm, and then calls apply_changes with expectedPlanHash.

bun add @crossdelta/pf-mcp
node ./node_modules/@crossdelta/pf-mcp/dist/cli.js --stdio

The server talks over stdio, so the MCP client of your agent has to start that command. It also serves the generator guidelines from docs/generators/ in the package source as the MCP resource docs://generators.


🚢 Deployment

pf pulumi up              # deploys the current Pulumi stack

Each workspace ships with one Pulumi stack and pre-configured GitHub Actions. Add more stacks (e.g. stage, production) as your platform grows. pf and generate-env work with any stack name.

pf dev generates .env.local from the current stack's Pulumi config (secrets, API keys) and discovered service ports.

Pre-configured GitHub Actions included:

TriggerAction
PR to main🧪 Lint + test
Push to main🚀 Build, push to GHCR, deploy
Changes in packages/📦 Publish to npm
🔐 Required secrets
SecretDescription
PULUMI_ACCESS_TOKENPulumi Cloud token
DIGITALOCEAN_TOKENDO API token

⚙️ Requirements

RequirementNotes
Bun or Node.js ≥ 21Bun recommended for speed
Pulumi CLIFor infrastructure deployment
DockerFor local NATS

🔍 Under the Hood

📁 Project structure
my-platform/
├── services/           # Your microservices
│   ├── orders/
│   └── notifications/
├── packages/
│   └── contracts/      # Event contracts (single source of truth)
├── infra/
│   └── services/       # Auto-generated Pulumi configs
└── .env.local          # Auto-generated from infra

The key insight: Services define their ports, env vars, and event subscriptions once. Everything else is derived.

🛠️ Tech stack
LayerTechnology
MonorepoTurborepo
ServicesHono or NestJS
MessagingNATS + JetStream
Events@crossdelta/cloudevents (CloudEvents + Zod)
InfrastructurePulumi → DigitalOcean (extensible)
RuntimeBun
⚙️ Workspace configuration
{
  "pf": {
    "registry": "my-org/my-platform",
    "commands": {
      "deploy": {
        "cwd": "infra",
        "command": "pulumi up --yes",
        "description": "Deploy infrastructure to production"
      }
    },
    "paths": {
      "services": { "path": "services", "watch": true },
      "contracts": { "path": "packages/contracts" }
    }
  }
}
🏗️ Service infrastructure config
// infra/services/orders.ts
import { ports, type K8sServiceConfig } from '@crossdelta/infrastructure'

const config: K8sServiceConfig = {
  name: 'orders',
  ports: ports().http(4001).build(),
  replicas: 1,
  healthCheck: { httpPath: '/health' },
  resources: {
    requests: { cpu: '50m', memory: '64Mi' },
    limits: { cpu: '150m', memory: '128Mi' },
  },
}

export default config

See @crossdelta/infrastructure for full options.

📡 Event-driven architecture

Contracts live in packages/contracts/ as the single source of truth:

// packages/contracts/src/events/orders/created.ts
import { createContract } from '@crossdelta/cloudevents'
import { z } from 'zod'

export const OrderCreatedSchema = z.object({
  orderId: z.string(),
  total: z.number(),
})

export type OrderCreatedData = z.infer<typeof OrderCreatedSchema>

export const OrdersCreatedContract = createContract({
  type: 'order.created',
  channel: { stream: 'ORDERS' },
  schema: OrderCreatedSchema,
})

Handlers import contracts and delegate to use cases:

// services/notifications/src/events/order-created.handler.ts
import { handleEvent } from '@crossdelta/cloudevents'
import { OrdersCreatedContract } from '@my-platform/contracts'
import { sendOrderNotification } from '../use-cases/send-notification.use-case'

export default handleEvent(OrdersCreatedContract, async (data) => {
  await sendOrderNotification(data)
})

Handlers are auto-discovered. No manual subscriptions.

See @crossdelta/cloudevents for full event API.

⚡ NATS message broker

Local NATS started by pf dev is development infrastructure. Production streams are materialized via Pulumi from contracts.

Every workspace includes pre-configured NATS with JetStream for development:

Development:

  • Auto-started with pf dev (docker-based, ephemeral)
  • Ports: 4222 (client), 8222 (monitoring)
  • Health check: curl http://localhost:8222/healthz
  • Streams: Auto-created by pf dev from contracts (memory, 1h retention)

Production:

  • Deployed via Pulumi (infra/)
  • Streams materialized from contracts with retention policies
  • Persistent storage (file-based) with explicit limits

Services never create streams. In dev, pf dev auto-creates from contracts. In prod, Pulumi materializes.


License

MIT © crossdelta

版本与发布记录

@crossdelta/platform-sdk 共发布 255 个版本,首次发布于 2025/12/01;过去 12 个月发布了 255 个版本。

版本发布日期距今
0.26.15latest2026/11/046 天前
0.26.142026/11/038 天前
0.26.132026/10/3110 天前
0.26.122026/10/2913 天前
0.26.112026/10/2813 天前
0.26.102026/10/2814 天前

关于 @crossdelta/platform-sdk 的常见问题

@crossdelta/platform-sdk 是什么?

Platform toolkit for event-driven microservices — keeping code and infrastructure in lockstep.

如何安装 @crossdelta/platform-sdk?

在项目目录运行 npm install @crossdelta/platform-sdk,或使用 pnpm add / yarn add / bun add。它还提供命令行工具 pf,可以用 npx pf 直接运行。

@crossdelta/platform-sdk 支持 TypeScript 吗?

支持。包内自带 TypeScript 类型声明(package.json 声明了 types 入口),安装后即可获得类型提示,无需再安装 @types 包。

@crossdelta/platform-sdk 支持 ESM 还是 CommonJS?

同时提供 ES Module 与 CommonJS 入口,import 和 require() 都可以使用,打包工具会自动选择合适的版本。

@crossdelta/platform-sdk 需要什么版本的 Node.js?

package.json 的 engines 字段要求 Node.js >=21.0.0。版本不符时 npm 默认只给出警告,开启 engine-strict 后会拒绝安装。

@crossdelta/platform-sdk 可以商用吗?

@crossdelta/platform-sdk 使用 MIT 许可。宽松许可:允许商业使用、修改和再分发,通常只需在分发时保留原版权与许可声明。以上为概括,不构成法律意见,请以许可原文为准。

@crossdelta/platform-sdk 的下载量有多少?

根据 npm 官方下载统计,@crossdelta/platform-sdk 在 2026/10/11 – 2026/11/09 这 30 天内被下载 5,321 次,日均约 177 次。下载量会把 CI 构建、镜像同步和作为其他包依赖的安装一并计入,适合横向比较热度,不能直接等同于使用人数。

@crossdelta/platform-sdk 还在维护吗?

最新版本 0.26.15 发布于 2026/11/04(6 天前);至今共发布 255 个版本,其中过去 12 个月发布了 255 个;首次发布于 2025/12/01。发布频率只是参考信号:功能稳定的工具可能很少需要更新,建议结合源码仓库的 issue 和提交记录判断。