Depends on the use-case. For development, you would need to install some system dependencies, access to bash for debugging etc and hence the full blown base image. In production, you want the image sizes to be minimal and hence alpine base image. Also reduces the attack vector.

But why are you doing minute-to-minute development within a container? What's so hard about installing the official Node package for your development system's distribution? When the developer is finished working on a feature, then and only then build a production Docker image from the codebase that now implements that feature, maybe run a few smoke tests, and push to CI. Building special containers for development purposes is sheer madness.

I am developing in a container - most of the time - as this allows me to run the (micro-)service within it's defined ecosystem, so no need to mock any service boundaries.

Note: New services and major functionalities are usually developed locally with unit-tests ensuring compliance with the spec. But once this is done and stuff needs to be integrated with the real system - or debugged later on - there is IMHO nothing that can beat a complete copy of the real system running locally where one can easily manipulate whatever is needed.

you're right, plus docker-compose supports extending services in compose files. In the projects i dockerized, i have a docker-compose.yml, docker-compose.dev.yml, docker-compose.test.yml and docker-compose.prod.yml, no override files.