svelixir_new

Copy Markdown

The zero-dependency bootstrap archive for Svelixir.

mix archive.install hex svelixir_new
mix svelixir.new NAME --base otp|web --github-org ORG [--svelixir-path PATH]

This is perimeter 2: a standalone Mix project with its own git repository, checked out at priv/svelixir_new inside the Svelixir repo and gitignored by it. It is not a dependency of the svelixir package and the svelixir package is not a dependency of it. They meet in exactly one place — an integration test asserting the svelixir.exs this archive writes is readable by Svelixir.Config.

Every dependency carries an only: that excludes :prod, so the published package has an empty requirements list and the built archive ships no dependency BEAM. only: is the discriminator, not runtime: false: {:jason, "~> 1.4", runtime: false} with no only: still emits a full requirement entry.

Post-MVP continuation — verified working, deliberately NOT implemented

Once mix svelixir.gen exists in the hex package, Mix.Tasks.Svelixir.New continues with this sequence. It is recorded here rather than in the task's @moduledoc because Svelixir.BoundaryGuard substring-scans priv/svelixir_new/lib/**/*.ex — documentation and comments included — and two of these four calls are on its banned list. Prose that names a banned API is indistinguishable from a call to it, by design: the guard exists because a rule expressed only in prose rots.

File.cd!(target)
Mix.Project.pop()
Code.compile_file("mix.exs", ignore_module_conflict: true)
Mix.Task.run("svelixir.gen", argv)

All four steps are required and were verified at Elixir 1.20.3.

  • Mix.Project.pop/0 is mandatory when a project is on the stack, and a harmless no-op returning nil when none is. Omitting it produces a state that looks correct and then fails at deps.compile with "cannot retrieve dependencies information".
  • The process must stay changed into the target directory for the rest of the run, because compile_path/0, deps_path/0 and build_path/0 re-expand against the current working directory on every call.
  • Mix.Task.get/1 is not a valid probe for the delegated task: it returns nil while Mix.Task.run/2 on the same name succeeds, because run/2 triggers loadpaths first.

Running this today buys nothing — svelixir.gen does not exist — and deps.compile prunes every archive off the code path before it could.

Development

mix deps.get
mix test

The full gate for both perimeters is bin/check at the root of the Svelixir repo, which runs this project's gates too when this directory holds a mix.exs.