The most-used component a documentation theme is missing: one API parameter,
with more explanation than a table row holds.

## Usage

::preview
:::field{name="showRepo" type="boolean" default="false"}
Force a repository segment even with a single repository.
:::

#code
```mdc
::field{name="showRepo" type="boolean" default="false"}
Force a repository segment even with a single repository.
::
```
::

## API

### Props

| Prop       | Type      | Default | Notes                              |
| :--------- | :-------- | :------ | :--------------------------------- |
| `name`     | `string`  | —       | The parameter's name, in mono      |
| `type`     | `string`  | —       | Drawn beside it, in mono           |
| `default`  | `string`  | —       | Right-aligned, as `= value`        |
| `required` | `boolean` | `false` | Draws a badge instead of a default |

### Slots

| Slot      | What goes in it              |
| :-------- | :--------------------------- |
| `default` | The description, as Markdown |

## Notes

A definition list would be the semantic choice and is the wrong one here: the
name, the type, the default and whether it is required are four different things,
and `<dt>` gives them one slot between them.

A table stays the better choice for a long list of one-line fields — see
[Sources](/reference/sources), where eight fields are meant to be compared at a
glance rather than read one by one.