Shaping the output

The same annotated Go can render into the spec in more than one shape. A handful of codescan.Options let you choose: should an alias become a $ref or expand inline? Should a field’s description survive next to a $ref? Should pointer fields be marked nullable?

Each guide here is task-oriented — “I want the output to look like this” — and shows the same input rendered both ways, as before/after golden output the example tests verify.

• Scoping the scan

  Limit what gets scanned — package patterns, working directory, include/exclude filters, tag filters, and dependency handling.
• When the scanner emits a type

  codescan never invents definitions — a type appears only when it is reachable or registered. Understand reachability and swagger:model so nothing goes missing or appears unexpectedly.
• Nullable pointers

  Mark pointer-typed fields as nullable with x-nullable, via SetXNullableForPointers.
• Vendor extensions

  Control the x-go-* vendor extensions codescan emits, or suppress them with SkipExtensions.
• Descriptions beside a $ref

  Keep a field’s description when its type resolves to a $ref, by wrapping the reference in a single-arm allOf (DescWithRef).
• Alias rendering

  Choose how Go type aliases render — dissolved to their target, or exposed as a first-class $ref via swagger:model, with RefAliases / TransparentAliases.
• Overlaying a spec

  Merge scanned discoveries on top of an existing Swagger document with InputSpec.
• Build tags

  Scan source guarded by Go build constraints by passing build tags to the scanner.

For the field-by-field meaning of each option, see the Options godoc.