feat(ramen): write first-run config to global, not project-local#98
feat(ramen): write first-run config to global, not project-local#98vigneshshanmugam wants to merge 2 commits intodevfrom
Conversation
First-run setup, profile switches, and reset now write provider, model,
mcp.eab, and permission.eab_* to ~/.config/elastic-ramen/elastic_ramen.json
instead of <cwd>/elastic_ramen.json. Users no longer redo setup in every
directory, and per-project config bloat goes away. Project-local
elastic_ramen.json still wins via merge precedence for users who want
per-project overrides.
Stale provider/model in any project-local elastic_ramen.json{,c} or
.elastic-ramen/elastic_ramen.json{,c} is stripped on next save/switch
to keep global as the single source of truth. .jsonc files are edited
through jsonc-parser so comments and untouched keys survive intact.
Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]>
Two pre-existing typecheck errors blocked the pre-push hook:
- model-label.ts ProviderEntry.models lacked api?: { id?: string },
failing the M extends { api?: { id?: string } } constraint of
KibanaGateway.resolveKibanaModel.
- provider.ts:1247 reassigned info from KibanaGateway.resolveKibanaModel
(which returns M | undefined) to a let-binding inferred as Model.
Annotate info as Model | undefined so the union is acceptable.
Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]>
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
There was a problem hiding this comment.
Left one inline comment for a correctness issue that should be addressed before merge.
What is this? | From workflow: PR Review
Give us feedback! React with 🚀 if perfect, 👍 if helpful, 👎 if not.
| }) | ||
| if (text === undefined) return undefined | ||
| if (!text.trim()) return {} | ||
| const data = parseJsonc(text) |
There was a problem hiding this comment.
readConfigFile says it "throws on malformed content", but parseJsonc(text) is called without an errors array, so syntax errors are not surfaced here. That means malformed config can be treated as an object and then rewritten by patchConfigFile, which can silently drop unrelated user keys.
Concrete scenario: a user has a global elastic_ramen.jsonc with a trailing syntax mistake in an unrelated section; a later save/setCurrent runs writeGlobalConfig, reads via this function, and writes back patched content instead of failing fast.
Please parse with an errors array (like Config.parseConfig) and throw when errors.length > 0 before proceeding with patch/write.
flash1293
left a comment
flash1293
left a comment
There was a problem hiding this comment.
LGTM, works as expected
2 participants
What does this PR do?
Today, the first time a user starts ramen in any directory, the setup dialog writes
provider,model,mcp.eab, andpermission.eab_*into<cwd>/elastic_ramen.json. Users running ramen across many directories had to redo setup each time, and ended up with staleelastic_ramen.jsonfiles polluting every project.This change moves first-run setup, profile switches, and
resetto write the same fields to~/.config/elastic-ramen/elastic_ramen.json(global). The config loader already supported a global file at the same precedence layer; nothing in the merge order changes.Why it's safe:
~/.config/elastic/config.yaml) are already global.elastic_ramen.jsonstill wins via merge precedence, so a user who explicitly setsprovider/modelin a project file keeps that override.Migration:
providerandmodelare stripped from any leftover project-localelastic_ramen.json{,c}and.elastic-ramen/elastic_ramen.json{,c}so global stays the single source of truth..jsoncfiles are edited via `jsonc-parser`'s `modify` + `applyEdits` so user comments and untouched keys survive intact.Other changes:
Checklist
🤖 Generated with Claude Code