internal/ and libs/ were split into 9 single-package Go modules, held
together by 22 replace directives across 7 go.mod files. The module
boundaries bought nothing: internal/dto, internal/browser and
internal/migrations were already plain packages in the root module and
worked fine.
Delete the 9 go.mod/go.sum pairs so those packages belong to the root
github.com/jobs-scraper module. Import paths are unchanged --
github.com/jobs-scraper/internal/domain resolves identically whether it
is its own module or a package inside the root module -- so no .go file
is touched by this commit.
Each deployable module now needs one require + one replace on the root
module instead of four to six:
go.work entries: 14 -> 5
replace directives: 22 -> 4
go.mod files: 14 -> 5
Dependency versions are deliberately held at their previous pins. A bare
go mod tidy resolved several to latest once the per-package constraints
were gone (lib/pq 1.10.9 -> 1.12.3, amqp091-go 1.10.0 -> 1.13.0,
migrate 4.19.0 -> 4.19.1, go-openai 1.41.2 -> 1.42.0, genai
1.39.0 -> 1.66.0); all five are pinned back, since a structural refactor
should not move dependency versions.
Side effect worth noting: `go build ./...` at the repo root previously
matched only 2 packages, because everything else sat behind a module
boundary. It now covers all 12 shared packages, so the build and vet
steps in .forgejo/workflows/ actually exercise the shared code.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
fcbe2f04f9