The command is injected when running xcaddy with one of Caddy's commands, though validate-interfaces does not exist in Caddy itself. This is useful for guest modules developers to validate their implementation meets the expectation of the host module. Developers who introduce new caddy namespaces and want to participate in the validation process may include code as such in their init:
There's dependency on caddyserver/caddy#4838 because the Caddy executable built for the development process expects a version of Caddy that contains certain functions, namely caddy.ConformsToNamespace. I'm not sure if this will break any workflow. We can brainstorm an idea to conditionally inject it, but I can't think of something now.
With this addition, the developer of a Caddy module can run xcaddy validate-interfaces to have a custom Caddy built to receive a message of either All modules conform to their namespaces. or a spit-out of the interface they're missing.
Perhaps validate-types is a better command name? 🤔
The command is injected when running xcaddy with one of Caddy's commands, though
validate-interfacesdoes not exist in Caddy itself. This is useful for guest modules developers to validate their implementation meets the expectation of the host module. Developers who introduce new caddy namespaces and want to participate in the validation process may include code as such in theirinit:There's dependency on caddyserver/caddy#4838 because the Caddy executable built for the development process expects a version of Caddy that contains certain functions, namely
caddy.ConformsToNamespace. I'm not sure if this will break any workflow. We can brainstorm an idea to conditionally inject it, but I can't think of something now.With this addition, the developer of a Caddy module can run
xcaddy validate-interfacesto have a custom Caddy built to receive a message of eitherAll modules conform to their namespaces.or a spit-out of the interface they're missing.Perhaps
validate-typesis a better command name? 🤔