I’ve been doing a lot of prototypes in Phoenix lately. After doing the same annoying things over and over after each invocation of $ mix phx.new blah I ended up with script to bootstrap a new app the way I like it. I’m sure many have done this and was wondering if others had scripts to share. Or perhaps there is a library I’m missing to better define this stuff? https://phx.new/ does not do it for me. I’d love to see your scripts or get feedback on mine (I’m no shell expert).
The things I always do are:
Tell ecto to use utc_datetime_usec for timestamps
Use binary ids for primary keys
Create a custom Schema module for setting said primary keys as well as use and import the usual stuff
Remove page controller and associated files
Remove other boilerplate (phoenix css, phoenix logo)
Create a HomeLive LiveView (I pretty much always have a HomeLive to start which maybe gets renamed later)
Here’s my script:
#!/usr/bin/env bash
function snake_to_pascal {
echo $1 | perl -pe 's/(?:\b|_)(\p{Ll})/\u$1/g'
}
mix phx.new "$@" --binary-id
cd "$1"
# Delete page controller
rm "lib/$1_web/controllers/page_controller.ex"
rm "test/$1_web/controllers/page_controller_test.exs"
# Delete templates
rm "lib/$1_web/templates/page/index.html.heex"
rmdir "lib/$1_web/templates/page"
# Delete view
rm "lib/$1_web/views/page_view.ex"
# Remove header from the root layout
sed -I '' '13,27d' "lib/$1_web/templates/layout/root.html.heex"
# Remove getext thing (if it's there)
sed -I '' '10s/.*/ compilers: Mix.compilers(),/' mix.exs
# Remove CSS
rm assets/css/phoenix.css
echo > assets/css/app.css
# Use utc_datetime_usec in migrations
subt="s/pool_size: 10/pool_size: 10,\n migration_timestamps: \[type: :utc_datetime_usec\]/"
sed -I '' "$subt" "config/dev.exs"
sed -I '' "$subt" "config/test.exs"
# Setup a HomeLive
sed -I '' 's/get "\/", PageController, :index/live "\/", HomeLive, :index/' "lib/$1_web/router.ex"
mkdir "lib/$1_web/live"
module=$(snake_to_pascal "$1")
cat <<EOF > "lib/$1/schema.ex"
defmodule ${module}.Schema do
defmacro __using__(_) do
quote do
use Ecto.Schema
import Ecto.Changeset, warn: false
@timestamps_opts type: :utc_datetime_usec
@primary_key {:id, :binary_id, autogenerate: true}
@foreign_key_type :binary_id
end
end
end
EOF
cat <<EOF > "lib/$1_web/live/home_live.ex"
defmodule ${module}Web.HomeLive do
use ${module}Web, :live_view
def render(assigns) do
~H"""
<h1>${module}</h1>
"""
end
end
EOF
# Delete phoenix logo
rm priv/static/images/phoenix.png
# Use the heex formatting plugin
cat <<EOF > ".formatter.exs"
[
import_deps: [:ecto, :phoenix],
plugins: [Phoenix.LiveView.HTMLFormatter],
inputs: ["*.{heex,ex,exs}", "priv/*/seeds.exs", "{config,lib,test}/**/*.{heex,ex,exs}"],
subdirectories: ["priv/*/migrations"]
]
EOF
I realize this is coming hot on the heels of the next phoenix release so these could end up changing a little. But I’m glad I didn’t take the time to make this thing add tailwind!
If you don’t want the database you can do $ mix phx.new --no-ecto. Otherwise I don’t fully know what you have in mind but I assume you would want to uncomment the /api routes in the router and set up some common controllers?
Thanks. My Phoenix app probably has the most minimal dependencies possible: it’s a “redirect server”. I have all my old domain names pointed to it, and it saves my Pagerank/SEO by replying with 301’s to the current locations. It doesn’t even need JSON. The log looks like this:
01:41:56.084 request_id=FxiUHVktYMUpJhcAMZiB [info] GET /ors/167.347
01:41:56.084 request_id=FxiUHVktYMUpJhcAMZiB [info] Sent 301 in 51µs
01:42:01.986 request_id=FxiUHrju6IcV6nYAMZiR [info] GET /
01:42:01.986 request_id=FxiUHrju6IcV6nYAMZiR [info] Sent 301 in 63µs
01:42:06.529 request_id=FxiUH8fF40HTccUAMZih [info] GET /ors/609.020
01:42:06.530 request_id=FxiUH8fF40HTccUAMZih [info] Sent 301 in 78µs
01:42:08.381 request_id=FxiUIDYk7rKSDOwAMZix [info] HEAD /
01:42:08.381 request_id=FxiUIDYk7rKSDOwAMZix [info] Sent 301 in 47µs
It’s great because it uses just 200MB of RAM and 0% CPU. I have it on a server with my other apps, so hosting is free. It’s very flexible and testable.
I too wish we had flags for starting projects like this. Hell, with the advent of tools like treesitter I’d even try my hand at devising scripts that can modify existing projects.
Alas, the pesky bills always keep coming and nobody will pay you to do such work.
You probably would be better served by a Plug project. You start off with much less deps and you can opt-in to anything you need from Phoenix, piecemeal.
It’s slightly more tedious to do but it still took me an afternoon and that project has been rock-solid for no less than 2 years now, doing its stuff on a VPS. I only invested another several hours when I wanted to add some metrics a few months ago.
I have the same feeling. I’m now starting a third project this year, and every time after running phx.new I have the same reaction: “now what?” Oh, right: clean out views and layouts, remember how to tie layouts together for a live view, add seeds and repo details,… and a thousand of other small things
Too bas these small things are different for different people, otherwise it would be nice to have them done by the generator
A bunch of them, yes, but I haven’t worked that into the script yet. There are some I think are useful to leave if it was expecting to grow, although I’ve never started such a project on my own before.
I usually do this manually, because I change some naming convetion and organization on phoenix apps.
But I guess this automatic cleanup as your script does, would be cool.
I think it could even be mix task on phoenix… mix phx.clean_examples or something like that.
The next step would be to use something better than a shell script. I’m half trying to gauge how a big a pain this is for people and if it’s worth writing something a little nicer with options. Something like Rails’ bootstrapping templates would be nice (although I never actually used those).
OCaml and Racket are excellent if you want produce other DSLs so yeah, shell scripts would only be a first crippled prototype and nothing else. OCaml would be my first stop. They have a ton of libraries dealing with parsing and transforming stuff.
But that requires good tooling around parsing the languages themselves into a structured and well-standardized AST – and not necessarily the one their own compiler / runtime uses, too. And some languages, Elixir included, don’t have a standardized AST at all so this is still an area that the community must one day step up to fix.
Oh, right: clean out views and layouts, remember how to tie layouts together for a live view, add seeds and repo details,… and a thousand of other small things
