<p dir="auto">We should consider implementing a command that would essentially evaluate a script and its dependencies and output a JSON structure representing the important documentation information for that code.  This then could be used and ingested to generate static site documentation content for personal use or as part of a registry.</p>
<p dir="auto">The TypeScript compiler API guide actually has a <a href="https://github.com/microsoft/TypeScript/wiki/Using-the-Compiler-API#using-the-type-checker">nice little example of how to walk the TypeScript AST and write out types to a JSON structure</a>.</p>
<p dir="auto">For prior art or standards, I did a bit of research.  Looking at JSDoc3, it does not directly support a JSON structure, it emits HTML.  It has some plugins that allow you to change how it renders, but there is no good intermediary standard.  TypeDoc can produce an intermediary JSON blob, but it then can't ingest that for static site generation.  Even then the structure of the TypeDoc JSON still has some strong opinions about how code is done, which is not ideal way.  I really think we need to try to find something that meets our needs as there isn't really a good starting point that I can find.</p>
<p dir="auto">Refs <a class="issue-link js-issue-link" data-error-text="Failed to load title" data-id="443689137" data-permission-text="Title is private" data-url="https://github.com/denoland/deno/issues/2355" data-hovercard-type="issue" data-hovercard-url="/denoland/deno/issues/2355/hovercard" href="https://github.com/denoland/deno/issues/2355">#2355</a> - <code class="notranslate">deno ast script.ts</code> the challenge I think is that there is there is a lot of information in there that is "useless" to the task of generating documentation, and some things are a bit hard to get to.  I think a structure that is more focused on documentation might be a better idea.</p>
<p dir="auto">cc/ <a class="user-mention notranslate" data-hovercard-type="user" data-hovercard-url="/users/j-f1/hovercard" data-octo-click="hovercard-link-click" data-octo-dimensions="link_type:self" href="https://github.com/j-f1">@j-f1</a></p>
<p dir="auto">V8 offers the possibility to generate code coverage<br>
ref: <a href="https://v8.dev/blog/javascript-code-coverage#for-embedders" rel="nofollow">https://v8.dev/blog/javascript-code-coverage#for-embedders</a></p>
<p dir="auto">I've already started writting a lcov parser : <a href="https://github.com/zekth/deno-lcov">https://github.com/zekth/deno-lcov</a> (ATM use standard lcov file but can be ported to v8 coverage files)</p>
<p dir="auto">I think it would be really usefull for <code class="notranslate">deno_std</code> test modules and even for the <code class="notranslate">core js</code> of deno, to see what is really tested or not.</p>