Add extends keyword to simplify overrides

[smeijer]

Feature Request

Add an extends keyword to the config files, to simplify running with overrides.

I'm currently using multiple compose files in a monorepo, so often deal with overrides, or completely separate configs. Ideally the user running the configs shouldn't need to know if I have configured a certain environment trough overrides, or as standalone config.

Think of:

• a base config that runs database services
• an override that runs services needed by the backend team
• an override that runs services needed by the frontend team
• an override to run backend team and frontend team services combined
• a separate config to run packages/apps that only need to run when working on that, say a documentation site

So in a perfect world, I'd have something like:

• process-compose up -f process-compose.backend.yaml
• process-compose up -f process-compose.frontend.yaml
• process-compose up -f process-compose.docs.yaml

Use Case:

Simplify running with overrides, by only needing to specify one config file, instead of the proper inheritance.

Proposed Change:

Having these two compose files:

# ./process-compose.yaml
version: "0.5"

processes:

# ./process-compose.prod.yaml
version: "0.5"
extends: "./process-compose.yaml"

processes:

The following commands would be the same:

# current
$ process-compose -f process-compose.yml -f process-compose.prod.yml

# proposal
$ process-compose -f process-compose.prod.yml

Totally optional, but it could even be extended further, using the filename convention, to run it based on the override name only, like:

$ process-compose -f prod # expand to (process-)compose.prod.{yml,yaml}

Who Benefits From The Change(s)?

Anyone using overrides.

[F1bonacc1]

Hi @smeijer,

I have a question on the proposal:
Should extend specify a path relative to itself (the extending process-compose.yaml file) or the current working directory (like the -f flag does today)?

[smeijer]

I'd suggest to make the behavior the same as the extends in for example typescript config. Meaning, all relative paths will be resolved relative to the configuration file they originated in.

Having the cli parse arguments relative to the cwd, makes total sense and is in that same line of thoughts.

So if you're having two files, one in the root and one nested, both files resolve paths relative to themselves, even when they're spawned in a single command. That includes the extends (and any other) property.

[F1bonacc1]

Added in v1.40.0
@smeijer please let me know if it works as expected.
Documentation.