# `MontyCad.Gen`
[🔗](https://github.com/d-led/ex.monty.cad/blob/main/lib/monty_cad/gen.ex#L1)

The shared half of the code generators: what a plugin is called, where it goes,
and that what is written is formatted.

A generator that writes unformatted code teaches the wrong thing on its first
line, so every source here goes through the formatter before it is written. A
generator that writes into the wrong namespace is worse: the module would be
in this package's namespace while the plugin belongs to the application that
asked for it, so the namespace comes from the project's own `:app`.

# `file_path`

```elixir
@spec file_path(module()) :: Path.t()
```

Where the module's source goes.

# `format`

```elixir
@spec format(String.t()) :: String.t()
```

One source as the formatter leaves it.

# `module_name`

```elixir
@spec module_name(String.t()) :: {:ok, module()} | {:error, String.t()}
```

The module a plugin name becomes, in the host application's namespace.

`follow_chamfers` in an application called `my_agent` is
`MyAgent.Plugins.FollowChamfers`.

# `module_name!`

```elixir
@spec module_name!(String.t()) :: module()
```

The module a plugin name becomes, or the reason it is not a name.

# `namespace`

```elixir
@spec namespace() :: String.t()
```

The application this generation is for, as a module prefix.

# `test_path`

```elixir
@spec test_path(module()) :: Path.t()
```

Where the module's test goes.

# `write!`

```elixir
@spec write!([{Path.t(), String.t()}]) :: [Path.t()]
```

Writes the files a generator made, and answers the paths it wrote.

An existing file is refused rather than overwritten: a generator run a second
time by mistake would otherwise take the decisions the first run's owner has
since written into it.

---

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