although I’m a fan of including tailwind, I also acknowledge the criticism… and really like the “gen” idea..
to further complicate the “gen” idea - I feel like it would be also great to have gen “heroku”/“buildpacks” (buildpacks used by various paas platforms,dokku etc), and a gen “docker” (and possibility for others, even react/vue etc down the line)
or the very least include those future requirements, in however the gen “tailwind” solution is crafted..
This is what I imagined too, sort of. I imagined that someone would run phx.new and then run a series of tasks that had been installed locally, e.g.:
mix phx.new my_app --live
cd my_app
mix phx.add.tailwind
mix phx.add.alpine
I wrote up something last night just to see how this might work. I put in on GitHub just as a talking point (not as an example of what I would recommend or a good implementation underneath).
Note I specifically called it “add” and not “gen” only to distinguish it from generators that are part of Phoenix proper or otherwise “official.”
Thinking about this further, I might instead want something like:
mix phx.custom my_app --live --tailwind --no-ecto --alpine
Where this task parses the options, runs phx.new with the applicable options, and then runs locally archived tasks similar to the first example for the other options. Of course phx.new could do the same thing at some point.
That preserves access to the options that were specified when the stock app was created, which can be helpful. For example, there are some changes that need to be made to app.js for Alpine to work in Live View apps, that aren’t necessary otherwise. It would also give all of the custom generators access what other generators were included and in what order. Theoretically then, if you knew that a generator conflicted with another one, you (or the generator author) could handle that. Which is not to say it isn’t still all brittle.
One problem with this is for generators that have their own arguments (like phx.gen.auth). That could be messy. I suppose you could use prompts as one solution, or you could allow a file to be specified with a list of custom generators and installation switches. I don’t know that I love either of those ideas.
I used to think that too until I started consulting an agency, and what I saw made me change my minds. My clients start new projects fairly frequently. They want to keep the different projects technically as similar as possible to each other (language, frameworks, libraries, CI/CD). When I started working with them they have already built their own custom generator which expanded on phx.new generating some custom stuff (like e.g. deploy pipeline).
One of my main tasks has been introducing common Elixir style & practices to their projects, with the purpose of assisting with project switches. A company-wide custom generator has been indispensable in making this happen, so I’ve spent significant amount of time expanding it. Examples of simpler things we’re doing include generating our own custom credo configuration, or setting up default CI checks (formatter, credo, dialyzer, migrations reversibility, OTP release).
In addition, the generator also performs some more complicated changes on top of phx.new, such as moving db/endpoint configuration to init callbacks, renaming some files, most notably everything under the web folder, together with renaming corresponding modules. Changing some configurations in config scripts, etc. Such changes are made using a hacky combination of regex search & replaces, file operations (e.g. rename), or in some cases by completely overwriting the generated files.
It all feels fragile, and I sometimes wonder if we should completely part ways with phx.new and generate everything ourselves. However, the main challenge is that it’s unclear what exactly should be done to add different layers of Phoenix to the existing non-Phoenix project. Last time I was doing that, I invoked mix phx.new my_existing_project in /tmp, then copied that over the existing project, and carefully analyzed git differences, which was far from perfect. Moreover, once such generator is built, I fear that upgrading it to the next Phoenix is going to be much harder.
A comprehensive step-by-step guide explaining how to add Phoenix to existing project to existing project might be of great help here. I’d expect such guide to cover various scenarios, starting with the basic API, and then expanding with HTML, LiveView, and webpack, and of course including recipes for std configuration (e.g. dev-only live reload, debug errors, etc.). Understanding the changes between two Phoenix version could then amount to diffing the guides, which should be easier to comprehend than diff of the generator project.
Other than that, I’m not really sure what kind of support could be offered by the core generators to simplify the kind of changes we’re doing.
