Buffalo — Dependencies#

Module info#

Module: github.com/gobuffalo/buffalo
Go version: 1.25.0
Direct dependencies: 18
Indirect dependencies: 23 listed in go.mod indirect block; go.sum has 112 lines (~56 unique modules)

Dependency categories#

Core infrastructure#

github.com/spf13/cobra v1.6.1 — CLI framework powering the buffalo command and all its subcommands (dev, build, generate, etc.)
github.com/joho/godotenv v1.4.0 — .env file loading; Buffalo uses this to inject development configuration from .env at startup, following the 12-factor pattern
github.com/gobuffalo/logger/v2 v2.0.1 — structured logging abstraction; wraps logrus internally, exposing a Logger interface so apps can swap backends
github.com/gobuffalo/refresh v1.13.3 — file watcher that triggers live-reload during buffalo dev; key for the Rails-style developer experience
github.com/BurntSushi/toml v1.2.1 — TOML parsing for database.toml and other Buffalo config files; a holdover from the era when Go tooling favoured TOML

Networking/HTTP#

github.com/gorilla/mux v1.8.0 — the HTTP router; Buffalo’s entire routing API (app.GET, app.Resource, named parameters) is a thin wrapper over gorilla/mux. Notably, gorilla/mux was archived and later transferred to community maintenance — a supply-chain risk Buffalo has accepted
github.com/gorilla/sessions v1.2.1 — session store abstraction (cookie-backed by default); used for Buffalo’s c.Session() API
github.com/gorilla/handlers v1.5.1 — HTTP middleware (CORS, logging, recovery); Buffalo registers these in its default middleware stack
github.com/gobuffalo/httptest v1.5.2 — Buffalo-aware HTTP testing helpers that spin up a real App and make assertions on responses; used extensively in Buffalo’s own test suite

Data/Storage#

github.com/monoculum/formam v3.5.5+incompatible — HTML form data binding; maps HTTP form values to Go structs for Buffalo’s c.Bind(). The +incompatible tag means it predates Go modules and has no go.mod, which is a minor compatibility concern
golang.org/x/text v0.29.0 — unicode/language handling; used for locale detection and text normalization in Buffalo’s i18n support

Templating/Rendering#

github.com/gobuffalo/plush/v5 v5.0.11 — Buffalo’s template engine, an ERB-inspired syntax for Go (<%= ... %>). This is a first-party gobuffalo package and the primary HTML rendering mechanism
github.com/gobuffalo/helpers v0.6.10 — template helper functions (time formatting, string helpers, form helpers) registered into the plush context
github.com/gobuffalo/tags/v3 v3.1.4 — HTML tag builder for form inputs, links, and asset tags used within plush templates
github.com/gobuffalo/github_flavored_markdown v1.1.4 — GFM markdown renderer; used in Buffalo’s content/documentation rendering pipeline (not typical app rendering)

Internal gobuffalo ecosystem#

github.com/gobuffalo/events v1.4.3 — lightweight pub/sub event bus; Buffalo fires events (buffalo:app:start, buffalo:worker:start, etc.) to allow plugins and middleware to hook into lifecycle events without tight coupling
github.com/gobuffalo/flect v1.0.3 — string inflection (singular/plural, snake_case, CamelCase); used internally for code generation and routing conventions (e.g. UsersResource → /users routes)

Testing#

github.com/stretchr/testify v1.9.0 — assertion library (require, assert); used pervasively in Buffalo’s own test suite. Present as a direct dependency since Buffalo exports test helpers that depend on it

Stdlib reliance#

Buffalo makes heavy use of the standard library. By import-frequency across non-test source files:

Package	Count	Usage
`net/http`	54	Core HTTP types — `http.Handler`, `http.Request`, `http.ResponseWriter` permeate every layer
`fmt`	44	String formatting for errors and output
`strings`	39	URL manipulation, header parsing, string normalization
`io`	24	Reader/Writer abstractions in request/response handling
`time`	23	Request timing, session expiry, worker scheduling
`context`	23	Request context propagation (notably less than you’d expect for a web framework)
`bytes`	22	Buffer management in render pipeline
`sync`	20	Mutex for app-level state (route map, middleware list)
`os`	19	Environment variable access, file system operations
`encoding/json`	17	JSON render and test assertions

Buffalo’s design philosophy is to stay close to net/http primitives — buffalo.Context wraps http.Request/http.ResponseWriter rather than replacing them, so stdlib reliance is genuinely high. Third-party dependencies are largely additive (routing, sessions, templating) rather than replacements for stdlib behaviour.

Shared dependencies#

Dependencies likely shared with other projects in the 50-project set:

github.com/stretchr/testify — near-universal in the Go ecosystem; most of the 50 projects use it
github.com/spf13/cobra — the dominant Go CLI framework; used by almost all projects with a CLI (kubectl, vault, terraform, etc.)
github.com/gorilla/mux — was the dominant Go router before chi/fiber rose; likely shared with older projects in the set
gopkg.in/yaml.v3 (indirect) — ubiquitous YAML parsing; will appear as a transitive dep in most projects
github.com/fsnotify/fsnotify (indirect via refresh) — file watching; common transitive dep via viper or similar
golang.org/x/net, golang.org/x/sys (indirect) — almost universal as transitive deps in any non-trivial Go project

Vendoring#

Buffalo does not vendor its dependencies. There is no vendor/ directory. This is consistent with modern Go modules practice and appropriate for a web framework (as opposed to a binary distribution). Buffalo relies on the module proxy (proxy.golang.org) and the go.sum lock file for reproducibility.

Notable dependency decisions#

All-in on the gobuffalo ecosystem. Of 18 direct deps, 8 are gobuffalo/* packages. This tight first-party coupling is by design — Buffalo is the “glue” layer coordinating a family of packages (plush, flect, helpers, events, tags, logger, httptest). This reduces external dependency risk but concentrates maintenance burden in a single organisation.
Gorilla stack over chi or httprouter. Buffalo chose gorilla/mux in 2016 for its named route support and named-parameter syntax — features that were unique at the time. Chi and httprouter have since matched or exceeded gorilla/mux’s performance, and gorilla/mux was archived. Buffalo hasn’t migrated, accepting the maintenance risk as the cost of API stability.
formam over gorilla/schema. For form binding, Buffalo uses monoculum/formam rather than the more common gorilla/schema. The +incompatible version tag indicates this dep predates modules — a subtle technical debt signal.
cobra for CLI, not a custom solution. Despite Buffalo being a web framework, it invests heavily in its CLI (buffalo new, buffalo generate, buffalo dev). Using cobra rather than a custom argument parser was a pragmatic choice that gives Buffalo all cobra’s features (help generation, subcommands, completion) for free.
No ORM in core. Notably absent: gobuffalo/pop (Buffalo’s preferred ORM) is not a direct dependency of the core buffalo module. Database access is deliberately decoupled — pop is a separate optional dependency that Buffalo apps include themselves. This keeps the core framework lightweight and database-agnostic.
Minimal use of x/ packages. Only golang.org/x/text is a direct dep; golang.org/x/net and golang.org/x/sys appear only as indirect deps. This suggests Buffalo avoids the heavier extended stdlib surface (no x/sync, x/crypto in direct deps), relying instead on standard sync and crypto packages.