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
- Listing every file under
files — works but doesn't scale; requires keeping config and template directory in sync manually.
- 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.
Is your feature request related to a problem? Please describe.
When using the
filesconfig 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: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
filesDirconfig option that points to a directory. The generator scans it and auto-registers every file found, using subdirectory names to determine thetemplateType:Where the directory structure follows this convention:
Rules:
SupportingFilesapi,model,apiDocs,modelDocs,apiTests,modelTests,supportingFiles) map to the correspondingtemplateTypeSupportingFileswith the directory path as the outputfolder.mustachesuffixes are stripped from the destination filenamefilesDirandfilescan be used together; explicitfilesentries take precedence on conflictDescribe alternatives you've considered
files— works but doesn't scale; requires keeping config and template directory in sync manually.meta— theprocessOpts()method in a customCodegenConfigsubclass can programmatically scan a directory and callsupportingFiles.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:
DynamicSettings.java(~80 lines of new code) — thegetFiles()method is extended to also scanfilesDirand return the merged list ofTemplateDefinitionobjectsCodegenConfigurator,DefaultGenerator,TemplateDefinition,TemplateFileType, or any CLI classes — the entire downstream pipeline already works withList<TemplateDefinition>genericallyfilesDiris optional and the existingfilesbehavior is unchangedI have a PR ready with the implementation, tests (5 new test cases), and documentation.