Support inline record fields in doc extraction

[zth]

Closes #887

I've also removed all of the JSON decoding code, because with untagged variants we can just map to the result zero cost, which is a lot easier to maintain.

cc @aspeddro

[woeps]

Removing the JSON decoding code let a bug surface: type item in Tools_Docgen.resi defines

Module({
  id: 
  docstrings: array<string>,
  deprecated?: string,
  name: string,
  items: array<item>,
})

having docstrings not being optional, but the generated json (by analysis binary) does not contain the docstrings field for module items.

I believe, I found the issue in DocExtraction.ml#L156-166:

  | Module m ->
    stringifyObject ~startOnNewline:true ~indentation
      [
        ("id", Some (wrapInQuotes m.id));
        ("name", Some (wrapInQuotes m.name));
        ("kind", Some (wrapInQuotes "module"));
        ("docstrings", Some (stringifyDocstrings m.docstring));  (* THIS LINE IS MISSING! *)
        ( "items",
          Some
            (m.items
            |> List.map
                 (stringifyDocItem ~originalEnv ~indentation:(indentation + 1))
            |> array) );
      ]

which doesn't stringified the docstring field yet.

[zth]

@woeps perfect, I'll fix it!

[zth]

@woeps can you test the latest commits?

[woeps]

@zth This field name (constructorPayload) is not matching the field name given in stringifyDetail in DocExtraction.ml (items).
If I'm not mistaken, both names need to be identical: either items or constructorPayload.

edit:
Just tested it locally: Yes, if I change the fieldname to items in Tools_Docgen.res(i) my tests work as expected.

[aspeddro]

@zth changed items from array to object then better rename field to payload or params?

[aspeddro]

Gabriel, can we remove JSON decode soon (maybe 0.5 release)? At the moment, I use the decode function on the website.