Feature request: optionally allow empty files to be generated

[izeau]

Hi there :)

I am planning on using Scaffold to generate Terraform modules boilerplate. Hashicorps recommends using a standard layout with well-known file paths that should be used even if they're empty (main.tf, variables.tf, outputs.tf). This is not a hard requirement though, as Terraform itself does not care -- it's just a convention.

Currently (v0.0.91), an empty render will result in ErrTemplateIsEmpty, which is ignored but prevents the file from being written to (as specified in the docs). While I fully understand this behavior, I would like to be able to optionally bypass this check at the scaffold level. Now the issue as far as I can tell would be introducing options in the scaffold.yaml file, which you might want to avoid to prevent feature creep.

Thank you for your work, and for your time :)

[hay-kot]

Will definitely need to think about this some more. I know I've been wanting to make some changes that could possibly break some scaffolds, so having some way to opt-into behavior may be necessary.

In the mean time, adding comments to the files so they always have content or if they aren't templates, adding them to the skip list would always copy them (I think)

[izeau]

Adding Terraform comments is what I have been doing in the meantime.

By the way, there is a strange output if the template only contains only gotemplate comment and whitespace (e.g if it's only {{/* ... */}}): the resulting file contains its own path.

.scaffold/terraform-module/scaffold.yaml

questions:
  - name: module_name
    required: true
    prompt:
      message: name

computed:
  module_dir: "infrastructure/modules/terraform-aws-{{ .Scaffold.module_name }}"

rewrites:
  - from: templates/main.tf
    to: "{{ .Computed.module_dir }}/main.tf"

.scaffold/terraform-module/templates/main.tf

{{/* test */}}

infrastructure/modules/terraform-aws-example/main.tf

infrastructure/modules/terraform-aws-example/main.tf

[hay-kot]

Super weird, found the issue there - fixed in #138. Thank you!

[izeau]

@hay-kot should this issue be closed now that #167 provides a workaround with less moving parts?

[hay-kot]

Sounds good, thanks for your work on this one!