`config.ResolvedConfig` has no `json:` struct tags, so `encoding/json` emits Go-PascalCase field names (`DevcontainerID`, `Source`, `ContainerWorkspaceFolder`, …).
That's fine when the library is embedded, but it makes `devcontainer read-configuration` output awkward for anyone piping into `jq` — and it's not a stable shape (a struct field rename silently changes the JSON key).
Add explicit `json:` tags using camelCase / spec-style names where the spec defines them (`workspaceFolder`, `remoteUser`, `containerEnv`, etc.), and our own conventions for fields not in the spec (`devcontainerId`, `source`, `warnings`).
Benefits:
- Stable CLI output shape, usable with `jq`
- Spec-aligned where it makes sense
- Cheaper for any future programmatic consumer
Worth verifying nothing else in the repo (tests, examples) depends on the current PascalCase JSON.
`config.ResolvedConfig` has no `json:` struct tags, so `encoding/json` emits Go-PascalCase field names (`DevcontainerID`, `Source`, `ContainerWorkspaceFolder`, …).
That's fine when the library is embedded, but it makes `devcontainer read-configuration` output awkward for anyone piping into `jq` — and it's not a stable shape (a struct field rename silently changes the JSON key).
Add explicit `json:` tags using camelCase / spec-style names where the spec defines them (`workspaceFolder`, `remoteUser`, `containerEnv`, etc.), and our own conventions for fields not in the spec (`devcontainerId`, `source`, `warnings`).
Benefits:
Worth verifying nothing else in the repo (tests, examples) depends on the current PascalCase JSON.