I fixed the merge conflicts and added some of the tests I'd already written for the other PR, this one covers the other use case and applies the same logic to other commands 🥳

Ahh! Need to fix some tests 😅

While looking into why this was failing when applying a similar logic to compose ps I noticed some inconsistencies regarding how the -p flag is handled vs the COMPOSE_PROJECT_NAME env var.

The reason why some tests were failing was that we are running compose ps with the COMPOSE_PROJECT_NAME env var set, but without a compose.yaml in the directory. Using projectOptions.toProjectName(...), this worked because before attempting to load the project, it checks for the env var and doesn't attempt to load the project otherwise. However, the introduction of projectOptions.projectOrName(...) causes some issues here because it doesn't attempt to check the env var, and instead always loads the project unless the passed projectOptions struct already has a name set. The inconsistencies here are due to the fact that the projectOptions.ProjectName field is set when running compose -p [project-name], but not when running COMPOSE_PROJECT_NAME=[project-name] compose.

I think we should handle these in the same way, probably in the parent compose command, and set that value regardless of where the project name comes from. This would also make some other things more consistent, ie compose -p [name] down works even if there is no compose.yaml in the directory but COMPOSE_PROJECT_NAME=[name] compose down fails.

I made some changes to projectOrName() in this PR to fallback to the previous behavior so the tests can pass, but I think some of this logic should be cleaned up and moved up for more consistency.

compose -p [name] down works even if there is no compose.yaml in the directory but COMPOSE_PROJECT_NAME=[name] compose down fails

Why would you like the latter to fail? IMHO once COMPOSE_PROJECT_NAME is set, all compose command should be able to run based on existing resources, same as passing -p flag. But maybe I'm missing some corner cases...

I worded that weirdly 😅 don’t want it to fail, but with the changes before my last commit it was failing. This was due to projectOrName not checking the env var.

LGTM with @laurazard additions