fcbe2f04f9
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>
12 lines
332 B
Text
12 lines
332 B
Text
go 1.24.0
|
|
|
|
// Shared Go code (internal/, libs/) lives in the root github.com/jobs-scraper
|
|
// module rather than in per-package modules. Only deployable units — the API,
|
|
// the scrapers, the cron app — get their own module.
|
|
use (
|
|
.
|
|
./apps/cron-analyzer
|
|
./services/api
|
|
./services/scraper-google
|
|
./services/scraper-linkedin
|
|
)
|