> go generate fruit.com/fruit
go: finding fruit.com v1.0.0
go: downloading fruit.com v1.0.0
go: extracting fruit.com v1.0.0
go: not generating in packages in dependency modules
It feels like this should be an error instead of a noisy success. Reason being, I've specified the pattern of a non-main module package(s) on the command line; based on the current implementation, that will never succeed (even if there is a replace directive).
Personally, I'd prefer that we allow go generate to refer to other modules with filesystem replace directives: that way, for example, you could test the impact of changes to a code-generator on a few important modules that use that generator.
that way, for example, you could test the impact of changes to a code-generator on a few important modules that use that generator.
Not averse to your suggestion, but just to note (at least from my experience) the requirement is the other way around, i.e. the module with the go:generate directive requires the generator. As such the module with the directive is still the main module. Testing of a quick fix would also generally be from the perspective of the directive-containing module, with/without a replace directive.
Unless you're talking about temporarily adding the reverse requirement for testing purposes?