Extracted from #573 (comment)

I think this, and the upcoming bases feature #388, would allow the user to choose either to prefer, (1) readability of release template expressions #439, or (2)less number of files involved.

Let's say we have a legacy helmfile.yaml below:

helmfile.legacy.yaml:

environments:
  {{ .Environment.Name }}:
    values:
    - environments/{{ .Environment.Name }}/values.yaml

releases:
- name: {{ .Environment.Values.releaseName }}
  values:
  - releases/{{` {{.Release.Name }} `}}/values.yaml

This can be reimplemented with bases like this:

base.yaml:

environments:
  {{ .Environment.Name }}:
    values:
    - environments/{{ .Environment.Name }}/values.yaml

helmfile.legacy2.yaml:

bases:
- base.yaml

releases:
- name: {{ .Environment.Values.releaseName }}
  values:
  - releases/{{` {{.Release.Name }} `}}/values.yaml

bases and the selective whole-file templating, we can reimplement these with:

base.yaml.gotpl:

environments:
  {{ .Environment.Name }}:
    values:
    - environments/{{ .Environment.Name }}/values.yaml

helmfile.new.yaml:

bases:
- base.yaml.gotpl

releases:
- name: '{{ .Environment.Values.releaseName }}'
  values:
  - releases/{{.Release.Name}}/values.yaml

Notice helmfile.new.yaml is a valid YAML, but you can still use Release Template #439 in name and the values item to dynamically generate their values.

This may eventually be a breaking-change, as your helmfile.yaml won't work after this change.

But we can defer the breakness until helmfile v1. In the meantime, we can just required .v1 ID in file names, like helmfile.v1.yaml to enable this mode.

helmfile.v1.yaml is indeed verbose so deprecating it in helmfile v1 and making the helmfile.yaml defaults to a regular YAML file would be necessary in the end.