Compose overrides are quite cool but can get very involved.
An easier way is to make the port range dynamic by adding a prefix variable in .env/example.env. So, once configured, the whole localdev binds to ports in the prefix range, eg: 342xx.
Experience shows that localdevs will need that env file anyway and adding this config step to the readme is quite effective.
I like this a lot. It works well alongside setting the compose project name.
However I'd suggest at least specifying a default value so developers don't need to mess with version-controlled .env files to customize their local setups.
> However I'd suggest at least specifying a default value so developers don't need to mess with version-controlled .env
That's a good point. Most of my projects tend to ship an `example.env` which documents each env var and introduces a sane default.
When introducing the principle to projects some times a dev will complain about config drift and the like but experience in practice shows that these files tend to change a bit when introduced and then rarely at all so it really is not that much of a deal.
An easier way is to make the port range dynamic by adding a prefix variable in .env/example.env. So, once configured, the whole localdev binds to ports in the prefix range, eg: 342xx.
Experience shows that localdevs will need that env file anyway and adding this config step to the readme is quite effective.