Enhancement: Improving the generators for greater flexibility

[crimson-knight]

Description

Generators are powerful conveniences for being productive. Amber has a good foundation but we can improve it to allow for greater customization for maturing projects.

Example:

1. I have 2 different 'base' classes that I'm using for my models, maybe one for a legacy database and one for the new database. The current generators wouldn't allow me to customize the fields that would be injected into the model template if I were to run amber g model. This isn't a big problem but it's inconvenient.
2. It's common for growing applications to have patterns that need to be applied to new controllers, maybe authorization logic in a before_action, changing the parent inherited controller or even just being able to pass in the folder (relative to app/controllers to put the new file into).
3. I often find a code base will have it's own patterns for domain-specific behavior. It's just not possible to create a template and use a generator now.

Here is how I want to change the existing generator behavior:

1. Looks inside of the current project folder for a .amber/generators/**. The sub-directory name is the name of a generator that can be used. So .amber/generators/model would overwrite the default amber g model generator. Doing .amber/generators/custom_service would add a custom generator for custom_service.
   1 (a). The convention here is the generator name is the singular form. ie model not models, because you're generating a single version of your new template.

2. Inside of the new sub-folder, the first file that's expected is a .yml or .json file that is named the same as the sub-directory. So .amber/generators/custom_service would contain a file called custom_service.yml or custom_service.json that describes the patterns for the file to be created.

The yaml file will include a minimum of the following information:

# Required
folder_name: custom_services

# Required
relative_to: app/

# Required, should be inside of the `custom_service` sub-folder
template_file: custom_service_template.txt

# Required, tells the generator what extension to put onto the newly created file.
template_file_extension: .cr

# Required, anything in the double-curls will be lowercase substituted to name the newly created file
template_naming_convention: {{name}}_service

# Anything inside of this tag will be matched to a variable in the template and substituted
parts:
  # Nest in your custom parts. Do not nest any deeper than this one key. Anything double nested will just be ignored.

The template_file doesn't have to be a specific extension because these files are not compiled. So you could use these generators to build js templates, controllers, background jobs, specs, etc.

Our internal generators should follow the same principles to make everything consistent.

Expected behaviors for overwriting the default generators

1. The customized aspects do not need to overwrite all of the default values. Anything not overwritten will still use the defaults.
2. We should add a --template parameter for the existing generators that will copy the entire configuration that is used by default into the .amber/generators folder (or create it if it doesn't already exist). So doing amber g model --template would not create a model, but it would create the generator template files.

Expected behavior for custom generators

1. Raise errors for any missing and required configuration fields. Ensure the error messages are helpful and specific.
2. Put warnings into the console, but still complete the operation if there are configuration options that are not used, or are defined incorrectly.

Expectation for all generators

1. Allow the templates to define calling other generators, or generating multiple templates. ie generate a spec in spec in addition to a file generated in app/.

I've been thinking over how to do this for a long while. The PR for doing this is going to be fairly large, even if it's just focusing on enabling the custom generators to start. Cleaning up our CLI generators is going to be a big quality of life improvement though!