Skip to content

[REQ] Add filesDir config option for directory-based template discovery #23877

@aegeiger

Description

@aegeiger

Is your feature request related to a problem? Please describe.

When using the files config option to add custom template files, every single file must be listed individually in the YAML/JSON configuration. For projects with many additional templates, this quickly becomes unwieldy and error-prone:

files:
  README.mustache:
    folder: ''
    destinationFilename: README.md
  validators.mustache:
    templateType: Model
    destinationFilename: .ts
  api_interfaces.mustache:
    templateType: API
    destinationFilename: Interface.kt
  api_impl.mustache:
    templateType: API
    destinationFilename: Impl.kt
  build.gradle.mustache:
    folder: scripts
    destinationFilename: build.gradle
    templateType: SupportingFiles
  # ... 20 more entries ...

Every time you add or remove a template file, you must also update the config. There is no way to say "use all files in this directory."

Describe the solution you'd like

A new filesDir config option that points to a directory. The generator scans it and auto-registers every file found, using subdirectory names to determine the templateType:

templateDir: my_custom_templates
filesDir: my_extra_templates/

Where the directory structure follows this convention:

my_extra_templates/
  README.md                        # -> SupportingFiles (root = default)
  LICENSE.mustache                  # -> SupportingFiles, output as "LICENSE"
  api/
    custom_api.mustache             # -> templateType: API
  model/
    validators.mustache             # -> templateType: Model
  apiDocs/
    api_readme.mustache             # -> templateType: APIDocs
  modelDocs/
    model_readme.mustache           # -> templateType: ModelDocs
  apiTests/
    api_test.mustache               # -> templateType: APITests
  modelTests/
    model_test.mustache             # -> templateType: ModelTests
  supportingFiles/
    build.gradle.mustache           # -> SupportingFiles
    scripts/
      check.sh                      # -> SupportingFiles, folder: "scripts"
  custom_output_dir/
    deploy.sh                       # -> SupportingFiles, folder: "custom_output_dir"

Rules:

  • Root files default to SupportingFiles
  • Recognized subdirectory names (case-insensitive: api, model, apiDocs, modelDocs, apiTests, modelTests, supportingFiles) map to the corresponding templateType
  • Unrecognized subdirectory names become SupportingFiles with the directory path as the output folder
  • .mustache suffixes are stripped from the destination filename
  • filesDir and files can be used together; explicit files entries take precedence on conflict

Describe alternatives you've considered

  1. Listing every file under files — works but doesn't scale; requires keeping config and template directory in sync manually.
  2. Writing a custom generator via meta — the processOpts() method in a custom CodegenConfig subclass can programmatically scan a directory and call supportingFiles.add(...). This works but is a massive escalation in complexity (requires a separate Java/Maven project, compilation, classpath management) for what should be a simple config option.

Additional context

The implementation is small and low-risk:

  • The change is confined to DynamicSettings.java (~80 lines of new code) — the getFiles() method is extended to also scan filesDir and return the merged list of TemplateDefinition objects
  • No changes needed to CodegenConfigurator, DefaultGenerator, TemplateDefinition, TemplateFileType, or any CLI classes — the entire downstream pipeline already works with List<TemplateDefinition> generically
  • Fully backward compatible — filesDir is optional and the existing files behavior is unchanged

I have a PR ready with the implementation, tests (5 new test cases), and documentation.

Metadata

Metadata

Assignees

No one assigned

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions