[DocGen]: Polish

[aspeddro]

Emit all items from module alias.

{
    "id": "RescriptCore.Core__Console",
    "kind": "moduleAlias",
    "docstrings": [],
    "signature": "module Console = Core__Console"
}, 

New Output:

{
    "id": "RescriptCore.Core__Console",
    "name": "Console",
    "kind": "moduleAlias",
    "docstrings": [],
    "items": [
    {
      "id": "RescriptCore.Core__Console.assert_",
      "kind": "value",
      "name": "assert_",
      "signature": "let assert_: (bool, 'a) => unit",
      "docstrings": ["`assert_(assertion, value)` print a message to console if `assertion` evaluates `false`. Does nothing if it's `true`.\n\nSee [`console.assert`](https://developer.mozilla.org/en-US/docs/Web/API/console/assert)\non MDN.\n\n## Examples\n\n```rescript\nConsole.assert_(false, \"Hello World!\")\nConsole.assert_(n == 42, \"The answer\")\n```"]
    }, 
    {
      "id": "RescriptCore.Core__Console.assert2",
      "kind": "value",
      "name": "assert2",
      "signature": "let assert2: (bool, 'a, 'b) => unit",
      "docstrings": ["`assert2(v1, v2)`. Like `assert_`, but with two arguments.\n\n## Examples\n\n```rescript\nConsole.assert2(false, \"Hello\", \"World\")\nConsole.assert2(n == 42, [1, 2, 3], '4')\n```"]
    },
   ....
}

Full output for ReScriptCore: Gist

[aspeddro]

Run for entrypoint lib file dune exec -- rescript-editor-analysis extractDocs ~/path/to/rescript-core/src/RescriptCore.res

[zth]

This eagerly looks up stuff, right? I think it's fine, we can change back to the old behavior easily if we see issues with this.

Thank you!

[aspeddro]

Yes. I would like to test this in the compiler documentation.

[aspeddro]

@zth, I added some error messages and an exit code.

Also renamed some fields, this simplifies writing the decode

[zth]

@zth, I added some error messages and an exit code.

Also renamed some fields, this simplifies writing the decode

We should design the output so that we can use zero-cost modelling of the data via ReScript v11 and the new variants represenation. That should be possible with inline records. What do you think about that?

[aspeddro]

I'm testing the decode in rescript-lang repo using version 10.1. I haven't explored the new variant representation. Does the current output make it impossible to use this feature?

[zth]

I'm testing the decode in rescript-lang repo using version 10.1. I haven't explored the new variant representation. Does the current output make it impossible to use this feature?

Ahh, right! No, it looks fine. Here's a quick example of how bindings for most of the structures could look, zero cost: https://rescript-lang.org/try?version=v10.1.2&code=C4TwDgpgBAZglhANgEwCIHsDGUC8UDeAUFLAigHICGAthAFxQDOwATnAHYDmANMVMlmZsujBpRYtKIADxCOnAHy8SjOJ3aVgAVxb0mrebwC+hQqEhRM6dkK2Zg6Fhmx4iJKzdZ2HLKrQZyXMr8ggYiYhJSsmGKwarqmjp6gTyEJoQAAsCUnAAUAEQA1hzI+QCUZuDQyBDZcIi4UAA+UBmUjAW6ViylZVAAShDdyLn48EhoghGSMuMozgpGfS1tHfkAbuJwlOzA5VAAals7wKNzk5iiUOIz0ucLS6ZZOQXF7L2VFl1QcMAQ1Lg+Ct2gVzBBynwACpVUZ8EgkODIAIxYLwqAafz6YSpNEqNQabS6ZHY1HwgSXGJXG5RFJKOFQR4kYFrTaILTgiokI5siCw3E-JFYwz0kgY5IokVMfGJIlCoKS8kpKmRGS00mM5qtEH5ajoZBaRAQACCiG2jAhJAAsnqDcbTSC3LjEcThfyxS75fzFZTpjSYnT+b9-srbkHqAH4Y8gA

[aspeddro]

I added one more change 70f19fa. id as valid module path, Belt.Map.Int.checkInvariantInternal instead of Belt.Belt_Map.Belt_MapInt.checkInvariantInternal

diff --git a/data/api_belt.json b/data/api_belt.json
index 565cd1a..df12c7e 100644
--- a/data/api_belt.json
+++ b/data/api_belt.json
@@ -3,60 +3,60 @@
   "docstrings": ["The ReScript standard library.\n\nBelt is currently mostly covering collection types. It has no string or date functions yet, although Belt.String is in the works. In the meantime, use [Js.String](js/string) for string functions and [Js.Date](js/date) for date functions.\n\n## Motivation\n\nBelt provides:\n\n- The **highest quality** immutable data structures in JavaScript.\n- Safety by default: A Belt function will never throw exceptions, unless it is\n  indicated explicitly in the function name (suffix \"Exn\").\n- Better performance and smaller code size running on the JS platform.\n- Ready for [Tree Shaking](https://webpack.js.org/guides/tree-shaking/).\n\n## Usage\n\nTo use modules from Belt, either refer to them by their fully qualified name (`Belt.List`, `Belt.Array` etc.) or open the `Belt` module by putting\n\n```rescript\nopen Belt\n```\n\nat the top of your source files. After opening Belt this way, `Array` will refer to `Belt.Array`, `List` will refer to `Belt.List` etc. in the subsequent code.\n\nIf you want to open Belt globally for all files in your project instead, you can put\n\n```json\n\"bsc-flags\": [\"-open Belt\"]\n```\n\ninto your `bsconfig.json`.\n\n**Note**: this is the **only** `open` we encourage.\n\nExample usage:\n\n```rescript\nlet someNumbers = [1, 1, 4, 2, 3, 6, 3, 4, 2]\n\nlet greaterThan2UniqueAndSorted =\n  someNumbers\n  ->Belt.Array.keep(x => x > 2)\n  // convert to and from set to make values unique\n  ->Belt.Set.Int.fromArray\n  ->Belt.Set.Int.toArray // output is already sorted\n\nJs.log2(\"result\", greaterThan2UniqueAndSorted)\n```\n\n## Curried vs. Uncurried Callbacks\n\nFor functions taking a callback parameter, there are usually two versions\navailable:\n\n- curried (no suffix)\n- uncurried (suffixed with `U`)\n\nE.g.:\n\n```rescript\nlet forEach: (t<'a>, 'a => unit) => unit\n\nlet forEachU: (t<'a>, (. 'a) => unit) => unit\n```\n\nThe uncurried version will be faster in some cases, but for simplicity we recommend to stick with the curried version unless you need the extra performance.\n\nThe two versions can be invoked as follows:\n\n```rescript\n[\"a\", \"b\", \"c\"]->Belt.Array.forEach(x => Js.log(x))\n\n[\"a\", \"b\", \"c\"]->Belt.Array.forEachU((. x) => Js.log(x))\n```\n\n## Specialized Collections\n\nFor collections types like set or map, Belt provides both a generic module as well as specialized, more efficient implementations for string and int keys.\n\nFor example, Belt has the following set modules:\n\n- [Belt.Set](belt/set)\n- [Belt.Set.Int](belt/set-int)\n- [Belt.Set.String](belt/set-string)\n\n## Implementation Details\n\n### Array access runtime safety\n\nOne common confusion comes from the way Belt handles array access. It differs from than the default standard library's.\n\n```rescript\nlet letters = [\"a\", \"b\", \"c\"]\nlet a = letters[0] // a == \"a\"\nlet capitalA = Js.String.toUpperCase(a)\nlet k = letters[10] // Raises an exception! The 10th index doesn't exist.\n```\n\nBecause Belt avoids exceptions and returns `options` instead, this code behaves differently:\n\n```rescript\nopen Belt\nlet letters = [\"a\", \"b\", \"c\"]\nlet a = letters[0] // a == Some(\"a\")\nlet captialA = Js.String.toUpperCase(a) // Type error! This code will not compile.\nlet k = letters[10] // k == None\n```\n\nAlthough we've fixed the problem where `k` raises an exception, we now have a type error when trying to capitalize `a`. There are a few things going on here:\n\n- Reason transforms array index access to the function `Array.get`. So `letters[0]` is the same as `Array.get(letters, 0)`.\n- The compiler uses whichever `Array` module is in scope. If you `open Belt`, then it uses `Belt.Array`.\n- `Belt.Array.get` returns values wrapped in options, so `letters[0] == Some(\"a\")`.\n\nFortunately, this is easy to fix:\n\n```rescript\nopen Belt\nlet letters = [\"a\", \"b\", \"c\"]\nlet a = letters[0]\n\n// Use a switch statement:\nlet capitalA =\n  switch a {\n  | Some(a) => Some(Js.String.toUpperCase(a))\n  | None => None\n  }\n\nlet k = letters[10] // k == None\n```\n\nWith that little bit of tweaking, our code now compiles successfully and is 100% free of runtime errors!\n\n### A Special Encoding for Collection Safety\n\nWhen we create a collection library for a custom data type we need a way to provide a comparator function. Take Set for example, suppose its element type is a pair of ints, it needs a custom compare function that takes two tuples and returns their order. The Set could not just be typed as Set.t (int \\* int) , its customized compare function needs to manifest itself in the signature, otherwise, if the user creates another customized compare function, the two collection could mix which would result in runtime error.\n\nWe use a phantom type to solve the problem:\n\n```rescript\nmodule Comparable1 =\n  Belt.Id.MakeComparable(\n    {\n      type t = (int, int)\n      let cmp = ((a0, a1), (b0, b1)) =>\n        switch Pervasives.compare(a0, b0) {\n        | 0 => Pervasives.compare(a1, b1)\n        | c => c\n        }\n    }\n  )\n\nlet mySet1 = Belt.Set.make(~id=module(Comparable1))\n\nmodule Comparable2 =\n  Belt.Id.MakeComparable(\n    {\n      type t = (int, int)\n      let cmp = ((a0, a1), (b0, b1)) =>\n        switch Pervasives.compare(a0, b0) {\n        | 0 => Pervasives.compare(a1, b1)\n        | c => c\n        }\n    }\n  )\n\nlet mySet2 = Belt.Set.make(~id=module(Comparable2))\n```\n\nHere, the compiler would infer `mySet1` and `mySet2` having different type, so e.g. a `merge` operation that tries to merge these two sets will correctly fail.\n\n```rescript\nlet mySet1: t<(int, int), Comparable1.identity>\nlet mySet2: t<(int, int), Comparable2.identity>\n```\n\n`Comparable1.identity` and `Comparable2.identity` are not the same using our encoding scheme."],
   "items": [
   {
-    "id": "Belt.Belt_Id",
+    "id": "Belt.Id",
     "kind": "moduleAlias",
     "name": "Id",
     "docstrings": ["[`Belt.Id`]()\n\n  Provide utilities to create identified comparators or hashes for\n  data structures used below.\n\n  It create a unique identifier per module of\n  functions so that different data structures with slightly different\n  comparison functions won't mix"],
     "items": [
     {
-      "id": "Belt.Belt_Id.hash",
+      "id": "Belt.Id.hash",
       "kind": "type",
       "name": "hash",
       "signature": "type hash<'a, 'id>",
       "docstrings": ["`('a, 'id) hash`\n\n  Its runtime represenation is a `hash` function, but signed with a\n  type parameter, so that different hash functions type mismatch"]
     }, 
     {
-      "id": "Belt.Belt_Id.eq",
+      "id": "Belt.Id.eq",
       "kind": "type",
       "name": "eq",
       "signature": "type eq<'a, 'id>",
       "docstrings": ["`('a, 'id) eq`\n\n  Its runtime represenation is an `eq` function, but signed with a\n  type parameter, so that different hash functions type mismatch"]
     }, 
     {
-      "id": "Belt.Belt_Id.cmp",
+      "id": "Belt.Id.cmp",
       "kind": "type",
       "name": "cmp",
       "signature": "type cmp<'a, 'id>",
       "docstrings": ["`('a,'id) cmp`\n\n  Its runtime representation is a `cmp` function, but signed with a\n  type parameter, so that different hash functions type mismatch"]
     }, 
     {
-      "id": "Belt.Belt_Id.comparable",
+      "id": "Belt.Id.comparable",
       "kind": "type",
       "name": "comparable",
       "signature": "type comparable<'key, 'id> = module(Comparable with type identity = 'id)\\ntype t = 'key",
       "docstrings": ["`('key, 'id) cmparable` is a module of functions, here it only includes `cmp`.\n\n  Unlike normal functions, when created, it comes with a unique identity (guaranteed\n  by the type system).\n\n  It can be created using function [`comparableU`]() or [`comparable`]().\n\n  The idea of a unique identity when created is that it makes sure two sets would type\n  mismatch if they use different comparison function"]
     }, 
     {
-      "id": "Belt.Belt_Id.MakeComparableU",
+      "id": "Belt.Id.MakeComparableU",
       "name": "MakeComparableU",
       "kind": "module",
       "items": [
       {
-        "id": "Belt.Belt_Id.MakeComparableU.identity",
+        "id": "Belt.Id.MakeComparableU.identity",
         "kind": "type",
         "name": "identity",
         "signature": "type identity",
         "docstrings": []
       },