8a3e6f81

Carry a codec's comments into the option it generates

A comment written with `<?>` or `<??>` was thrown away when a field became a Nix option, so only the field's own description survived into `lib.mkOption`.

That is the wrong half to keep for a shared type. A field says what it is for where the field is; a type says what it means where the type is. Whoever reads the NixOS module generated from the codec wants both, and documentation written on a codec reached the rendered configuration documentation while silently never reaching the module.

## What changed

`objectCodecNixOptions` now builds each option's description from the field's own description followed by the comments on the codec under it, outermost first, joined by newlines.

```haskell
requiredFieldWith "issuer" (codec <?> "more about it") "the issuer"
```

```nix
issuer = lib.mkOption {
  description = "the issuer\nmore about it";
  type = lib.types.str;
};
```

It descends through a `BimapCodec`, as `valueCodecNixOptionType` already does, because a codec written for one type in terms of another is still that type's codec. It does not descend into an `EitherCodec` or an `ArrayOfCodec`, whose comments are about something the option is made of rather than about the option itself.

## Compatibility

Generated output changes for any codec that has a comment on a field's value codec, so downstream golden files move. Nothing in this repository's own goldens changed, which is why the new `CommentedFields` fixture exists: it covers a required field, an optional one, one with an omitted default, and one with a comment and no description of its own.

A field with a comment and no description now has a description where it had none at all.

`autodocodec-nix` goes to 0.1.1.0.

Total

13m22s

Created 2 weeks ago Started 2 weeks ago Finished 2 weeks ago

Timeline