fix(golang): always emit consolidated imports regardless of leadingComments

[schani]

Bug

Passing leadingComments (even []) to the quicktype-core API's quicktype() function for Go output produced invalid, non-compiling Go code. For example, a schema with a date-time field would emit import "time" in the middle of the file, between two struct definitions — Go requires all import declarations to precede any other top-level declarations.

Root cause

In GolangRenderer.ts, emitSourceStructure (single-file mode) and emitTopLevel (multi-file mode) both gated their entire header block — including the consolidated top-of-file import collection (emitPackageDefinitons(false, collectAllImports())) — behind this.leadingComments === undefined. Passing any leadingComments value (including []) skipped that whole block, so the consolidated import block was never emitted. A later, per-class emission of import "time" (for time.Time fields) is normally deduplicated against that header block via emitLineOnce, but with no header block to dedupe against, the bare import "time" landed wherever the class happened to be emitted in the file — i.e. mid-file.

Other language renderers (CSharpRenderer, JavaRenderer, SwiftRenderer, RustRenderer, KotlinRenderer, etc.) use a different, correct pattern: leadingComments, when set, only replaces the default generated-file header comment; it does not suppress unrelated output like import blocks. GolangRenderer was the outlier that conflated the two.

Fix

• emitTopLevel (multi-file) and emitSourceStructure (single-file) now always emit the import/package block; leadingComments, when provided, replaces the default header comment text instead of skipping the whole block, matching the pattern used elsewhere in the codebase.
• While fixing this, also corrected a related latent issue in multi-file output: emitTopLevel now collects and emits the actual imports needed by the top-level type (via collectClassImports/collectUnionImports) instead of emitting no imports at all for the top-level file's own type.

Test coverage

Added LeadingCommentsGoFixture (fixture id schema-golang-leading-comments) in test/fixtures.ts, which is registered in allFixtures. Since leadingComments is a quicktype-core API option not exposed via the CLI, this fixture drives quicktype-core's quicktype()/quicktypeMultiFile() directly (rather than through the CLI-based fixture path) using test/inputs/schema/date-time.schema, with leadingComments: [] set, and verifies both single-file and multi-file Go output actually compiles and runs correctly (go test/go run via the existing Go fixture driver).

This fixture reproduces the bug on unfixed code (imports must appear before other declarations) and passes after the fix.

Verification performed locally

• npm run build passes.
• npm run test:unit — 163 tests passed.
• FIXTURE=schema-golang-leading-comments QUICKTEST=true script/test — passes (new fixture, compiles and runs generated Go for both single- and multi-file output).
• FIXTURE=schema-golang QUICKTEST=true script/test — passes (no regression in existing Go schema fixtures).
• FIXTURE=golang QUICKTEST=true script/test — passes for the vast majority of samples; a few samples (bitcoin-block.json, getting-started.json, uuids.json) hit an unrelated, environment-level flake (go: cannot determine current directory: getwd: no such file or directory) from running many go run processes across 16 parallel workers in this sandbox. Re-running each of those three samples individually with go run succeeded cleanly (exit 0, correct output), confirming this is sandbox/concurrency flakiness, not a code regression. CI will validate the full fixture matrix.
• Manually re-ran the exact repro from the issue (and from the maintainer triage comment) against the built quicktype-core package before and after the fix, confirming the import "time" now lands in the consolidated top-of-file import block instead of mid-file.

Fixes #2670

🤖 Generated with Claude Code