SvEx.
The :api project preset — priv/templates/base_api_app.exs as code.
A Phoenix project with no HTML and no asset pipeline: mix phx.new --no-html --no-assets. Measured against base_web_app.exs the whole difference is
three values — assets.type and the two assets.ui flags — because both
presets are project.type: :web.
That pairing is where SvEx.Config's moduledoc shorthand "base: is
project.type" stops holding. It is true of :otp and :web by coincidence
of their presets, not by construction: base: names a preset that read!/1
dispatches on, and this one resolves to a :web project exposing only an API
surface.
Not the api COMPONENT. That one adds open_api_spex, grpc, hammer
and a rate limiter — an API surface on a project that already exists. This
is Phoenix generated without HTML. They occupy different keys in
target.exs, base: and plugins:, so nothing collides mechanically;
one word meaning two things is a naming decision left open deliberately.
This is a builder, not a struct. It returns %SvEx.Config{}; there is no
%SvEx.Config.Api{}.
Summary
Functions
Builds an :api config, with overrides merged over the preset.
The values this preset supplies, before any override.
Functions
@spec new!(keyword() | map()) :: SvEx.Config.t()
Builds an :api config, with overrides merged over the preset.
Overrides recurse to the leaf, so naming one key in a section keeps the rest of that section's preset values.
@spec preset() :: keyword()
The values this preset supplies, before any override.