1.10 Implement the config service

[goofmint]

Part of Phase 1 — Core skeleton (tasks.md Task 1.10).

Summary

Implement configuration loading, layering, schema registry, and live reload.

Details

• Tolerant JSONC parser (comments + trailing commas → JSON.parse), with line/column error positions surfaced via the status sink.
• Layering: defaults (from contributes.configuration schemas + core defaults) ← user ~/.config/tecode/settings.json ← workspace .tecode/settings.json. tecode.config.get(key) reads the merged view.
• Schema registry fed by contributes.configuration (types + defaults; validation is best-effort MVP).
• fs.watch on both settings files and keybindings.json: on change re-parse, diff keys, fire onDidChangeConfiguration({ affectsConfiguration }), notify dependent services (hooks for theme/keymap; wired in later tasks).
• Broken file → keep last good configuration, surface the parse error.
• Path resolution behind a paths module (~/.config/tecode/ on POSIX, %APPDATA%\tecode\ on Windows).

Completion requirements

• JSONC edge cases tested (line/block comments, trailing commas, strings containing //)
• Layer merge tested: workspace overrides user overrides defaults, per key
• Watch-triggered reload fires onDidChangeConfiguration with a correct affectsConfiguration predicate
• Parse error keeps last-good config and reports position
• bun test and lint pass

References

• requirements.md: Req 9.1–9.4
• design.md: §11, §17 (paths)

Dependencies

Blocked by: 1.2 (#3). Parallelizable with 1.3–1.9.

[goofmint]

@coderabbitai make plan in Japanese

---

Generated by Claude Code

[coderabbitai]

Coding Plan

Summary

• design.md §11/§15 の方針に従い、外部ライブラリを使わず JSONC パーサーを手書きします。
• OS 依存のパス解決を host/paths.ts に集約し、呼び出し側の process.platform 分岐を排除します。
• createConfigService(deps) ファクトリと Deps 注入、keymap/context.ts のイベントパターンを踏襲し、既存 core 規約に一致させます。
• fs/watcher を任意注入にしてテストを決定論的にし、統合テストのみ実ファイルシステムを使います。

Design Choices

Design Choice 1: `paths` モジュールの配置場所をどこにするか

Options Considered:

1. packages/core/src/host/paths.ts に配置し、host/index.ts から再エクスポートする。
2. packages/core/src/config/paths.ts に config 専用として配置する。

Chosen Option: 1

Rationale: design.md §17 は OS 依存の設定ディレクトリ解決を担う paths モジュールを指定します。既存の共有インフラは host/ にあります。state.json や extensions/ など config 以外の core 状態も同じディレクトリを使うため（design.md §8.2/§4.1）、共有インフラである host/ に置く方が将来の再利用に合います。

Design Choice 2: ファイルシステムアクセスをどう注入するか

Options Considered:

1. read/watch を持つ狭い fs 依存を任意注入し、未指定時は node:fs を既定にする。
2. 実 node:fs をハードコードし、テストは実ファイルシステムのみで行う。

Chosen Option: 1

Rationale: design.md §11 は config が fs.watch を直接使うと記述します。テストでは決定論的な fake が必要です。document.ts の clock?: Clock 既定パターンに一致し、大半のテストを fake で高速・決定論的に実行できます。

💡 User Tips

Regenerate the plan with different choices with @coderabbitai <feedback>.

Implementation Steps

Phase 1: パス解決と JSONC パーサーの基盤

このフェーズは設定サービスが依存する 2 つの純粋ユーティリティを実装します。両方とも I/O を持たず、単体テストが容易です。

Task 1: `paths` モジュールを実装する

OS 依存の設定ディレクトリ解決を 1 か所に集約します。

• packages/core/src/host/ に paths.ts を新規作成する。
• POSIX では ~/.config/tecode/、Windows では %APPDATA%\tecode\ を解決する関数を提供する。
• ユーザー設定ファイルパス（settings.json、keybindings.json）と、ワークスペースパス（<workspace>/.tecode/settings.json）を組み立てるヘルパーを提供する。
• node:os / node:path / 環境変数で process.platform の分岐をこのモジュール内に閉じ込める。呼び出し側は分岐しない。
• host/index.ts から新しい関数と型を再エクスポートする。

Task 2: 寛容な JSONC パーサーを実装する

コメントと末尾カンマを許容し、エラー位置を報告するパーサーを実装します。

• packages/core/src/config/ に jsonc.ts を新規作成する。
• 行コメント（//）、ブロックコメント（/* */）、末尾カンマを除去してから JSON.parse に委譲する。
• 文字列リテラル内の // や , を誤って除去しないよう、文字列状態を追跡する。
• 解析失敗時は line/column を含むエラー情報を返す。呼び出し側が StatusSink に転送できる形にする。
• 成功時はパース済みオブジェクトを、失敗時はエラー位置を返す判別可能な結果型を返す（例外を公開境界で投げない方針に合わせる）。

🤖 Prompt for AI agents

このフェーズでは、設定サービスが依存する 2 つの独立した純粋ユーティリティを実装します。両方とも I/O を持たず、単体テストが容易な構造にします。

1. `paths` モジュールを実装してください。
- `packages/core/src/host/` に `paths.ts` を新規作成します。
- POSIX では `~/.config/tecode/`、Windows では `%APPDATA%\tecode\` を解決する関数を提供します。
-
ユーザー設定ファイルパス（`settings.json`、`keybindings.json`）と、ワークスペースパス（`<workspace>/.tecode/settings.json`）を組み立てるヘルパーを提供します。
- `process.platform` の分岐は `node:os` / `node:path` /
環境変数を使い、このモジュール内だけで完結させます。呼び出し側では分岐処理を書きません。
- `host/index.ts` から新しい関数と型を再エクスポートします。

2. 寛容な JSONC パーサーを実装してください。
- `packages/core/src/config/` に `jsonc.ts` を新規作成します。
- 行コメント（`//`）、ブロックコメント（`/* */`）、末尾カンマを除去してから `JSON.parse` に処理を委譲します。
- 文字列リテラル内の `//` や `,` を誤って除去しないよう、パース処理内で文字列状態を追跡します。
- 解析に失敗した場合は line/column を含むエラー情報を返し、呼び出し側が `StatusSink` に転送できる形式にします。
- 成功時はパース済みオブジェクトを返し、失敗時はエラー位置を返す判別可能な結果型を使います。公開境界では例外を投げない方針に従います。

Phase 2: 設定サービス本体

このフェーズはレイヤリング、スキーマレジストリ、get、監視、再読み込み、イベントを実装します。@tecode/api の ConfigNamespace を満たします。

Task 1: スキーマレジストリとレイヤーマージを実装する

defaults←user←workspace のマージと get(key) を実装します。

• packages/core/src/config/ に service.ts（または同等ファイル）を新規作成する。
• contributes.configuration（ConfigurationContribution.properties）を受け取り、各 ConfigurationPropertySchema.default から defaults レイヤーを構築するスキーマレジストリを実装する。
• defaults ← user settings.json ← workspace .tecode/settings.json の順でマージした統合ビューを構築する（後のレイヤーが優先）。
• ドット区切りキー（例 editor.tabSize）を統合ビューから解決する get<T>(key): T | undefined を実装する。
• スキーマ検証は MVP のベストエフォートとする。型不一致はログに記録するが読み取りは失敗させない。

Task 2: 監視・再読み込み・変更イベントを実装する

fs.watch による再読み込みと onDidChangeConfiguration 発火を実装します。

• createConfigService(deps) ファクトリを実装する。deps は必須の log: HostLog / sink: StatusSink と、任意注入の狭い fs 依存（read/watch、未指定時は node:fs/fs.watch を既定）を持つ。
• ユーザーの settings.json、keybindings.json、ワークスペースの .tecode/settings.json を監視する。パスは Phase 1 の paths モジュールで解決する。
• 変更時に該当ファイルを再パースし、統合ビューを再構築し、旧ビューと新ビューでキー差分を計算する。
• 変更キーがある場合のみ onDidChange を発火する。ConfigChangeEvent.affectsConfiguration(key) は指定キーとその子孫の変更を正しく判定する。
• イベント実装は keymap/context.ts のパターンに従う。Set<Listener>、反復前スナップショット、listener ごとの try/catch、二重 dispose 安全、を守る。
• パース失敗時は last-good 設定を保持し、StatusSink にエラー位置を報告する。統合ビューは更新しない。
• キーマップ再構築などの依存サービス通知はフック（コールバック）として公開する。実配線は後続タスクで行う。生の keybindings.json エントリはこのサービスが保持し、keymap モジュールへは構造化データとして渡す前提とする。

🤖 Prompt for AI agents

このフェーズでは、レイヤリング、スキーマレジストリ、`get`、監視、再読み込み、イベントを実装し、`@tecode/api` の
`ConfigNamespace` を満たします。

1. スキーマレジストリとレイヤーマージを実装してください。
- `packages/core/src/config/` に `service.ts`（または同等ファイル）を新規作成します。
- `contributes.configuration`（`ConfigurationContribution.properties`）を受け取り、各
`ConfigurationPropertySchema.default` から defaults レイヤーを構築するスキーマレジストリを実装します。
- defaults ← user `settings.json` ← workspace `.tecode/settings.json`
の順で統合ビューをマージします。後のレイヤーが前のレイヤーを上書きします。
- ドット区切りキー（例 `editor.tabSize`）を統合ビューから解決する `get<T>(key): T | undefined` を実装します。
- スキーマ検証は MVP のベストエフォートとします。型不一致はログに記録しますが、読み取り処理は失敗させません。

2. 監視・再読み込み・変更イベントを実装してください。
- `createConfigService(deps)` ファクトリを実装します。`deps` には必須の `log: HostLog` / `sink:
StatusSink` と、任意注入の狭い fs 依存（`read`/`watch`）を持たせます。fs 依存が未指定の場合は
`node:fs`/`fs.watch` を既定にします。
- ユーザーの `settings.json`、`keybindings.json`、ワークスペースの `.tecode/settings.json`
を監視します。各パスは Phase 1 の `paths` モジュールで解決します。
- ファイル変更時は該当ファイルを再パースし、統合ビューを再構築し、旧ビューと新ビューのキー差分を計算します。
- 変更キーが存在する場合だけ `onDidChange`
を発火します。`ConfigChangeEvent.affectsConfiguration(key)`
は指定キーとその子孫の変更を正しく判定するようにします。
- イベント実装は `keymap/context.ts` のパターンに従います。`Set<Listener>`
を使い、反復前にスナップショットを取り、listener ごとに try/catch を適用し、二重 dispose を安全に処理します。
- パースに失敗した場合は last-good 設定を保持し、`StatusSink` にエラー位置を報告します。この場合、統合ビューは更新しません。
- キーマップ再構築などの依存サービスへの通知は、フック（コールバック）として公開します。実際の配線は後続タスクで行います。生の
`keybindings.json` エントリはこのサービスが保持し、`keymap` モジュールへは構造化データとして渡す前提にします。

Phase 3: エクスポート統合とテスト

このフェーズは公開バレルを更新し、完了要件のテストを追加します。

Task 1: バレルエクスポートを更新する

config の実エクスポートをパッケージ公開面に組み込みます。

• packages/core/src/config/index.ts の CONFIG_PLACEHOLDER を削除し、createConfigService、ConfigService 型、Deps/オプション型、JSONC パース関数を再エクスポートする。
• packages/core/src/index.ts の export { CONFIG_PLACEHOLDER } from "./config/index"; を、他モジュール（commands/keymap/buffer）と同じスタイルの名前付きエクスポートブロックに置き換える。
• packages/core/src/index.test.ts の CONFIG_PLACEHOLDER 参照を、存在しなくなるため更新または削除する。

Task 2: 設定サービスのテストを追加する

完了要件を満たすテストを追加します。

• packages/core/src/config/ に jsonc.test.ts を作成する。行コメント、ブロックコメント、末尾カンマ、// を含む文字列、破損入力の line/column 報告を検証する。
• packages/core/src/config/ に service.test.ts を作成する。
• レイヤーマージをキー単位で検証する。workspace が user を上書きし、user が defaults を上書きする。
• fake fs/watcher を注入し、変更コールバックを同期的に発火して再読み込みをトリガーする。onDidChangeConfiguration が発火し、affectsConfiguration が正しいことを検証する。
• パースエラー時に last-good 設定が保持され、StatusSink に位置が報告されることを検証する。テストは registry.test.ts の createRecordingSink() 相当のローカルスタブを使う。
• 必要に応じて packages/api/src/layering.test.ts の temp ディレクトリ + try/finally + afterEach クリーンアップパターンに従い、実 fs.watch の統合テストを 1〜2 本追加する。長時間監視は setDefaultTimeout で既定タイムアウトを延長する。
• bun test と eslint . が通ることを確認する。

🤖 Prompt for AI agents

このフェーズでは、公開バレルを更新し、完了要件を満たすテストを追加します。

1. バレルエクスポートを更新してください。
- `packages/core/src/config/index.ts` の `CONFIG_PLACEHOLDER`
を削除し、`createConfigService`、`ConfigService` 型、`Deps`/オプション型、JSONC
パース関数を再エクスポートします。
- `packages/core/src/index.ts` の `export { CONFIG_PLACEHOLDER } from
"./config/index";`
を、他モジュール（`commands`/`keymap`/`buffer`）と同じスタイルの名前付きエクスポートブロックに置き換えます。
- `packages/core/src/index.test.ts` の `CONFIG_PLACEHOLDER`
参照は存在しなくなるため、更新または削除します。

2. 設定サービスのテストを追加してください。
- `packages/core/src/config/` に `jsonc.test.ts` を作成し、行コメント、ブロックコメント、末尾カンマ、`//`
を含む文字列、破損入力の line/column 報告を検証します。
- `packages/core/src/config/` に `service.test.ts` を作成します。
- レイヤーマージをキー単位で検証します。workspace が user を上書きし、user が defaults を上書きすることを確認します。
- fake fs/watcher を注入し、変更コールバックを同期的に発火して再読み込みをトリガーします。`onDidChangeConfiguration`
が発火し、`affectsConfiguration` が正しく動作することを検証します。
- パースエラー発生時に last-good 設定が保持され、`StatusSink` にエラー位置が報告されることを検証します。テストでは
`registry.test.ts` の `createRecordingSink()` 相当のローカルスタブを使います。
- 必要に応じて、`packages/api/src/layering.test.ts` の temp ディレクトリ + try/finally +
`afterEach` クリーンアップパターンに従い、実 `fs.watch` を使う統合テストを 1〜2 本追加します。長時間監視するテストでは
`setDefaultTimeout` で既定タイムアウトを延長します。
- `bun test` と `eslint .` が通ることを確認します。

Research

本リポジトリは Bun ベースの monorepo です。packages/api は公開型（ConfigNamespace、ConfigChangeEvent、ConfigurationContribution、ConfigurationPropertySchema、Disposable/Listener/Event）を定義します。

packages/core は各サブモジュール（commands、keymap、buffer、host、config）を持ちます。各モジュールは createXxx() ファクトリ関数と Deps 注入パターンで実装します。

イベントは keymap/context.ts の Set<Listener> + スナップショット反復 + try/catch パターンに従います。

host/errors.ts は HostLog と StatusSink を提供します。

config/index.ts と src/index.ts の該当行は現在 CONFIG_PLACEHOLDER のみです。

JSONC ライブラリは依存に存在しません。design.md §11/§15 はパーサーの手書きを明示します。

paths モジュールと fs 抽象はまだ存在しません。

---

🚀 Next Steps

🤖 All AI agent prompts combined

Task: 1

このフェーズでは、設定サービスが依存する 2 つの独立した純粋ユーティリティを実装します。両方とも I/O を持たず、単体テストが容易な構造にします。

1. `paths` モジュールを実装してください。
- `packages/core/src/host/` に `paths.ts` を新規作成します。
- POSIX では `~/.config/tecode/`、Windows では `%APPDATA%\tecode\` を解決する関数を提供します。
-
ユーザー設定ファイルパス（`settings.json`、`keybindings.json`）と、ワークスペースパス（`<workspace>/.tecode/settings.json`）を組み立てるヘルパーを提供します。
- `process.platform` の分岐は `node:os` / `node:path` /
環境変数を使い、このモジュール内だけで完結させます。呼び出し側では分岐処理を書きません。
- `host/index.ts` から新しい関数と型を再エクスポートします。

2. 寛容な JSONC パーサーを実装してください。
- `packages/core/src/config/` に `jsonc.ts` を新規作成します。
- 行コメント（`//`）、ブロックコメント（`/* */`）、末尾カンマを除去してから `JSON.parse` に処理を委譲します。
- 文字列リテラル内の `//` や `,` を誤って除去しないよう、パース処理内で文字列状態を追跡します。
- 解析に失敗した場合は line/column を含むエラー情報を返し、呼び出し側が `StatusSink` に転送できる形式にします。
- 成功時はパース済みオブジェクトを返し、失敗時はエラー位置を返す判別可能な結果型を使います。公開境界では例外を投げない方針に従います。
===============================================================================

Task: 2

このフェーズでは、レイヤリング、スキーマレジストリ、`get`、監視、再読み込み、イベントを実装し、`@tecode/api` の
`ConfigNamespace` を満たします。

1. スキーマレジストリとレイヤーマージを実装してください。
- `packages/core/src/config/` に `service.ts`（または同等ファイル）を新規作成します。
- `contributes.configuration`（`ConfigurationContribution.properties`）を受け取り、各
`ConfigurationPropertySchema.default` から defaults レイヤーを構築するスキーマレジストリを実装します。
- defaults ← user `settings.json` ← workspace `.tecode/settings.json`
の順で統合ビューをマージします。後のレイヤーが前のレイヤーを上書きします。
- ドット区切りキー（例 `editor.tabSize`）を統合ビューから解決する `get<T>(key): T | undefined` を実装します。
- スキーマ検証は MVP のベストエフォートとします。型不一致はログに記録しますが、読み取り処理は失敗させません。

2. 監視・再読み込み・変更イベントを実装してください。
- `createConfigService(deps)` ファクトリを実装します。`deps` には必須の `log: HostLog` / `sink:
StatusSink` と、任意注入の狭い fs 依存（`read`/`watch`）を持たせます。fs 依存が未指定の場合は
`node:fs`/`fs.watch` を既定にします。
- ユーザーの `settings.json`、`keybindings.json`、ワークスペースの `.tecode/settings.json`
を監視します。各パスは Phase 1 の `paths` モジュールで解決します。
- ファイル変更時は該当ファイルを再パースし、統合ビューを再構築し、旧ビューと新ビューのキー差分を計算します。
- 変更キーが存在する場合だけ `onDidChange`
を発火します。`ConfigChangeEvent.affectsConfiguration(key)`
は指定キーとその子孫の変更を正しく判定するようにします。
- イベント実装は `keymap/context.ts` のパターンに従います。`Set<Listener>`
を使い、反復前にスナップショットを取り、listener ごとに try/catch を適用し、二重 dispose を安全に処理します。
- パースに失敗した場合は last-good 設定を保持し、`StatusSink` にエラー位置を報告します。この場合、統合ビューは更新しません。
- キーマップ再構築などの依存サービスへの通知は、フック（コールバック）として公開します。実際の配線は後続タスクで行います。生の
`keybindings.json` エントリはこのサービスが保持し、`keymap` モジュールへは構造化データとして渡す前提にします。
===============================================================================

Task: 3

このフェーズでは、公開バレルを更新し、完了要件を満たすテストを追加します。

1. バレルエクスポートを更新してください。
- `packages/core/src/config/index.ts` の `CONFIG_PLACEHOLDER`
を削除し、`createConfigService`、`ConfigService` 型、`Deps`/オプション型、JSONC
パース関数を再エクスポートします。
- `packages/core/src/index.ts` の `export { CONFIG_PLACEHOLDER } from
"./config/index";`
を、他モジュール（`commands`/`keymap`/`buffer`）と同じスタイルの名前付きエクスポートブロックに置き換えます。
- `packages/core/src/index.test.ts` の `CONFIG_PLACEHOLDER`
参照は存在しなくなるため、更新または削除します。

2. 設定サービスのテストを追加してください。
- `packages/core/src/config/` に `jsonc.test.ts` を作成し、行コメント、ブロックコメント、末尾カンマ、`//`
を含む文字列、破損入力の line/column 報告を検証します。
- `packages/core/src/config/` に `service.test.ts` を作成します。
- レイヤーマージをキー単位で検証します。workspace が user を上書きし、user が defaults を上書きすることを確認します。
- fake fs/watcher を注入し、変更コールバックを同期的に発火して再読み込みをトリガーします。`onDidChangeConfiguration`
が発火し、`affectsConfiguration` が正しく動作することを検証します。
- パースエラー発生時に last-good 設定が保持され、`StatusSink` にエラー位置が報告されることを検証します。テストでは
`registry.test.ts` の `createRecordingSink()` 相当のローカルスタブを使います。
- 必要に応じて、`packages/api/src/layering.test.ts` の temp ディレクトリ + try/finally +
`afterEach` クリーンアップパターンに従い、実 `fs.watch` を使う統合テストを 1〜2 本追加します。長時間監視するテストでは
`setDefaultTimeout` で既定タイムアウトを延長します。
- `bun test` と `eslint .` が通ることを確認します。

💡 Iterate on the plan with: `@coderabbitai` <feedback>

Example Feedback
- `@coderabbitai` You can skip phase 3. Add a simple unit test case for phase 2.
- `@coderabbitai` For design choice 1 go ahead with option 3 and replan.

---