refactor(npm): drive the dispatcher mux from a route table (part 3/4) (S09 Enforcement plan: 13/20)

Split into 4 stacked MRs to keep each part within the review size target (~800 reviewable LoC ideal). Each part targets the previous one (part 1 targets main); the stack is reviewed and merged bottom-up.

Part 3 of 4 of the S09 (authorization) enforcement plan — Step 13: npm wiring and route-table parity. Spec: S09 (authorization).

📦 What this part does

Rebuilds the npm dispatcher's mux registration over a single-source routeTable and exports a read-only RouteTable() view of it. The registration set is byte-identical to the previous hand-written mux.Handle calls — a behavior-preserving refactor whose point is making the table reflectable for the parity tests.

Two of the three parity directions land here, in cmd/artifact-registry/wire_npm_authz_test.go:

  • every (route, method) pair the spec's npm table names is served by the real dispatcher mux (not a bare-mux miss, and not an auto-405 through a sibling method), and
  • the registered and spec-named (method, route) sets are exactly equal.

The third direction — driving the real authz chain and asserting each route maps to the spec's action — needs withNpmAuthz and lands in part 4, reusing this part's oracle and helpers.

📏 Size

550 reviewable LoC, past the 500 guideline: the production diff is internal/format/npm/handler.go (+174/−55); the remaining ~320 added lines are the tests pinning the table (route-table/mux parity, buildMux construction guards, and the two parity directions above). Splitting the tests from the refactor they pin would leave the refactor unverified in its own MR.

📚 Stacked MRs (review/merge bottom-up)

Related to #855 (closed)

Edited by David Fernandez

Merge request reports

Loading
Loading