mix phoenix_kit.post_install (phoenix_kit v2.13.18)

Copy Markdown View Source

Runs the PhoenixKit install steps that must happen AFTER the installer's file changes have landed on disk.

mix phoenix_kit.install queues this task with Igniter.add_task/3 rather than doing the work in its own run/1. That distinction is load-bearing: the entry point our docs recommend, mix igniter.install phoenix_kit, never calls the installer's run/1 at all. Igniter composes installers through Igniter.Mix.Task.configure_and_run/3, which invokes the task's igniter/1 callback and nothing else — so work parked in run/1 silently does not happen on the recommended path. A queued task runs on both paths, and is skipped on --dry-run, where running a migration would be wrong.

Steps

  • offer to run mix ecto.migrate (interactive terminals only — skipped under CI or with no TERM, with a note saying why)
  • rebuild assets, unless --skip-assets

Both shell out to a fresh mix process on purpose: the install just rewrote config/config.exs, and this VM still holds the configuration it booted with.

Options

  • --prefix SCHEMA — the PostgreSQL schema the install targeted
  • --skip-assets — skip the asset rebuild

Normally invoked for you. Running it by hand is safe and idempotent: it re-reads the migration state from disk and offers the same choices.