Phoenix Application Template customization

[chulkilee]

@cnck1387

@chulkilee

Elixir/Phoenix has less convention and more flexibility on organization than Ruby/Rails

It’s not too too different right?

Please note that Rails use autoload, and expects specific file name and structure for ruby classes - while Phoenix does not do that for elixir modules.

---

@cnck1387

@chulkilee

It would be better if you provide more concrete example

Of what? I think the Rails application template design is close to as good as it gets for creating such a thing. It’s all there to take inspiration from and potentially improve upon.

What is a “thing”? That’s what we need to discuss to capture our needs, before making something.

For example, steps in the following list is not Elixir-specific actually and thus it doesn’t need something from Elixir.

@cnck1387

It let you build templates by writing code like:

initial_commit
update_gitignore
copy_gemfile
copy_base_favicon
add_dotenv
add_procfile
add_markdown_readme
add_license

# ... 30 other things to supply a bunch of opinionated app decisions.

And then there were tons of helper functions provided by Rails to help you inject code at specific points in files and copy files from A to B.

---

Let me give my user stories and my decisions, for your information. It would be helpful you describe your cases in more details, other than "

• I want to add oban to new or existing project for background processing, which requires probably 20 lines of changes.
  • Can I automate it? Mostly yes, but adding supervisor new supervisor to the main supervisor is tricky…
  • Will it be worth to automate it? For new project - it’s small (since files are not changed) but it’s not worth to make it work on existing projects.
• I maintain a few projects, having slightly different dependencies (e.g. postgresql / oban / kafka / channel…). How can I ensure they have up-to-date convention/config easily?
  • Is it ever solvable problem? Unless I make another abstraction (e.g. having own library), it’s kind of writing a program to read and rewrite a program like me. I think that’s not easy right now.
• We have lots of non-elixir specific common files (CI config, docker config, issue template, githook, commit lint)
  • Should I manage them with Elixir project generator? Maybe for some (like docker) but most are language/tool agnostic so I don’t want to manage them with Elixir generator.

---

Don’t get me wrong - I’m not saying such project generator or application template is meaningless. Instead, I’d like to have good ecosystem, where we have right tools at right level - such as Elixir provides easy way to manipulate code and emit formatted code, and then we can have community tools around it.

But to have right tools at the right layer, we need to know what the actual user stories are (going back to that discussion)

---

BTW I wish we have language-agnostic tools for language agnostic tasks. For example, we may have a language-agnostic tool to run such steps, calling language/framework specific steps - and each language provides building block so that step authors can use good APIs (may vary by language though). (oh… it reminds my previous bash script - I have one for rails and another for elixir…)

I’m just not happy to have package.json to use changelog generation (standard-version), git hooks (husky), commit message convention check (@commitlint/cli)

---

On exgen - @cdegroot gave a talk about using exgen in PagerDuty in 2019 to start new project ready to deploy (e.g. having all CI/CD config).