Skip to content

feat: reference an out-of-repo module in a workspace (#350) - #351

Open
antoinetoussaint-byte wants to merge 1 commit into
mainfrom
issue-350-reference-an-out-of-repo-module-in-a
Open

feat: reference an out-of-repo module in a workspace (#350)#351
antoinetoussaint-byte wants to merge 1 commit into
mainfrom
issue-350-reference-an-out-of-repo-module-in-a

Conversation

@antoinetoussaint-byte

@antoinetoussaint-byteantoinetoussaint-byte commented Aug 24, 2026

Copy link
Copy Markdown
Contributor

Closes#350.

Summary

  • The model layer already carried most of what the issue asked for: a workspace module reference has a path: override (ModuleReference.PathOverride), Workspace.ModulePath resolves it, and LoadModules/LoadServices load a referenced module's services into the run/render graph the same as in-repo ones. Cross-boundary endpoint/dependency wiring (ValidateServiceDependencies) already works on whatever the reference resolves to.
  • The one gap: relative overrides were confined by filepath.IsLocal, so only a non-portable absolute path could point out-of-repo. A composition-root workspace committed to git needs a portable relative reference to a sibling checkout (path: ../module-saas-starter) — which was rejected.
  • This lifts that restriction for module references only (they are the composition root; absolute overrides were already treated as a deliberate external-location choice). Service/job/application overrides stay confined to their owning resource, and NUL/backslash stay rejected as cross-platform hazards. No vendoring, no fork boundary.

Workspace.ModulePath joins a relative override onto the workspace dir (path.Join(workspace.Dir(), override)), and LoadWorkspaceFromDir resolves the workspace dir to an absolute path up front — so path: ../host resolves relative to the workspace root regardless of the invocation cwd. That cwd-independence is what makes the relative form committable and portable across machines.

External git/OCI sources remain future work, as the issue scopes them ("and later an external git/OCI source"); this delivers the path-reference form.

Test plan

  • go test ./resources/... ./architecture/... (module-layout + path-boundary suites) pass
  • End-to-end test: a layout: modules workspace referencing an out-of-repo module via path: ../host loads the sibling module's services and validates a cross-boundary service dependency on its public endpoint. Asserts the committed override is the relative form (../host), not an absolute machine path — the portability property is the point.
  • Validator test: module reference accepts ../host, still rejects NUL/backslash; service reference override still rejects ../ traversal
  • go build ./..., go vet ./resources/, gofmt clean

🤖 Generated with Claude Code

Allow a workspace module reference to resolve to an out-of-repo module
via a relative path override, so a solution repo can be the composition
root that references a host module (a sibling checkout) without vendoring
a copy of it.
Module references are a composition root and now permit upward-traversing
relative overrides (e.g. `path: ../module-saas-starter`), matching the
existing precedent that absolute overrides are a deliberate external
location. Service/job/application overrides stay confined to their owning
resource. Module-graph loading and cross-boundary dependency wiring already
work once the reference resolves.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
@antoinetoussaint-byte
antoinetoussaint-byteforce-pushed the issue-350-reference-an-out-of-repo-module-in-a branch from 53ed79c to 1001aacCompareAugust 24, 2026 02:27
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Reference an out-of-repo module in a workspace (non-vendored composition)

1 participant

@antoinetoussaint-byte