@earendil-works/pi-server

中文文档
1.1.0发布于 2026/10/08MITTypeScriptES Module构建来源已验证近 30 天下载 24.6万

experimental server package for pi

原始使用文档

@earendil-works/pi-server

Experimental local server that routes clients to application-hosted durable Sessions.

The current slice supports server- and Session-scoped facet-service routing and multi-presentation attachment. RoutedServerServiceHost.attachClient() creates one connection-scoped server service endpoint with narrow attachment-management capabilities. RoutedSessionHandle.attachClient() returns a presentation-scoped Session capability. Its invokeService() forwards an opaque service/member envelope to the selected Session endpoint; the server validates the attachment route but does not load the facet contract.

  • server service calls and subscriptions route opaquely through the connection's RoutedServerServiceAttachment;
  • the application-owned SessionDirectory projects the private catalog into replicated presentation-safe state;
  • the application-owned SessionManagement creates, removes, attaches, and detaches Sessions without exposing route IDs in business results;
  • attachment changes are published out of band after the router installs or clears the live route;
  • Session service calls route through invokeService without server-side business-payload decoding;
  • service subscription updates remain scoped to the requesting attachment;
  • application observations such as transcripts route as ordinary service state without server-owned business schemas.

A Session may have multiple presentation attachments. Repeating attach from one connection is idempotent; every successful attachment has a server-generated attachmentId delivered only as routing control data. Session requests carry { serverId, sessionId, attachmentId }, and the server rejects stale or mismatched routes. Losing a connection rejects its local responses but releases its attachment only after admitted service calls settle. The host decides when zero presentation demand and worker-local Harness activity permit worker retirement. Server shutdown closes every routed Session handle, releasing its worker and Session writer ownership.

import { randomUUID } from "node:crypto";
import {
  type RoutedServerServiceHost,
  type RoutedSessionHandle,
  type ServerHost,
  type SessionMetadata,
  SessionNotFoundError,
} from "@earendil-works/pi-server";
import { createUnixServer, getUnixSocketPath } from "@earendil-works/pi-server/unix";

interface StoredSession extends SessionMetadata {
  path: string;
}

async function startServer(
  serverServices: RoutedServerServiceHost,
  sessions: Map<string, StoredSession>,
  openRoutedSession: (session: StoredSession) => Promise<RoutedSessionHandle>,
) {
  const host: ServerHost<StoredSession> = {
    serverServices,
    async resolveSession(sessionId) {
      const metadata = sessions.get(sessionId);
      if (!metadata) throw new SessionNotFoundError(`Unknown session: ${sessionId}`);
      return metadata;
    },
    openSession: (metadata) => openRoutedSession(metadata),
  };

  const serverId = randomUUID();
  const server = createUnixServer(host, {
    serverId,
    path: getUnixSocketPath(serverId, "/run/user/1000/pi"),
  });
  await server.start();
  return server;
}

Applications supply a required server service host, a bounded Session resolver, and a routed Session factory. SessionMetadata only requires an id; applications may extend it with their own storage fields. Session discovery and management are application-owned services; the protocol server only asks the resolver for metadata when routing an attachment. The host owns acquiring the worker-local Session and Harness. Failures are cleaned up in that worker. Neither an open JavaScript Session nor a Harness crosses the process boundary.

serverId is a logical identity supplied by the launcher, not a socket address. The Unix preset requires an explicit physical path; getUnixSocketPath() derives one from a caller-selected directory. Choose a short, private runtime directory rather than deriving the route from an unbounded home-directory path. A long-lived launcher can reuse the same ID and path when replacing a server process.

Server composes transports through ServerListener; peer authentication remains application policy and is not implemented by the experimental Unix transport. The Unix submodule provides createUnixListener() and createUnixServer(). Low-level routed-envelope validation, CBOR, and framing come from @earendil-works/pi-protocol; Chord owns service-control parsing, error codes, snapshots and updates, and each subscription's replicated-state encoder.

Server and worker lifecycle is managed outside the public Pi protocol. The replaceable application server converts connection attachments into private demand updates; the worker combines generation-tagged demand with authoritative Harness activity. The experimental coordinator only supplies stable routing and reports generic server-generation connection changes.

版本与发布记录

@earendil-works/pi-server 共发布 20 个版本,首次发布于 2026/08/06;过去 12 个月发布了 20 个版本。最新版本附带 npm provenance 构建来源证明,可追溯到公开的 CI 构建记录。

版本发布日期距今
1.1.0latest2026/10/081 个月前
1.0.42026/10/061 个月前
1.0.32026/10/051 个月前
1.0.22026/10/041 个月前
1.0.12026/10/031 个月前
1.0.02026/10/021 个月前

关于 @earendil-works/pi-server 的常见问题

@earendil-works/pi-server 是什么?

experimental server package for pi

如何安装 @earendil-works/pi-server?

在项目目录运行 npm install @earendil-works/pi-server,或使用 pnpm add / yarn add / bun add。

@earendil-works/pi-server 支持 TypeScript 吗?

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

@earendil-works/pi-server 支持 ESM 还是 CommonJS?

以 ES Module 形式发布,推荐使用 import 引入。在 CommonJS 项目中,Node.js 20.19+ / 22.12+ 可以直接 require() 不含顶层 await 的 ES Module,更早的版本需要改用动态 import()。

@earendil-works/pi-server 需要什么版本的 Node.js?

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

@earendil-works/pi-server 可以商用吗?

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

@earendil-works/pi-server 的下载量有多少?

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

@earendil-works/pi-server 还在维护吗?

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