`COMPOSE_PROJECT_NAME` ignored; `compose config` prints `name: default` instead of the effective project name

[KennethWKZ]

mocker version: 0.7.2 (Homebrew) — macOS, Darwin 25.5.0, arm64

Summary

Two related project-name defects:

1. COMPOSE_PROJECT_NAME set in .env (or the environment) is ignored — resource names fall back to the working directory basename.
2. mocker compose config prints name: default rather than the effective project name.

Effect: the same repo produces differently-named volumes, networks, and containers under mocker versus upstream Compose, so switching between the two silently yields two parallel sets of resources rather than reusing one. For a stateful stack (databases) that is a real data-confusion risk, since the second set starts empty and looks like data loss.

Reproduction — 1: COMPOSE_PROJECT_NAME ignored

In /tmp/mocker-inc/:

.env:

COMPOSE_PROJECT_NAME=zzztest

docker-compose.yml:

services:
  hello:
    image: docker.io/library/alpine:3.20
    command: ["sleep","300"]
volumes:
  data:

$ mocker compose up -d hello
[+] Running 2/2
 ✔ Volume mocker-inc-data                   Created
 ✔ Container mocker-inc-hello-1             Started

Expected prefix zzztest-, i.e. zzztest_data / zzztest-hello-1; got mocker-inc- from the directory basename.

Real-world instance: a Laradock checkout with COMPOSE_PROJECT_NAME=laradock in .env, sitting in a directory named laravel-docker, produced laravel-docker-backend, laravel-docker-mysql, etc., where upstream Compose produces laradock_*.

Note that mocker does read .env for ${VAR} interpolation — this is specifically the project-name variable not being consulted.

Reproduction — 2: config prints name: default

Same directory, with or without .env:

$ mocker compose config
name: default
services:
  hello:
    image: docker.io/library/alpine:3.20
    ...

Expected the effective project name on that line (zzztest with the .env above, otherwise mocker-inc from the directory).

Expected precedence

Upstream Compose resolves the project name as:

1. -p / --project-name flag
2. COMPOSE_PROJECT_NAME in the environment
3. COMPOSE_PROJECT_NAME in the .env file
4. top-level name: in the Compose file
5. basename of the project directory

and config prints the resolved value. mocker appears to implement only 1 and 5 (-p works; the directory basename is the fallback), and config prints a constant.

Item 4 matters alongside -f on a flattened file: docker compose config emits name: <project> into its output, so a downstream mocker compose -f flat.yml up currently has to be told the name again with -p even though it is right there in the file.

I did not find COMPOSE_PROJECT_NAME anywhere in Sources/MockerKit/Compose/ComposeFile.swift; the resolution may live in Sources/Mocker/Commands/Compose.swift, which I have not read — so treat the source location as unconfirmed. The behavior above is reproduced directly.

[us]

fixed in #77, shipped in v0.8.0.

both halves. the project name now resolves exactly as you laid out: -p → COMPOSE_PROJECT_NAME in the environment → COMPOSE_PROJECT_NAME in .env → top-level name: → directory name, normalized to compose's character set. compose config prints what it resolved instead of the literal default.

worth flagging since you hit the laradock case: if you were relying on COMPOSE_PROJECT_NAME before, your resources are now named with it, so anything created under the old directory-derived name won't be matched anymore. bringing the project down before upgrading is the clean path.