Problem statement
Developers who want to use a custom generator with dot have no way to register it without modifying the dot source code. There is no CLI to manage local generators.
Proposed solution
Implement dot generator add/list/remove in cmd/dot/cmd_generator.go.
dot generator add ./my-generator # register a local generator path
dot generator list # list registered generators: name, language, modules, source
dot generator remove my-generator # unregister by name
Local generators are stored in .dot/generators.json:
{
"generators": [
{ "name": "my-generator", "source": "./my-generator", "version": "local" }
]
}
At startup, buildRegistry() reads .dot/generators.json and loads registered generators in addition to the official ones.
Alternatives considered
Require users to fork dot and add generators to cmd/dot/build.go. Current workaround but not scalable.
Subprocess-based loading. Better long-term but requires the loading mechanism decision first.
Area
Core
Additional context
Depends on: Community generator loading mechanism decision (open-decisions.md #1).
Problem statement
Developers who want to use a custom generator with dot have no way to register it without modifying the dot source code. There is no CLI to manage local generators.
Proposed solution
Implement
dot generator add/list/removeincmd/dot/cmd_generator.go.Local generators are stored in
.dot/generators.json:{ "generators": [ { "name": "my-generator", "source": "./my-generator", "version": "local" } ] }At startup,
buildRegistry()reads.dot/generators.jsonand loads registered generators in addition to the official ones.Alternatives considered
Require users to fork dot and add generators to
cmd/dot/build.go. Current workaround but not scalable.Subprocess-based loading. Better long-term but requires the loading mechanism decision first.
Area
Core
Additional context
Depends on: Community generator loading mechanism decision (open-decisions.md #1).