`project create`: allow overriding COMPOSE_PROJECT_NAME (and other generated .env keys) via flags

[ROBJkE]

Summary

When using shopware-cli project create … --docker, the CLI writes a generated COMPOSE_PROJECT_NAME into the project .env (format sw-<basename>-<6 hex>). That is useful for local uniqueness, but there is currently no create flag (or documented create-time override) to choose a custom value.

For CD / multi-env setups we often want Compose’s project name to follow a stable identity (e.g. <shop-id>-<env>), not a random local slug. Today the only options are to edit .env after create or remove the key for stacks that derive name: themselves.

Current behaviour

• Docker scaffolds call into EnvFileContent / GenerateComposeProjectName and write COMPOSE_PROJECT_NAME=sw-… into .env.
• EnsureComposeProjectName leaves an existing value untouched, but create itself always generates one for docker projects.
• Documented create flags cover things like --docker, --local-domain, --no-interaction, version, etc. — not compose project naming.

Request

Please make host-side .env values that create writes — at least COMPOSE_PROJECT_NAME — modifiable at project create time, ideally via CLI flags (and/or documented env overrides that create respects when writing .env).

Suggested shape (illustrative)

shopware-cli project create my-shop --docker \
  --compose-project-name=acme-live

Or a small set of --env KEY=VALUE / --env-file options for any keys create would otherwise generate.

Acceptance ideas

• project create --docker --compose-project-name=<name> writes that exact value to .env
• Invalid Compose project names are rejected with a clear error (Compose rules: lowercase, digits, dashes, underscores)
• Default remains the current sw-<basename>-<hash> when the flag is omitted (no behaviour change for existing users)
• Documented in project create --help and the CLI docs

Why it matters

Teams using image-based CD with a separate VPS Compose stack often treat shop id + deploy env as the Compose identity. A random COMPOSE_PROJECT_NAME from create overrides Compose name: when the same .env is reused, which is easy to miss and breaks multi-shop / live+staging isolation expectations.

Being able to set this at create time (instead of a manual post-edit) would keep the local docker path and CD path aligned and scriptable.

Environment

• Observed with recent shopware-cli docker create (Shopware 6.7.x scaffolds)
• Related implementation: internal/shop/compose_project_name.go (GenerateComposeProjectName, EnvFileContent)

[shyim]

Why you don't commit that?

[ROBJkE]

I will create a PR later. Just filled the issue first to keep track on.

[shyim]

nono I mean .env should be committet together with the project. so it's than stable 😅

[ROBJkE]

I dont know what you mean. Sure the .env will be committed. The issue is not about 'manual' setups, but about automation workflows.

For CD / multi-env setups we often want Compose’s project name to follow a stable identity (e.g. -), not a random local slug. Today the only options are to edit .env after create or remove the key for stacks that derive name: themselves.

You can argue to remove or manipulate this env var after creation (also via scrip), but it would be nice DX sugar if you could set it on create

[lasomethingsomething]

Hello ROBJkE, thanks for filing this issue. Product manager for the CLI here, trying to better understand the problem/proposed solution. You mention you could also remove or script the value after create. What makes the flag worth it over those options? As Soner notes, the .env is committed with the project, so the name only gets written once and is stable from then on.

[ROBJkE]

somethings (@lasomethingsomething) It would be nice DX sugar if you could set it on create, so you don't have to modiy it afterwards.

[lasomethingsomething]

ROBJkE Thanks much, but we'd seen that point made earlier and were still left wondering.