Skip to content

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

Merged
antoinetoussaint-byte merged 2 commits into
mainfrom
issue-350-reference-an-out-of-repo-module-in-a
Aug 24, 2026
Merged

feat: reference an out-of-repo module in a workspace (#350)#351
antoinetoussaint-byte merged 2 commits into
mainfrom
issue-350-reference-an-out-of-repo-module-in-a

Conversation

@antoinetoussaint-byte

@antoinetoussaint-byte antoinetoussaint-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-byte force-pushed the issue-350-reference-an-out-of-repo-module-in-a branch from 53ed79c to 1001aac Compare August 24, 2026 02:27
validateModuleReferencePathOverride only rejected NUL/backslash, so an
empty override (`path: ""`) passed validation where the prior generic
validator rejected it (filepath.IsLocal("") is false). An empty override
then resolved via ModulePath to the workspace root itself and failed late
with an opaque "cannot load module" instead of a clear validation error.
Restore the guard the loosening dropped.

Also document why a module's own path override stays confined while a
workspace-level ModuleReference may resolve out-of-repo, so the two
"module" validators no longer read as an accidental inconsistency.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
@antoinetoussaint-byte
antoinetoussaint-byte merged commit 28bb10f into main Aug 24, 2026
1 check passed
Sign up for free to 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