# `mix rupa.gen.struct`
[🔗](https://github.com/zero-one-group/rupa/blob/v0.1.0/lib/mix/tasks/rupa.gen.struct.ex#L1)

Writes the struct modules a schema's `into:` options name.

    $ mix rupa.gen.struct MyApp.Schemas.user
    * creating lib/my_app/user.ex
    * creating lib/my_app/address.ex

The argument names a zero-arity function in your own project that returns a schema. The task
compiles the project, calls it, stages the schema, and writes one file per `into:` module it
finds — the root's and every nested one — at the path that module's name conventionally has
under `lib/`.

What it writes is a `defstruct` and a `@type t`, and nothing else: no `use`, no import of
Rupa, no behaviour. The file is yours from the moment it lands. Re-running the task shows
what a change to the schema would write, and `--force` is how you take it.

Staging is what makes the keys right. They are the names after `rename_all:`, `from:` and
`keys:` have been spent — the keys `Rupa.decode/3` will actually put in the struct — so the
generated module is the one `Rupa.compile/2` will accept rather than one that looks close.

## Options

  * `--force` — overwrite files that already exist. Without it, they are left alone and
    reported.
  * `--dry-run` — print what would be written, and write nothing.

## The gap it closes

`into:` is a soft dependency: `Rupa.compile/2` refuses a schema whose struct module is not
loaded, or is missing a key the object decodes to. So the loop is to change the schema, run
this, and commit both.

---

*Consult [api-reference.md](api-reference.md) for complete listing*