plugins/caddy master cannot be built with xcaddy: SortQuery undefined (go.mod requires souin v1.7.8, masked by an in-repo replace) #848

Description

Building the Caddy plugin from master with the documented xcaddy line fails to compile: plugins/caddy at HEAD uses configurationtypes.Key.SortQuery, but its go.mod requires the released root module github.com/darkweak/souin v1.7.8, which predates that field (added in #751).

xcaddy build \
  --with github.com/darkweak/souin/plugins/caddy@e6cde294f4099d03559b422f8d671181d3a24b7b

# github.com/darkweak/souin/plugins/caddy
.../plugins/caddy@v1.7.9-0.20260623072703-e6cde294f409/configuration.go:501:11:
    ck.SortQuery undefined (type configurationtypes.Key has no field or method SortQuery)
.../plugins/caddy@v1.7.9-0.20260623072703-e6cde294f409/configuration.go:599:18:
    config_key.SortQuery undefined (type configurationtypes.Key has no field or method SortQuery)

Cause

plugins/caddy/go.mod:

require github.com/darkweak/souin v1.7.8
...
replace github.com/darkweak/souin v1.7.8 => ../..

The replace keeps the in-repo build and CI green, because a replace in the main module applies there. When the plugin is consumed as a dependency — which is what xcaddy does — replace directives in non-main modules are ignored, so the real v1.7.8 is resolved and the build breaks.

So master builds in CI but cannot be built by a user, and this is invisible from inside the repo.

Workaround

Pin the root module explicitly, so xcaddy puts it in the main module where the version applies:

xcaddy build \
  --with github.com/darkweak/souin/plugins/caddy@e6cde294f4099d03559b422f8d671181d3a24b7b \
  --with github.com/darkweak/souin@e6cde294f4099d03559b422f8d671181d3a24b7b

That builds cleanly (verified: caddy v2.11.4, cache v1.7.9-0.20260623072703-e6cde294f409).

Suggested fix

Bump the require in plugins/caddy/go.mod to a pseudo-version of the current root module whenever the plugin starts using a newly added field, so the released dependency graph stays consistent. A CI job that builds the plugin via xcaddy from the proxy (rather than from the working tree) would catch this class of breakage — the in-repo replace currently masks it.

Note this only affects builds from master; the tagged v1.7.8 line builds fine.

Environment

• go 1.26, xcaddy latest, caddy v2.11.4
• souin e6cde294f4099d03559b422f8d671181d3a24b7b (master, 2026-06-23)