Fiber — Dependencies#

Module info#

  • Module: github.com/gofiber/fiber/v3
  • Go version: 1.25.0
  • Direct dependencies: 14 (11 in first require block + 3 in second block missing // indirect)
  • Indirect dependencies: 8 (listed in second require block with // indirect)
  • go.sum entries: 49 lines (~24 unique module versions)

Dependency categories#

Core infrastructure#

  • github.com/gofiber/utils/v2 v2.0.2 — Fiber’s own shared utilities: byte conversions, string helpers, IP parsing, MIME handling. Used pervasively across app.go, ctx.go, and middleware packages. Kept as a separate module to share with the wider gofiber ecosystem.
  • github.com/gofiber/schema v1.7.0 — Fiber’s own form/URL schema decoder (forked from gorilla/schema). Used by the binder/ package to decode query parameters and form fields into structs.
  • github.com/mattn/go-colorable v0.1.14 and github.com/mattn/go-isatty v0.0.20 — Terminal color and TTY detection for the log/ package’s colored console output.

Networking/HTTP#

  • github.com/valyala/fasthttp v1.69.0 — The foundational HTTP engine. This is the single most important dependency; Fiber is essentially a developer-ergonomic layer on top of fasthttp’s zero-allocation request handling. Used throughout app.go, ctx.go, listen.go, client/, etc.
  • github.com/valyala/bytebufferpool v1.0.0 — Pooled byte buffers, a companion library to fasthttp used directly in ctx.go for zero-allocation body reads and response building.
  • golang.org/x/crypto v0.49.0 — Used in two distinct places: acme/autocert in listen.go for automatic TLS certificate provisioning (Let’s Encrypt) and bcrypt in middleware/basicauth/config.go for password hashing.
  • golang.org/x/net v0.52.0 — idna package used in req.go for internationalized domain name normalization in URL processing.

Data/Storage#

  • github.com/google/uuid v1.6.0 — UUID generation; used by the session middleware for session ID creation.
  • github.com/shamaton/msgpack/v3 v3.1.0 — MessagePack serialization (zero-allocation variant); used in the context binder and response encoding paths.
  • github.com/tinylib/msgp v1.6.3 — MessagePack code generator; used at build time (via go generate) to produce optimized marshal/unmarshal code. Runtime dependency because generated code imports it.
  • github.com/fxamacker/cbor/v2 v2.9.1 — CBOR serialization; used in client/client.go for the built-in HTTP client’s request/response encoding. Listed in the indirect block but lacks // indirect marker — it is a direct code dependency.
  • golang.org/x/text v0.35.0 — unicode/norm package used in middleware/basicauth for username normalization (NFC normalization of UTF-8 credentials).

Testing#

  • github.com/stretchr/testify v1.11.1 — The sole test framework; used extensively across all test files for assertions (assert, require) and suite setup. No gomock, ginkgo, or other assertion libraries present.

Indirect (transitive only)#

  • github.com/andybalholm/brotli v1.2.0 — Brotli compression; pulled in by fasthttp for response compression support.
  • github.com/klauspost/compress v1.18.5 — General compression (gzip, deflate, zstd, snappy); pulled in by fasthttp.
  • github.com/philhofer/fwd v1.2.0 — Forward-only byte reader; pulled in by tinylib/msgp.
  • github.com/davecgh/go-spew v1.1.1, github.com/pmezard/go-difflib v1.0.0, gopkg.in/yaml.v3 v3.0.1 — All pulled in by stretchr/testify for diff output and YAML test fixtures.
  • github.com/x448/float16 v0.8.4 — Half-precision float support; pulled in by fxamacker/cbor/v2.
  • golang.org/x/sys v0.42.0 — OS-level system calls; pulled in by fasthttp and mattn/go-isatty.

Stdlib reliance#

Fiber uses the standard library heavily alongside fasthttp. Key stdlib packages observed:

  • context, sync, sync/atomic — concurrency primitives throughout
  • encoding/json, encoding/xml — standard serializers used alongside msgpack/cbor
  • crypto/tls, crypto/x509 — TLS configuration in the client and server
  • net, net/http, net/http/httputil — used in app.go for compatibility shims and net utilities (notably, net/http is used for compatibility bridging, not as the serving engine)
  • fmt, errors, io, os, strings, strconv — standard utility packages

The balance is heavily tilted toward stdlib for general utilities, with third-party deps reserved for specific high-value concerns (HTTP engine, serialization, crypto extensions). This is a deliberate minimal-deps philosophy.

Shared dependencies#

Dependencies likely shared across the 50-project set:

  • stretchr/testify — Near-universal in Go projects; Fiber’s test suite is entirely testify-based.
  • google/uuid — Widely used for ID generation.
  • golang.org/x/crypto — Standard for TLS/crypto extension work.
  • golang.org/x/net — Commonly pulled in for networking utilities.
  • klauspost/compress — Frequently used as a compression backend in web/HTTP projects.
  • valyala/fasthttp — Less universal (most projects use net/http), but critical in the high-performance HTTP framework niche (e.g., shared with other fasthttp-based frameworks).

Vendoring#

No vendor/ directory present. Fiber relies on the Go module proxy and go.sum checksums for reproducibility. This is the modern standard approach and appropriate for a framework (vendoring would balloon repository size and make third-party consumption awkward).

Notable dependency decisions#

  1. fasthttp over net/http is the defining choice. Every other dependency decision flows from this. It delivers ~10x throughput gains in benchmarks but makes Fiber incompatible with the net/http middleware ecosystem, which the project accepts as a trade-off and partially mitigates with a middleware/adaptor bridge.

  2. Two MessagePack implementations. Both shamaton/msgpack (runtime serialization) and tinylib/msgp (code generation) are present. This is intentional: msgp generates fast static serialization code at build time, while shamaton/msgpack handles dynamic struct serialization at runtime. The dual approach maximizes performance for known-schema cases while retaining flexibility.

  3. CBOR via fxamacker/cbor/v2. Adding CBOR support alongside JSON, XML, and MessagePack in the HTTP client reflects Fiber v3’s ambition to be a full-featured, multi-protocol framework. This is relatively unusual for a web framework to support natively.

  4. Intra-ecosystem deps (gofiber/schema, gofiber/utils). Fiber maintains its own utility and schema packages as separate modules rather than embedding them. This lets other gofiber middleware packages depend on shared infrastructure without depending on the full framework — a modular monorepo-adjacent strategy.

  5. Extremely lean indirect graph. With only 49 go.sum lines total (~24 modules), Fiber’s transitive closure is remarkably small for a batteries-included framework. This is a conscious design goal: fasthttp itself has a minimal dep tree, and Fiber inherits that discipline.

Backward Fiber — Structure Fiber — Architecture Forward