GORM — Dependencies#

Module info#

Module: gorm.io/gorm
Go version: 1.18
Direct dependencies: 3 (required) + 2 (indirect, test-only)
Indirect dependencies: 5 total packages in go.sum (10 lines — each package appears twice for hash + go.mod hash)

Dependency categories#

Core infrastructure#

None. GORM uses no external logging framework, CLI library, or configuration system. Its own logger/ package implements a minimal logger interface backed entirely by stdlib (log, fmt, os).

Networking/HTTP#

None. GORM is a library, not a server. All I/O goes through database/sql.

Data/Storage#

github.com/jinzhu/inflection v1.0.0 — English-language pluralization / singularization of words. Used in schema/naming.go and schema/relationship.go to derive conventional table names from struct names (e.g., User → users, Category → categories). Authored by Jinzhu (the GORM author), so effectively a first-party dependency.
github.com/jinzhu/now v1.1.5 — Time parsing utilities for expressions like "yesterday", "last month", beginning/end of day/week/month/year. Used in schema/field.go for default time value parsing and in soft_delete.go for time-based soft-delete queries. Also authored by Jinzhu.
golang.org/x/text v0.20.0 — Specifically golang.org/x/text/cases and golang.org/x/text/language, used in schema/naming.go and schema/relationship.go for Unicode-aware title-casing when converting struct field names to column names. Necessary for correct internationalized name handling beyond ASCII.

Testing (indirect only)#

gorm.io/driver/sqlite v1.6.0 (indirect) — The SQLite dialect for GORM, used only in test files (tests/). Not required at compile time for the core library.
github.com/mattn/go-sqlite3 v1.14.22 (indirect) — CGo-based SQLite3 driver, pulled in transitively by the sqlite dialect. Only present because of the test suite. Requires CGo, which is otherwise not a dependency of the core library.

Other#

None.

Stdlib reliance#

GORM is extremely stdlib-heavy. Analysis of non-test source files shows:

Package	Import count	Role
`reflect`	30	Schema introspection — the entire `schema/` package is built on reflection to map structs to columns
`strings`	23	SQL clause building, name normalization
`fmt`	22	Error formatting, SQL generation
`database/sql`	16	Core database abstraction — all query execution goes through this
`context`	16	Propagated through all DB operations
`time`	14	Timestamp handling, soft-delete
`sync`	10	Cache synchronization (`sync.Map` in schema cache, `sync.Mutex` in stmt_store)
`database/sql/driver`	10	Driver value interfaces for type mapping
`errors`	9	Error sentinel creation and wrapping
`sort`	8	Sorting clause expressions
`regexp`	7	SQL pattern matching in naming conventions
`strconv`	6	String/int conversion for SQL values
`go/ast`	3	Struct tag parsing in the schema package
`encoding/json`	2	JSON serialization for data types

reflect and database/sql are the load-bearing stdlib packages — GORM could not function without them. The project deliberately avoids any abstraction over database/sql since that package is itself a well-designed abstraction layer.

Shared dependencies#

Within the 50-project analysis set, golang.org/x/text is a common shared dependency (also seen in projects that need Unicode handling). database/sql as a stdlib package is used across all database-touching projects. The jinzhu/* dependencies are GORM-specific and unlikely to appear elsewhere. No shared framework dependencies (no Viper, cobra, zap, testify, etc.) exist in GORM’s dependency graph.

Vendoring#

No vendor directory. GORM relies on the Go module proxy and the standard module cache. This is appropriate for a library: vendoring would force the library’s choices on downstream consumers. The extremely short go.sum (10 lines) makes the module resolution graph trivially auditable.

Notable dependency decisions#

Radical minimalism by design. Three direct dependencies for a full-featured ORM is an architectural statement. Compare to ORMs in other languages that pull in dozens of libraries. GORM achieves this by offloading all database-specific logic to separate gorm.io/driver/* packages, and using stdlib’s database/sql and reflect instead of code generation or external query builders.
Self-authored dependencies. Both jinzhu/inflection and jinzhu/now were written by the GORM author (Jinzhu Wei). This eliminates external maintenance risk for functionality specific to GORM’s needs — the author controls both sides of the dependency. It’s a pattern more common in mature solo/small-team open source projects.
No test framework. GORM uses only stdlib testing — no testify, gomock, or ginkgo. This keeps the test dependency footprint at zero beyond the SQLite driver required for actual database operations.
golang.org/x/text over custom Unicode logic. Using the official extended standard library for language-sensitive casing is the correct call for internationalized identifiers. The alternative (ASCII-only strings.ToTitle) would silently break for non-ASCII struct field names.
No code generation. Many ORMs (XORM, ent, sqlc) use code generation to avoid runtime reflection. GORM explicitly chooses runtime reflection, accepting the performance cost in exchange for zero build-step overhead for library consumers. The dependency profile reflects this: no go generate toolchain deps.