Summary
Enable a workspace to reference an out-of-repo module (by path / external source) that codefly run resolves and boots alongside in-repo modules — without vendoring a copy of it.
Why
A "solution" (e.g. lastlogin-go in obin-ai/core-solutions) is a multi-module composition: it needs the saas host module (codefly-dev/module-saas-starter) plus its own runtime module(s), which live in different repos. We want the solution repo to be the composition root that references the modules it needs, so one codefly run brings up host + solution together and the solution self-registers into the host at runtime.
Today the only way codefly composes a module it doesn't own is base-sync = vendor a hash-pinned copy into the workspace tree. That's right for taking upstream base updates, but it forces every solution repo to also vendor the entire host — duplication, and a fork boundary we're explicitly trying to avoid ("clients are config, not forks").
What's needed (core/model layer)
- A workspace module-source that is a reference, not a vendored copy — a module entry that resolves to an out-of-repo path (and later an external git/OCI source) instead of
modules/<name>/ in-tree. - Module-graph resolution (
Workspace.LoadServices / module layout loading) that loads a referenced module's services into the run/render graph the same as local ones. - Endpoint/dependency wiring across the reference boundary (the referenced host exposes
frontend/gateway; the referencing solution consumes it).
Current understanding — TO BE CONFIRMED BY SPIKE
From CLI surface + binary inspection only (not source): codefly add module has no --source/--path, modules are created in-tree, and base-sync is the sole external-module mechanism → path/live references appear unsupported. A spike (lodestar side) will verify this before this issue is scoped as real work. If a workspace can already reference a module by path, close this.
Links
Summary
Enable a workspace to reference an out-of-repo module (by path / external source) that
codefly runresolves and boots alongside in-repo modules — without vendoring a copy of it.Why
A "solution" (e.g.
lastlogin-goinobin-ai/core-solutions) is a multi-module composition: it needs the saas host module (codefly-dev/module-saas-starter) plus its own runtime module(s), which live in different repos. We want the solution repo to be the composition root that references the modules it needs, so onecodefly runbrings up host + solution together and the solution self-registers into the host at runtime.Today the only way codefly composes a module it doesn't own is base-sync = vendor a hash-pinned copy into the workspace tree. That's right for taking upstream base updates, but it forces every solution repo to also vendor the entire host — duplication, and a fork boundary we're explicitly trying to avoid ("clients are config, not forks").
What's needed (core/model layer)
modules/<name>/in-tree.Workspace.LoadServices/ module layout loading) that loads a referenced module's services into the run/render graph the same as local ones.frontend/gateway; the referencing solution consumes it).Current understanding — TO BE CONFIRMED BY SPIKE
From CLI surface + binary inspection only (not source):
codefly add modulehas no--source/--path, modules are created in-tree, and base-sync is the sole external-module mechanism → path/live references appear unsupported. A spike (lodestar side) will verify this before this issue is scoped as real work. If a workspace can already reference a module by path, close this.Links