-
Notifications
You must be signed in to change notification settings - Fork 2.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Custom Project Templates #5505
Custom Project Templates #5505
Conversation
Sorry I am not following how this is any different than the current behavior? We first look at the current app's priv dir for templates, and fallback to the phoenix ones. If this is about |
This PR only consolidates the templates into one directory, so project templates would live alongside other generator templates. I'm thinking through the changes required to support something like |
Closing this for PR now. I want to experiment more with Mix.Generator and see if I can accomplish more of my goals at once. |
@chrismccord I reverted the commits that moved the project templates, and added commits to accept a new |
for {name, mappings} <- Module.get_attribute(env.module, :templates), | ||
{format, _proj_location, files} <- mappings, | ||
format != :keep, | ||
{source, _target} <- files, | ||
source = to_string(source) do |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's hard to see from the diff, but there was a nested for
comprehension here. I merged them into one.
Thanks @type1fool! My concern is that this couples all of the generator internals and variables with user code. And any refactoring we do may break your generators. In other words, it makes all of the generator internals public. I think we should instead promote
|
Thank you for reviewing, @josevalim. I'll look for examples of packages using an |
The contact surface would be smaller. An init task has to interact with the generated files. Custom templates would interact with all generated files and all internal assigns used by |
I'm planning on revisiting this once I get some bandwidth to experiment more with modifying existing files with Mix tasks. @josevalim do you have an example of a package that does this? While I'm here, the Thinking Elixir guys discussed this topic in the latest episode: https://podcast.thinkingelixir.com/167 It seems there's an appetite to have better tools for customizing the code generated by phx_new. That could mean more documentation about using tasks or maybe the custom template path flag I'm proposing. |
I haven't forgotten about this PR. In my These tools may be sufficient to do what I want at a larger scale for client projects now that I'm more comfortable with Sourceror and Elixir's ASTs. I do think there is still an appetite in the community for customizing the project generators. All of the approaches seem to require some level of maintenance over time. |
Surface UI has an installer that mods existing files (using Sourceror) from a default |
Closing this, as the Surface approach is most likely the best way to forward. :) |
Goal
The goal of this PR is to provide better support for project customization for developers who frequently create new Phoenix projects.
Overview
Recently, I was reminded that we can customize the code produced by many of the Phoenix generators after revisiting @sasa1977's Medium blog series. While it has been possible to modify templates for most of Phoenix's Mix tasks, customizing the project file templates has proved to be more difficult.
Benefits
By allowing dev teams to customize the new project generator, significant time can be saved from adding common deps, config, CI yml, etc.
Limitations
While this PR allows non-standard files to be added to a template directory, these files are copied as-is without any EEx interpolation.
Example Usage
~/my_phx_templates
~/projects/my_app