Helm — Dependencies#

Module info#

• Module: helm.sh/helm/v4
• Go version: 1.25.0
• Direct dependencies: 47 (first require block in go.mod)
• Indirect dependencies: ~126 (second require block); go.sum has 523 lines ≈ 261 total modules

Dependency categories#

Core infrastructure / CLI#

• github.com/spf13/cobra v1.10.2 — CLI framework powering the entire helm command tree (~57 files import it). The canonical Go CLI framework; used by virtually every tool in the Kubernetes ecosystem.
• github.com/spf13/pflag v1.0.10 — POSIX-style flags, cobra’s companion. Handles --flag / -f parsing and env var binding.
• github.com/fatih/color v1.19.0 — Colorized terminal output for warnings, errors, and diff highlighting.
• github.com/gosuri/uitable v0.0.4 — Tabular output (used for helm list, helm repo list, etc.).
• github.com/moby/term v0.5.2 — Terminal size detection for adaptive output width.
• k8s.io/klog/v2 v2.130.1 — Kubernetes-style structured logging; used for the Kubernetes client internals. Helm’s own code uses Go’s log/slog (stdlib, Go 1.21+).

Template engine / Rendering#

• github.com/Masterminds/sprig/v3 v3.3.0 — Adds ~100 template functions (string manipulation, math, crypto, date, reflection) on top of Go’s text/template. This is Helm’s core value-add for chart authors.
• go.yaml.in/yaml/v3 v3.0.4 — Newer YAML library (fork of gopkg.in/yaml.v3 under active governance); used in 4 non-test locations, indicating an in-progress migration from gopkg.in/yaml.v3.
• github.com/BurntSushi/toml v1.6.0 — TOML parsing; used for reading Helm’s local configuration file (~/.config/helm/...).
• github.com/santhosh-tekuri/jsonschema/v6 v6.0.2 — JSON Schema validation for chart values.schema.json files, enabling chart authors to validate user-supplied values at install time.
• github.com/evanphx/json-patch/v5 v5.9.11 — JSON merge-patch and strategic merge patch, used in pkg/kube/client.go for three-way merges during upgrades.
• github.com/gobwas/glob v0.2.3 — Glob pattern matching for .helmignore and chart dependency filtering.

Kubernetes integration#

This is the largest category by count, reflecting that Helm drives Kubernetes directly rather than shelling out to kubectl:

• k8s.io/api v0.35.1 — Core Kubernetes API types (Pod, Service, Deployment, etc.)
• k8s.io/apimachinery v0.35.1 — Kubernetes API machinery (Object, GroupVersionKind, unstructured).
• k8s.io/apiextensions-apiserver v0.35.1 — CRD types; Helm can install CRDs as part of chart deployment.
• k8s.io/apiserver v0.35.1 — Some server-side machinery needed for server-side apply.
• k8s.io/cli-runtime v0.35.1 — genericclioptions.ConfigFlags for kubeconfig/context handling, used throughout pkg/action.
• k8s.io/client-go v0.35.1 — The Kubernetes API client; used for all cluster communication.
• k8s.io/kubectl v0.35.1 — Some kubectl internals (explain, table printing), embedded rather than shelled out.
• sigs.k8s.io/controller-runtime v0.23.3 — Used for server-side apply helpers.
• sigs.k8s.io/kustomize/kyaml v0.21.1 — KYAML pipeline (kio.Pipeline) used in pkg/action/action.go for resource filtering/transformation.
• sigs.k8s.io/yaml v1.6.0 — JSON/YAML marshaling bridge; heavily used (31 non-test imports) because Kubernetes types serialize to JSON but are presented as YAML.
• github.com/fluxcd/cli-utils v0.37.2-flux.1 — The kstatus polling subsystem for watching resource readiness. Helm uses this in pkg/kube/statuswait.go to implement --wait semantics, borrowing production-tested Kubernetes status machinery from the FluxCD project.

OCI / Registry#

Helm v3/v4 supports storing charts in OCI registries:

• oras.land/oras-go/v2 v2.6.0 — OCI artifact push/pull operations (helm push, helm pull). ORAS is the standard Go library for OCI distribution beyond container images.
• github.com/opencontainers/image-spec v1.1.1 — OCI image manifest/descriptor types.
• github.com/opencontainers/go-digest v1.0.0 — Content-addressable digest (SHA256) for OCI layers.
• github.com/distribution/distribution/v3 v3.0.0 — OCI registry server; appears only in test helpers (repotest/server.go) to spin up an in-process registry for integration tests.

WASM Plugin system (new in v4)#

A significant architectural addition for the v4 series:

• github.com/extism/go-sdk v1.7.1 — Extism is a universal plugin system built on WebAssembly. Helm v4 uses it to load plugins compiled to WASM, enabling sandboxed execution.
• github.com/tetratelabs/wazero v1.11.0 — Pure-Go WebAssembly runtime (zero CGo dependencies). The Extism SDK uses it as its WASM execution engine. This replaces the v3 subprocess plugin model with in-process WASM calls.

SQL Storage backend (new in v4)#

Helm v4 adds SQL (PostgreSQL) as a release storage backend alongside Kubernetes Secrets/ConfigMaps:

• github.com/jmoiron/sqlx v1.4.0 — Ergonomic SQL toolkit; used in pkg/storage/driver/sql.go.
• github.com/lib/pq v1.12.1 — PostgreSQL driver for database/sql.
• github.com/Masterminds/squirrel v1.5.4 — SQL query builder (fluent API); constructs SELECT/INSERT/UPDATE in the storage driver.
• github.com/rubenv/sql-migrate v1.8.1 — Schema migrations for the SQL storage backend.
• github.com/DATA-DOG/go-sqlmock v1.5.2 (direct, for testing) — SQL mock driver for unit-testing storage driver code without a live database.

Security / Provenance#

• github.com/ProtonMail/go-crypto v1.4.1 — OpenPGP implementation (active fork of golang.org/x/crypto/openpgp which was deprecated). Used in pkg/provenance/sign.go for chart signing and verification (.prov files).
• golang.org/x/crypto v0.49.0 — TLS utilities, bcrypt, and other crypto primitives.
• github.com/cyphar/filepath-securejoin v0.6.1 — Secure path construction preventing directory traversal; used when extracting charts.
• github.com/asaskevich/govalidator v0.0.0-20230301143203-a9d515a09cc2 — Validates URLs, hostnames, and other inputs in repo management.

Versioning / VCS#

• github.com/Masterminds/semver/v3 v3.4.0 — Semantic versioning parsing and constraint matching; used throughout for chart version checks, dependency resolution, and Kubernetes version constraints (~19 non-test imports).
• github.com/Masterminds/vcs v1.13.3 — VCS detection (git, hg, svn, bzr) used by the plugin installer to fetch plugins from source control URLs.

Utilities / Output#

• github.com/mattn/go-shellwords v1.0.12 — Shell word splitting; parses HELM_COMMAND_FLAGS and plugin arg strings.
• github.com/gofrs/flock v0.13.0 — Cross-platform file locking for the repository cache.
• golang.org/x/term v0.41.0 — Terminal detection (isatty) for choosing output mode.
• golang.org/x/text v0.35.0 — Unicode text transformation used indirectly via Sprig.

Testing#

• github.com/stretchr/testify v1.11.1 — assert / require / mock; universal in the codebase.
• github.com/foxcpp/go-mockdns v1.2.0 — In-process DNS server mock; used in pkg/engine tests to control DNS lookup behavior for Sprig’s lookup function.
• github.com/AdaLogics/go-fuzz-headers v0.0.0-20230811130428-ced1acdcaa24 — Fuzzing utilities; Helm has fuzz targets for chart loading and rendering.

Stdlib reliance#

Helm makes heavy, idiomatic use of the standard library. The pkg/action package alone imports 13 stdlib packages (bytes, errors, fmt, io, log/slog, maps, os, path, path/filepath, slices, strings, sync, text/template, time) against only 4 third-party imports. Notable stdlib choices:

• log/slog (Go 1.21+): Helm’s own code uses structured logging via the new stdlib slog rather than logrus or zap. k8s.io/klog/v2 appears only for Kubernetes client internals.
• text/template: The entire chart rendering engine is built on stdlib templates; Sprig adds functions without replacing the template engine itself.
• maps and slices (Go 1.21+): Used directly in action.go, signaling the team’s willingness to use the latest stdlib generics-backed packages instead of golang.org/x/exp.
• crypto/*: TLS and x509 used directly in pkg/registry for mTLS; ProtonMail only supplements where stdlib’s OpenPGP was deprecated.
• database/sql: The SQL storage driver wraps stdlib database/sql via jmoiron/sqlx; Helm does not use an ORM.

Shared dependencies#

Dependencies shared with many other projects in the 50-project set (connection points for the book):

Vendoring#

No vendor directory. Helm relies on the Go module proxy and go.sum for dependency integrity. This is typical for a tool (rather than a library) where reproducible builds are ensured by pinned versions in go.sum and CI infrastructure, not vendoring.

Notable dependency decisions#

1. WASM over subprocess for plugins (v4): The choice of wazero + extism/go-sdk over the v3 subprocess model is architecturally significant. Wazero is pure Go (no CGo), runs sandboxed WASM, and avoids the security and portability issues of subprocess plugins. This is one of the boldest dependency choices in the set of 50 projects.

2. SQL storage via four Masterminds-ecosystem packages: The addition of sqlx + squirrel + sql-migrate + lib/pq as direct deps (all production-grade but bringing ~4 new transitive closure branches) suggests the SQL backend is a first-class v4 feature, not an afterthought. The choice of squirrel (query builder) over raw SQL strings is a readability call that avoids an ORM.

3. go.yaml.in/yaml/v3 alongside gopkg.in/yaml.v3: Both YAML libraries are present as direct/indirect deps. go.yaml.in is the newer, actively maintained fork that the Go YAML community has coalesced around; Helm is in the middle of a migration. The coexistence of both is a transitional artifact.

4. fluxcd/cli-utils for wait semantics: Rather than reimplementing Kubernetes resource readiness polling, Helm borrows the production-battle-tested kstatus package from FluxCD’s cli-utils. This is a dependency on a specific version fork (v0.37.2-flux.1) rather than the upstream, showing pragmatic adoption of a patched version.

5. ProtonMail/go-crypto over golang.org/x/crypto/openpgp: Helm explicitly migrated to the ProtonMail fork when the Go team deprecated x/crypto/openpgp. This is a lesson in depending on deprecated stdlib extensions — when the Go team drops them, the community forks (and Helm followed).

6. Minimal logging framework: No uber-go/zap or rs/zerolog. Helm uses log/slog for its own code, which is a deliberate, forward-looking choice that avoids a performance-logging framework dependency in a tool whose hot path is not logging.