mocker version: 0.7.2 (Homebrew) — macOS, Darwin 25.5.0, arm64
Summary
mocker compose up <name> with a service name that matches nothing in the project prints [+] Running 0/0 and exits 0. Upstream docker compose treats this as a user error: no such service: <name>, exit 1.
Silent success on a typo'd or nonexistent service name is actively misleading — it is indistinguishable from a successful no-op, and it hides genuine model-loading failures (it is how a fully empty parsed project presented itself while diagnosing the include: gap, filed separately).
Reproduction
/tmp/mocker-inc/docker-compose.yml:
services:
hello:
image: docker.io/library/alpine:3.20
command: ["sleep","300"]$ mocker compose up -d doesnotexist
[+] Running 0/0
$ echo $?
0
$ mocker compose ps
NAME IMAGE COMMAND SERVICE CREATED STATUS PORTS
The project is valid and mocker compose up -d hello in the same directory works — so this is purely the unmatched-name path, independent of any parsing problem.
Expected
$ mocker compose up -d doesnotexist
no such service: doesnotexist
$ echo $?
1
Likely cause
ComposeFile.filtering(services:) in Sources/MockerKit/Compose/ComposeFile.swift (L200-213):
func include(_ name: String) {
guard !included.contains(name), let svc = services[name] else { return }
...
}The let svc = services[name] failure branch silently returns, so a requested name that is absent from services is discarded without a diagnostic and the caller sees an empty selection rather than an error.
Suggestion: validate the requested names against services.keys before filtering, and surface the unmatched ones. Applies equally to the other subcommands that take service arguments (create, start, stop, build, pull, run, exec).
mocker version: 0.7.2 (Homebrew) — macOS, Darwin 25.5.0, arm64
Summary
mocker compose up <name>with a service name that matches nothing in the project prints[+] Running 0/0and exits 0. Upstreamdocker composetreats this as a user error:no such service: <name>, exit 1.Silent success on a typo'd or nonexistent service name is actively misleading — it is indistinguishable from a successful no-op, and it hides genuine model-loading failures (it is how a fully empty parsed project presented itself while diagnosing the
include:gap, filed separately).Reproduction
/tmp/mocker-inc/docker-compose.yml:The project is valid and
mocker compose up -d helloin the same directory works — so this is purely the unmatched-name path, independent of any parsing problem.Expected
Likely cause
ComposeFile.filtering(services:)inSources/MockerKit/Compose/ComposeFile.swift(L200-213):The
let svc = services[name]failure branch silently returns, so a requested name that is absent fromservicesis discarded without a diagnostic and the caller sees an empty selection rather than an error.Suggestion: validate the requested names against
services.keysbefore filtering, and surface the unmatched ones. Applies equally to the other subcommands that take service arguments (create,start,stop,build,pull,run,exec).