Reduce broad runtime re-exports in generated service packages

[CaliLuke]

Generated service packages can re-export a large set of common runtime declarations from the Loom runtime package. When this happens, each generated package becomes partly a tunnel for shared framework API instead of containing only service-specific generated API.

Generic example:

package orders

type Endpoint = loom.Endpoint
type Middleware = loom.Middleware
type ServerOption = loom.ServerOption
// ... many more common runtime aliases

type Service interface {
    ListOrders(...) (...)
}

This creates avoidable namespace noise and makes generated package docs harder to scan because service-specific types are mixed with many framework-level aliases.

Requested improvement:

Prefer importing framework runtime types directly where needed, or centralize common aliases in one generated support package instead of repeating broad re-export sets in every generated service package.

Acceptance criteria:

• Generated service packages primarily expose service-specific contracts and wire types.
• Common Loom runtime declarations are not broadly re-exported from every generated package.
• Existing code can still access runtime concepts through an explicit framework import or a single stable generated support package.
• The generated output remains deterministic and gofmt/go vet clean.

[CaliLuke]

I took a pass through the current generator output and the local generated fixtures to sanity-check this request.

What I found so far:

• I did not find generated broad alias re-exports like type Endpoint = loom.Endpoint, type Middleware = ..., or type ServerOption = ... in the current checkout.
• The generated service packages do directly expose framework types in public signatures, especially loom.Endpoint in Endpoints, New*Endpoint, generated clients, and Use(func(loom.Endpoint) loom.Endpoint).
• That direct loom.Endpoint usage appears to be part of the generated service/client contract today, not just namespace noise. Removing it would be a source-breaking API redesign unless there is a replacement/migration plan.
• The reasonable cleanup target seems to be: avoid broad framework alias re-exports from service packages. I would treat removing legitimate endpoint/client contract types as a separate, larger design change.

Potential side effects if this is implemented too broadly:

• Consumers using any generated package aliases would break if those aliases are removed.
• Replacing loom.Endpoint in generated endpoint/client signatures would break middleware wrapping, endpoint construction, client construction, and existing generated-code tests.
• Moving aliases to a shared generated support package may reduce per-service docs noise, but still creates a new public import path and migration surface.

Can you add concrete examples of the problem you encountered? The most useful examples would be:

• a generated service.go or package doc snippet showing the broad re-export set,
• the DSL or generator path that produced it,
• whether the issue is current main output or output from an older generated service,
• and any downstream code that depends on gen/foo.Endpoint / gen/foo.Middleware style aliases today.

With that, this can be scoped either as a small regression/cleanup guardrail or as a deliberate generated API redesign.

[CaliLuke]

You are right. I rechecked the generated output that triggered this ticket, and I cannot find the broad type X = loom.X alias pattern described in the issue body.

The concrete generated shape is different:

func MakeInvalidRequest(err error) *loom.ServiceError {
    return loom.NewServiceError(err, "invalid_request", false, false, false)
}

func MakeUnauthorized(err error) *loom.ServiceError {
    return loom.NewServiceError(err, "unauthorized", false, false, false)
}

In the downstream generated output I checked, services had many service-specific Make* error factory functions returning *loom.ServiceError (for example 51 in one generated service package, 57 in another). Lagotto classified those packages as G8 re-export tunnels because many exported declarations point at github.com/CaliLuke/loom/pkg, but these are not alias re-exports and they are not the same problem as the issue body described.

I also agree that direct loom.Endpoint usage in generated endpoint/client signatures is part of the current generated public contract. Removing that would be a larger generated API redesign and should not be part of this ticket.

I think this issue should be closed as misfiled, or retitled/narrowed only if Loom wants a separate ergonomics issue for duplicated generated service-specific error factory wrappers. I will track the original audit result as a Lagotto detector false positive instead: G8 should not classify generated service-specific factory functions as broad runtime re-export tunnels.