Adding `--tailwind` flag to phx.new

[dbern]

@josevalim

While this approach doesn’t necessarily address point 1, because this type of code will always be brittle, it pretty much does better in all other points mentioned above. The beauty of phx_new_tailwind is:

1. Is its own project, with proper structure, and hopefully tests
2. Has its own command, which means it has a proper place to document all of its options and behaviour (something you don’t get with application templates iirc)

Wonderful! This phx_new_tailwind may need to pin itself against versions of Phoenix to ensure compatibility since Phoenix generates with foo (for example Webpack) by default, but I don’t see that as a huge problem.

The unfortunate part about separate projects like this is that it requires more instruction to the user and has less visibility.

• re: visibility: If there is a family of generators like this, it would be helpful to have a section on the Phoenix readme/guides that points to these generators since they’re potentially important to the user when starting a project, so they don’t run mix phx.new before they realize these other starters are available.

• re: user instruction: if the user is expected to run mix phx.new first and then mix phx.new.tailwind, then that’s adding more friction to these generators that flags like --live don’t have. I’m not suggesting those flags also be separated; just saying that experience is nicer to new users. An alternative is to have the user only run mix phx.new.tailwind, which passes original flags onto mix phx.new and then proceeds to add its own templates and adjustments.

If you have implementation suggestions, I’d love them. Like I said in the original post, I’d love to work on this feature. Thanks for your thoughts!

---

separately, I found a need to see the diffs between generated Phoenix projects. Anyone know of a tool that shows these? Something like http://railsdiff.org. I’d like to add support for these in https://diff.hex.pm somehow.