Skip to content

Migration: adapters are registered by the tool's main

Until this change, pkg/chat/providers.go blank-imported the three chat provider modules and pkg/setup/providers.go the four forge adapters, so every tool built on the framework linked all seven whether it used them or not. A bare root command weighed 81 MB statically linked; without them it weighs 34 MB (spec 0194).

Both files now register nothing. The framework still registers forge/direct, the plain download source that ships inside the forge module.

A hand-wired tool loses every provider until it adds the imports

A tool that builds its own main (rather than being generated by gtb) and upgrades past this release will find ai failing with unsupported provider and self-update failing with no release provider registered, each with a hint naming the import to add. The root command also refuses to start when a forge feature is enabled whose adapter is not linked, and doctor reports it as Forge adapters.

What to do

Add a file to the tool's main package that blank-imports the modules it uses. For a tool that talks to Claude and releases on GitHub:

package main

import (
    _ "gitlab.com/phpboyscout/go/chat-anthropic" // claude, claude-local
    _ "gitlab.com/phpboyscout/go/forge-github"
)

Then go get each module and go mod tidy. The modules are no longer indirect requirements of the framework, so the versions are the tool's own to choose.

Which module registers which name:

chat provider module
claude, claude-local gitlab.com/phpboyscout/go/chat-anthropic
openai, openai-compatible, codex-local gitlab.com/phpboyscout/go/chat-openai
gemini, gemini-vertex, agy-local gitlab.com/phpboyscout/go/chat-gemini
bedrock gitlab.com/phpboyscout/go/chat-bedrock
azure-openai gitlab.com/phpboyscout/go/chat-openai-azure
forge feature module
github gitlab.com/phpboyscout/go/forge-github
gitlab gitlab.com/phpboyscout/go/forge-gitlab
gitea, codeberg gitlab.com/phpboyscout/go/forge-gitea
bitbucket gitlab.com/phpboyscout/go/forge-bitbucket

chat.ProviderModule and forge.ModuleFor return the same tables at runtime, and the error hints quote them.

A tool generated by gtb is not affected: gtb generate project and gtb regenerate project emit these imports from the manifest (spec 0194 D4 to D7, the step after this one). A project generated before that lands keeps working, because the framework version it pins still carries the imports; regenerating it under the new gtb writes the files.

The gtb CLI moved to cli/

gitlab.com/phpboyscout/go-tool-base/cli is a nested module carrying the binary, the generator and the e2e suite. Two consequences for anyone building from source:

  • go install gitlab.com/phpboyscout/go-tool-base/cli/cmd/gtb@latest (the path gained cli/). The generated go.mod's tool block names the new path.
  • In a checkout, ./... reaches only the framework module: use go test ./... ./cli/..., or the justfile recipes, which already do.

The framework module's own requirements dropped from 266 to 200 lines; the generator's dependencies (dave/dst, dave/jennifer, godog) went with the CLI.