chore: go mod tidy + package godoc (no breaking changes) - #29
Merged
Conversation
Move bsm/redislock and redis/go-redis from indirect to direct requires (they are imported directly by hdlm/redislock) and complete go.sum. No version changes and the go directive stays at 1.18, so this is not a consumer-facing change. https://claude.ai/code/session_01J46cm6MaKsVpw1YSXGg8eq
Every library package now has a package comment (in a doc.go) describing its purpose, so godoc / pkg.go.dev render a useful overview. Documentation only; no API or behavior change. https://claude.ai/code/session_01J46cm6MaKsVpw1YSXGg8eq
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Non-breaking dependency hygiene + the godoc half of the docs workstream. No API or behavior changes, no runtime dependency version bumps,
godirective stays at 1.18.go mod tidy— movesbsm/redislockandredis/go-redis/v9from// indirectto direct requires (they're imported directly byhdlm/redislock) and completesgo.sum. No version changes → not consumer-facing.doc.gopackage comment to every library package that lacked one (roothexa,db/mgmadapter,hdlm/mongolock,hdlm/redislock,hexamask,hexatranslator,hlog,hlog/logdriver,htel,hurl,lg,probe), so godoc / pkg.go.dev show a useful overview.Test plan
gofmt -l .clean,go vet ./...,go build ./...golangci-lint run ./...(v1.64.8) → EXIT=0 (passes the new hard gate)go test ./...→ all passYou asked to bump otel/mongo-driver/zap/go-i18n, but flagged no breaking changes. Those bumps are consumer-facing because hexa re-exports the libraries' types in its public API:
htelexposesmetric.MeterProvider, and otel'smetricpackage had a v0.x → v1.x redesign. You can't bump otel core without pulling the new, incompatible metric API → anyone implementing/passing those types breaks. This is the "crucial but breaking" one — I'd defer it to a coordinated v2 (/v2module path).So I did not bump any runtime dependency here. Tell me how you'd like to proceed (defer otel to v2; do the within-major mongo/zap/i18n bumps as an accepted transitive upgrade; or hold).
🤖 Generated with Claude Code
Generated by Claude Code