Yes, I agree. I'm working on a Rails project today and the container in development has some gems we only use for development and testing: byebug, pry, rspec, timecop, simplecov, factory_bot. They won't go into the production images. The instructions for developers are

    docker-compose build
    docker-compose run --rm api bundle
    docker-compose up

api is the name of the service in docker-compose.yml

One developer has a M1 Mac and he's using something called mutagen instead of docker. His docker-compose.yml is a little different and he's paying a performance penalty. His M1 is only 50% faster than my Intel from 2014 at running the test suite (50 seconds vs 75.) The difference is not noticeable when running only a few tests per time when working on a single feature.

You probably want to use

    docker compose

not

    docker-compose

The latter was the name of the compose v1 binary, so using it may cause your command to be handled with a v1-to-v2 compatibility mode. Depends on how your installation is setup. Compose v2 is implemented as a Docker CLI plugin.

When I invoke `docker compose up` on my project with Docker version 20.10.18 it says:

    The new 'docker compose' command is currently experimental.

I'm not sure what that means, but I don't think compose v2 is considered experimental at this point. It is included in Docker Desktop, for example. You might be running an older version. You can check `docker compose version`. Version 2.12.2 was released a few days ago.

Does he run ARM docker images or X86? I can imagine the latter will slow things down