svelixir_new

# svelixir_new

The zero-dependency bootstrap archive for [Svelixir](https://github.com/wimwian-org/svelixir).

```sh
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.

```elixir
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

```sh
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`.