Skip to content

docs: TypeScript core migration plan (Phase 1 inventory)#3611

Draft
christierney wants to merge 7 commits intomainfrom
worktree-chris/ts-module
Draft

docs: TypeScript core migration plan (Phase 1 inventory)#3611
christierney wants to merge 7 commits intomainfrom
worktree-chris/ts-module

Conversation

@christierney
Copy link
Collaborator

Summary

  • Inventory the Go API surface (46 REST endpoints + SSE) grouped by domain concept
  • Map all extension API call sites — confirmed they're centralized in src/api/resources/
  • Identify all external resources (Connect API, file system, credentials, interpreters, etc.)
  • Assess the existing test suite for both Go and TypeScript
  • Propose candidate domain groupings, port interfaces, and migration order
  • Document open questions for team discussion before proceeding to Phase 3 (port interface design)

This is the Phase 1 output of a planned migration from the Go REST API backend to an in-process TypeScript core package using hexagonal architecture.

Reference implementation: https://github.com/christierney/hexatype

Open questions (looking for feedback)

  1. SSE replacement — How should the core report deployment progress?
  2. Credential storage — VSCode SecretStorage vs. driven port with multiple adapters?
  3. Migration approach — Option A (port interface boundary) vs. Option B (feature flag routing)?
  4. TOML handling — Port concern or direct core dependency?
  5. Accounts vs. Credentials — Distinct domain concept or derived view?

See TS_MIGRATION_PLAN.md for full details.

🤖 Generated with Claude Code

christierney and others added 7 commits February 25, 2026 17:44
Inventory the Go API surface (46 endpoints), map extension call sites,
identify external resources, and assess the test suite as groundwork
for migrating from the Go REST API to an in-process TypeScript core
using hexagonal architecture.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Proof-of-concept implementing the hexagonal architecture pattern for the
Configuration domain:

- Domain types translated from Go's internal/config/types.go
- ConfigurationStore port interface (list/read/write/remove)
- Three use cases: ListConfigurations, GetConfiguration, SaveConfiguration
- Product type compliance logic ported from Go
- 9 tests using node:test with inline fakes (no mocking framework)
- Extension wired via tsconfig paths (no npm workspaces, no vsce issues)
- Migration plan updated with workspace structure decisions

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
First driven adapter implementing the ConfigurationStore port:

- Reads/writes .posit/publish/*.toml files
- Translates snake_case TOML keys to camelCase domain types
- Maps filesystem errors to domain errors (NotFound, ReadError)
- 13 tests against real temp directories (list, read, write, remove,
  round-trip, error cases)
- Extension tsconfig wired with @publisher/adapters path mapping
- Proof-of-concept doc updated with full end-to-end architecture

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Demonstrates the incremental migration strategy: GoApiConfigurationStore
implements the same ConfigurationStore port as FsConfigurationStore, but
delegates to the existing Go backend REST API. This lets the extension be
wired through the port interface today while still using the Go backend.

Removes rootDir from the extension tsconfig to allow TypeScript to follow
paths mappings into packages/core/ and packages/adapters/.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Move error-collection logic from the ListConfigurations use case into
each adapter's list() implementation. This eliminates the N+1 pattern
where callers had to list names then read each one individually.

The use case becomes a thin wrapper, and both FsConfigurationStore and
GoApiConfigurationStore now return full summaries (with parsed configs
or error messages) in a single call.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant