Compatibility
RespKit separates its core response API from optional integrations. Each module declares its own Go requirements and dependencies, and CI checks those modules independently.
Go and module requirements
The minimum Go version for each module is declared in its go.mod file. Optional integrations can require a newer toolchain than the core library.
| Module | Purpose | Current requirements |
|---|---|---|
| Core | Public response helpers and internal runtime packages; standard library only | Root go.mod |
| Framework tests | Runtime checks against upstream HTTP frameworks | Framework test go.mod |
| Optional pgx adapter | PostgreSQL error mapping with pgx | pgx adapter go.mod |
For a released version, select its tag on GitHub before inspecting the manifest. This keeps the requirements aligned with the code you install.
HTTP framework support
Gin, Echo, and Fiber use their native contexts. Standard net/http handlers, Chi, Gorilla/mux, and Beego use resp.HTTP(w, r). The framework guide shows how to connect each router.
The integration suite sends requests through real upstream routers. It checks status codes, JSON bodies, localization and cache headers, error confidentiality, Location, and empty 204 responses. The framework test manifest lists the versions selected for those checks.
Passing the suite establishes compatibility with the dependency versions used by that run. Applications should also exercise their handlers with the framework version they install.
CI checks
| Check | Scope |
|---|---|
| Core platform checks | Unit tests and go vet on Linux, macOS, and Windows |
| Race detection | Concurrent behavior in the core and integration suites |
| Statement coverage | A 100% combined coverage requirement for resp and internal runtime packages |
| Framework runtime tests | Responses sent through upstream framework routers |
| Optional mapper tests | Database-specific error mapping in separate modules |
The CI workflow defines the current toolchain and platform matrix. To inspect results, open GitHub Actions, select the branch or tag, and open the run for the commit you want to use.
Run the checks locally using the testing guide. Integration suites download upstream dependencies and require network access. These dependencies remain outside the core module.
Interpreting results
Statement coverage measures executed statements in the packages included by the coverage command. It does not establish that every branch, input, or framework version has been exercised. Framework tests and optional mapper tests are reported separately because they live in separate modules.
A cross-build confirms that binaries compile for a target platform. Runtime compatibility requires tests that actually execute on that platform.