Consider making BSON support optional to avoid introducing the MongoDB driver as a core dependency

[acexy]

I noticed that Gin 1.12 introduced BSON binding/render support by depending on the MongoDB Go Driver (go.mongodb.org/mongo-driver/v2).

While BSON support itself is a useful feature, I'm wondering whether it should live in the core package.

Concern

Most Gin applications:

• don't use MongoDB
• don't use BSON
• only use JSON/XML/Form binding

However, all users now indirectly depend on the MongoDB driver.

Although Go's linker removes unused code from the final binary, introducing a new core dependency still has some costs:

• larger dependency graph
• additional dependency maintenance
• vulnerability/license scanning
• version compatibility concerns
• less minimal core

Suggestion

Would it make sense to move BSON support into an optional package (for example, gin-contrib/bson)?

Something like:

• gin (core)
• gin-contrib/bson

Users who need BSON can explicitly opt in, while keeping the core dependency tree smaller.

Is there a particular reason why BSON support was chosen to be included directly in Gin instead of as an optional extension?

I'd be interested in hearing the design considerations.

[dlanov]

Your technical analysis is spot on — the dependency concern is real and your suggestion aligns with Gin's existing extensibility pattern.

Your concerns validated

You're correct on all points:

• go.sum bloat — Go modules pull all transitive dependencies into go.sum regardless of whether your code uses them. go.mongodb.org/mongo-driver/v2 brings in a meaningful subtree (github.com/xdg-go/scram, github.com/youmark/pkcs8, golang.org/x/crypto, etc.)
• Vulnerability/license scanning — tools like govulncheck, nancy, Trivy, and Dependabot scan go.sum entries, not the compiled binary. An unused transitive dep with a CVE will still flag in your pipeline
• Dead code elimination — the Go linker does strip unused symbols from the final binary, so binary size isn't materially affected. But that's only one of the costs you listed and arguably the least impactful

The existing pattern supports your suggestion

Gin already has exactly this separation for other optional bindings via the gin-contrib org:

• gin-contrib/cors
• gin-contrib/sessions
• gin-contrib/cache
• gin-contrib/gzip

BSON binding/rendering fits naturally as gin-contrib/bson. The integration surface is small, it's just implementing binding.Binding and render.Render interfaces. So extracting it wouldn't require any changes to Gin's core API.

The specific change that introduced this

PR #4705 added BSON support in the 1.12.0 release. Looking at that PR, the BSON binding and render are self-contained files (binding/bson.go and render/bson.go) with no deep coupling to Gin internals — further confirming that extraction to gin-contrib/bson would
be straightforward.

Precedent from other frameworks

Echo (another popular Go HTTP framework) keeps its core dependency tree minimal and pushes protocol-specific bindings into middleware packages. The Go standard library itself follows this philosophy: encoding/json is in stdlib, encoding/xml is in stdlib, but MongoDB-specific wire formats are not.
BSON is a domain-specific encoding tied to a particular database ecosystem, not a general-purpose web format like JSON/XML/YAML/TOML.