YES - easy to configure generators could have a big impact. For example: look at the complexity of installing LiveView. Right now, install-by-hand is the only option. Writing a generator for LV installation would not be easy to write or maintain, nor would a LV-install generator be easily customizable in the field.
The only generator alternative I’m aware of are PragDave’s project generator. (An Elixir Project Generator). I do use the PragDave generator, in conjunction with a set of bash scripts - it’s devolved into a spagetti-mess that is hard to maintain and impossible to share.
It’s a bit difficult to articulate exactly what the properties of a flexible/composable generator should be. Maybe you could start by enumerating use cases:
- installing LV in a phoenix project
- installing an authentication system in a phoenix project
- replacing Milligram with Bootstrap4 (or some other CSS framework) in a phoenix project
- finding the right generator for my needs
- customizing and re-publishing a generator
- etc.
Probably you could list desirable properties of a flexible generator:
- creating new project from scratch, or modifying an existing project
- supports both ‘bash’ (or exs) style scripting and template generation
- ability to nest and/or ‘subclass’ generators
- generators separated from their underlying application code
- simple to share & reuse generators
- works with both ‘umbrella’ and ‘poncho’ style layouts
- idempotency
- testable
- interoperable with mix
- etc.
One approach might be to borrow concepts from Ansible:
- a library of prebuilt generator functions like
template
,line_in_file
andensure_path
playbooks
as elixir modules or some sort of ExUnit like DSL- collections of playbooks published as HEX packages
- …
It would be great to have a chunk of generator code that looked like:
generator_context
|> phx.new()
|> live_view.install()
|> auth_system.install()