mirror of https://github.com/deepseek-ai/deepseek-harness synced 2026-08-15 21:04:50 +00:00

Files

imccyu a213befd0f build(release): publish the vendored framework and the native packages publicly

The three release sequences shipped with publishConfig.access: restricted, so
nothing in the @deepseek-ai scope was installable from outside the organization.

A restricted dependency is what actually blocks a public consumer: every harness
package declares the vendored framework as a peerDependency, and
dsh-sandbox-local declares the Landlock entry as a dependency. Those two
sequences therefore go public first — the nine vendor/* packages and the three
native/landlock-run packages — while the dsh family stays restricted until its
own sequence is opened deliberately. No public package requires a restricted one
in this arrangement.

Access is now per sequence, so no publish path can pass --access: one flag
cannot express two levels and would override the manifest that owns the fact.
publish.ts stops passing it, matching the native workflow, and
check-workspace-constraints holds each manifest to its own sequence's level,
which is what stops the scope from drifting one package at a time.

Harness consumers reference the Landlock entry as workspace:^ instead of
workspace:*, so a published harness package accepts the entry's patch and minor
releases. The entry keeps workspace:* for its platform packages, where the
binary must match the entry version exactly.

Two rationales that named a private registry no longer describe the vendored
sequence; they now state the durable reason, which is that the verification must
not depend on the registry already carrying matching versions.

2026-08-13 14:05:48 +08:00

src

refactor(loader): resolve config after injected services

2026-08-10 23:45:04 +08:00

bin.js

build(vendor): rescope the vendored Cordis packages into @deepseek-ai

2026-08-10 22:04:13 +08:00

LICENSE

Vendor Cordis framework packages as source

2026-06-11 10:53:32 +08:00

package.json

build(release): publish the vendored framework and the native packages publicly

2026-08-13 14:05:48 +08:00

README.md

Vendor Cordis framework packages as source

2026-06-11 10:53:32 +08:00

tsconfig.json

refactor: rename build typings dir to types

2026-06-20 00:26:02 +08:00

README.md

Cordis

Cordis is a TypeScript plugin framework for applications that need explicit dependency injection, scoped services, lifecycle-managed cleanup, and optional configuration-driven loading. The core package is published as cordis; the official packages in this repository add a loader, config-file includes, HMR, console logging, timers, and project scaffolding.

Install

yarn add cordis

Cordis is ESM-first. The repository is tested on current Node releases, and the scaffolder requires Node 22 or newer.

Quick Start

import { Context, Service } from 'cordis'

declare module 'cordis' {
  interface Context {
    counter: Counter
  }

  interface Events {
    'app/ready'(message: string): void
  }
}

class Counter extends Service {
  value = 0

  constructor(ctx: Context) {
    super(ctx, 'counter')
  }

  next() {
    return ++this.value
  }
}

const greeter = Object.assign((ctx: Context) => {
  ctx.on('app/ready', (message) => {
    ctx.logger.info('%s #%d', message, ctx.counter.next())
  })
}, {
  inject: ['counter'],
})

const root = new Context()
await root.plugin(Counter)
await root.plugin(greeter)

root.emit('app/ready', 'started')
await root.fiber.dispose()

The important pieces are:

new Context() creates the root dependency container.
ctx.plugin() starts a plugin and returns a Fiber.
inject tells Cordis which services must exist before the plugin runs.
Effects, event listeners, and services are removed when their owning fiber is disposed.

Documentation

Packages

Package	Purpose
`cordis`	Core context, plugin registry, fiber lifecycle, events, services, and logger.
`create-cordis`	Interactive project scaffolder.
`@cordisjs/plugin-loader`	Runtime plugin tree and loader service.
`@cordisjs/plugin-include`	YAML/JSON config-file include support for the loader.
`@cordisjs/plugin-group`	Nested plugin groups for loader configs.
`@cordisjs/plugin-hmr`	Hot module replacement for loader-managed plugins.
`@cordisjs/plugin-logger-console`	Console exporter for the built-in logger.
`@cordisjs/plugin-timer`	Disposal-aware timeout, interval, throttle, and debounce helpers.
`@cordisjs/utils`	Shared utilities used by Cordis packages.

Development

yarn install
yarn build
yarn test
yarn lint

The monorepo uses Yakumo to build and test all packages. Most examples in the docs use public APIs from cordis; loader examples additionally use @cordisjs/plugin-loader and @cordisjs/plugin-include.