Reject import-mapping keys that are JSON pointers#2461
Conversation
Closes: #2459 import-mapping keys are the paths of $ref'd documents — a relative file path or a URL — but users occasionally write a JSON pointer like "#/components/schemas" expecting internal references to be remapped to another Go package (seen in #2078). Such an entry can never match anything, since same-document references always resolve to the package being generated, so the user just sees unresolved types with no hint of the misconfiguration. Configuration validation now rejects keys starting with "#" with an error explaining what keys must be and pointing at the import-mapping examples. This is an error rather than a warning because warnings are emitted to stderr and easily lost when generation output goes to stdout, and there is no legitimate configuration this rejects. The README's Import Mapping section gains a note stating the same up front: keys are document paths, internal refs cannot be remapped, and schemas wanted in a separate package should be split into their own spec file. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Greptile SummaryThis PR adds a validation guard in
Confidence Score: 5/5Safe to merge — the change adds a new hard error only for configurations that were previously silently broken anyway, and no struct fields or generated output are touched. The validation change is surgical: it only affects Validate(), not any struct definitions or code-generation paths. No existing valid configuration is rejected — a key starting with "#" could never have produced a successful mapping before this change, so real users are unaffected. The unit test covers both the failure path and multiple flavors of valid key. No files require special attention.
|
| Filename | Overview |
|---|---|
| pkg/codegen/configuration.go | Adds validation in Validate() to reject import-mapping keys that start with "#"; no struct fields were changed, so no JSON schema update is needed |
| pkg/codegen/configuration_test.go | New unit test covering both the rejection of a JSON-pointer key and acceptance of valid file-path/URL keys |
| README.md | Adds a NOTE callout to the Import Mapping section explaining that keys must be document paths, not JSON pointers |
Reviews (1): Last reviewed commit: "Reject import-mapping keys that are JSON..." | Re-trigger Greptile
Closes: #2459
import-mapping keys are the paths of $ref'd documents — a relative file path or a URL — but users occasionally write a JSON pointer like "#/components/schemas" expecting internal references to be remapped to another Go package (seen in #2078). Such an entry can never match anything, since same-document references always resolve to the package being generated, so the user just sees unresolved types with no hint of the misconfiguration.
Configuration validation now rejects keys starting with "#" with an error explaining what keys must be and pointing at the import-mapping examples. This is an error rather than a warning because warnings are emitted to stderr and easily lost when generation output goes to stdout, and there is no legitimate configuration this rejects.
The README's Import Mapping section gains a note stating the same up front: keys are document paths, internal refs cannot be remapped, and schemas wanted in a separate package should be split into their own spec file.