interpolation is ran after merge, so that a required missing variable, which is actually overridden, won't produce an error.
This is an alternative implementation based on https://github.com/compose-spec/compose-go/pull/644:
This PR always run interpolation applying extends and include, but only on the relevant configuration structures. Global interpolation eventually takes places after merge
This has a minor impact on the loading process and schema: as we don't interpolate, we can't rely on a canonical model to enforce unicity after compose file merge, and doing so compose-spec schema uniqueItem constraint must be removed. This one anyway is just a syntactic sugar AFAICT that has no real impact on usability. From an IDE point of view, while obvious duplicate can be detected by schema, the non-obvious ones (like ports: ["8080", "${PORT}"] can't, and we still have to implement unicity check by the code
interpolation is ran after merge, so that a required missing variable, which is actually overridden, won't produce an error.
This is an alternative implementation based on https://github.com/compose-spec/compose-go/pull/644: This PR always run interpolation applying
extends
andinclude
, but only on the relevant configuration structures. Global interpolation eventually takes places after mergeThis has a minor impact on the loading process and schema: as we don't interpolate, we can't rely on a canonical model to enforce unicity after compose file merge, and doing so compose-spec schema uniqueItem constraint must be removed. This one anyway is just a syntactic sugar AFAICT that has no real impact on usability. From an IDE point of view, while obvious duplicate can be detected by schema, the non-obvious ones (like
ports: ["8080", "${PORT}"]
can't, and we still have to implement unicity check by the codeclose https://github.com/docker/compose/issues/11925