Skip to content

feat: shorten CLI to ocs and add opencode.jsonc support - #17

Merged
lleontor705 merged 1 commit into
masterfrom
feat/ocs-cli-jsonc
Aug 9, 2026
Merged

lleontor705 merged 1 commit into
masterfrom
feat/ocs-cli-jsonc

Conversation

@lleontor705

Copy link
Copy Markdown
Owner

Summary

Two coordinated changes on this branch.

A — Support opencode.jsonc + opencode.json

  • Added dependency github.com/tailscale/hujson; LoadConfig now standardizes JSONC (comments // + /* */, trailing commas) before unmarshalling. Plain .json files pass through unchanged.
  • GetConfigPath now probes opencode.jsonc → opencode.json (first existing wins; default-create is .json when neither exists).
  • Backups derive their base name from the actual config path: .json → opencode.json.backup.* (backward compatible), .jsonc → opencode.jsonc.backup.*.
  • TUI save-confirm dialog renders the real config basename.
  • Accepted limitation (documented): saving re-emits standard JSON, so .jsonc comments are not preserved on write.

B — Shorten the CLI binary name to ocs

  • New internal/appname package (const Name = "ocs") as the single source of truth for main.go, the TUI banner, error strings, and integration-test markers.
  • Updated Makefile, .goreleaser.yaml, .gitignore, main.go, internal/tui/*, README, docs/INSTALLATION.md, CONTRIBUTING.md, logo inner text, package.json.
  • Module path in go.mod is unchanged (github.com/lleontor705/opencode-model-selector) — only the compiled binary name changed.

Verification

  • go vet ./... clean
  • go test ./... all green (5 packages, 0 failures), incl. new tests: probe-order precedence, JSONC-equals-JSON load, jsonc backup basename, jsonc cleanup glob scope, jsonc fixture standardization
  • go build produces ocs / ocs.exe; headless modes run and the FlagSet is titled ocs
  • Grep gate: 0 remaining opencode-model-selector command invocations (residual matches are all sanctioned: module path, repo URLs, logo filename, project-title prose, .gitignore legacy entry)
  • End-to-end: a commented opencode.jsonc loads via --config without parse errors

Known non-blocking note

hujson rejects a leading UTF-8 BOM (pre-existing library behavior). Optional future hardening: strip \xef\xbb\xbf in LoadConfig.

Branch: feat/ocs-cli-jsonc (commit 8d010c4)

Part A - opencode.jsonc support:
- Add JSONC loading via github.com/tailscale/hujson. The new decodeConfig
  helper standardizes comments (// and /* */) and trailing commas to
  standard JSON before unmarshalling, so valid .json configs are unaffected.
- LoadConfig now accepts both opencode.json and opencode.jsonc.
- GetConfigPath probes opencode.jsonc first, then opencode.json (jsonc > json
  precedence). If neither exists it defaults to the conventional opencode.json
  path so first-time Save writes standard JSON.
- Backup naming is now derived dynamically from filepath.Base(configPath), so
  opencode.jsonc produces opencode.jsonc.backup.* while legacy opencode.json
  behavior is byte-for-byte preserved.
- Documented limitation: .jsonc comments are supported on LOAD but are NOT
  preserved when the tool saves the config (it writes standard JSON).
- Tests: jsonc fixture, load-equality vs json fixture, hermetic GetConfigPath
  probe-order table, jsonc-aware backup naming/scope tests, fixture validator.

Part B - binary renamed to ocs:
- Binary/program name centralized in internal/appname (const Name = ocs).
- FlagSet (main.go), TUI header banner, and goreleaser/Makefile use appname.
- Module path github.com/lleontor705/opencode-model-selector is UNCHANGED;
  only the installed binary is named ocs.

Dependency note: hujson has no tagged release, so it is pinned to a
pseudo-version (v0.0.0-20260727124030-b80ff77dac4f). go mod tidy also
promoted charmbracelet/x/ansi from indirect to direct, reflecting the
pre-existing direct import in internal/tui/header.go.
@lleontor705
lleontor705 merged commit 1b6d360 into master Aug 9, 2026
3 of 5 checks passed
@lleontor705
lleontor705 deleted the feat/ocs-cli-jsonc branch August 9, 2026 22:25
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