Skip to content

tracking: one home for each rule and one responsibility per file #1096

Open
7 of 11 issues completed
Open

Description

@OmarAlJarrah

The goal and context come first, then the ordered plan. Each step is a sub-issue, and the blocked-by relations are set on the issues themselves. Steps that #976 already tracks are named here and stay its sub-issues.

End goal

A contributor finds a rule in one place, in a file named for what it does, and two copies of a rule can no longer disagree. Done means all of:

  • every rule below that is written more than once has one definition, and the defects its copies caused are closed;
  • every production file in pass and compilers/openapi holds one responsibility, and a file holding one or two functions is fine;
  • the compiler's root package holds its public face and nothing else;
  • no package re-exports another package's call under a second name.

Context

Measured at ff8330ba.

Ordering

  1. Behaviour changes that close defects come before moves.
  2. Within a package, semantic work already in flight goes first. A move is scripted (the go/ast mover refactor(compilers/openapi): split operations.go and load.go #1076 used) and re-run on the new code rather than rebased across it.
  3. Moves land one pull request per package. A move within a package is proved by byte-identical declarations and no golden change. A move across packages is proved by unchanged goldens, harness sweep and diagnostics.
  4. An open pull request holds back the moves of its files only while it is moving. fix(compilers/openapi): flatten a nested inline allOf #998 holds openapi: split content.go by construct #1059 and openapi: split schema lowering into one file per construct #1060. That is stated in prose, since a pull request cannot be a dependency target.

Plan

1. One home for each rule (changes behaviour)

2. One responsibility per file (moves)

3. Small

Out of scope

  • Look-alikes kept apart on purpose:
    • ir's subtype and exposure definitions beside the irfacts indexes over them (ir-design §4.9);
    • pass.Validate beside irverify, which report through separate channels;
    • the URI check in oas/format.go beside the one in merge/admits.go, which answer different questions;
    • the per-package copies of test helpers under compilers/openapi, which openapitest's allowlist forces;
    • the conformance goldens beside each conformance case's focused assertion (conformanceCases).
  • Bundling lowering.Ctx, *compile.Types, the anchor memo and depth into one struct, which openapi: the $dynamicAnchor memo is a parameter of 72 functions and is read by two #982 rules out.
  • A cohesion check in CI. The grouping above flags files that are fine, and openapi: give each lowering construct its own file #1062 rules out new checks.

Done check

Priority: P3, the tier of its highest open steps (#980 and #981, which #976 also tracks; #813).

Activity

  1. added
    type:choreRefactor or cleanup, no behavior change
    priority:P3Later emitters, M4 and up, 3.2-only, streaming, webhooks, rare constructs
    on Oct 22, 2026
  2. OmarAlJarrah commented on Oct 23, 2026

    @OmarAlJarrah
    MemberAuthor

    #1104 moves servers.go out of the root as well, into internal/document beside the rest of the document-level lowering, so the done check above now lists doc.go, openapi.go, options.go and detect.go.

    Keeping it in the root, as #1055 and #1091 proposed, would have meant handing the server lowering to document.Lower as a function parameter, only because of where the file sat. It would not help path-item and operation servers (#285) either: internal/operation can never import the root, but it could import internal/document, or the lowering could move to a package both walks reach. The change that gives those servers a field decides which.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    priority:P3Later emitters, M4 and up, 3.2-only, streaming, webhooks, rare constructstype:choreRefactor or cleanup, no behavior change

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions