Kitson Kelly
Kitson Kelly
We already have `deno info --json module_a.ts` as well as [`deno_graph`](https://deno.land/x/[email protected]/mod.ts) which is a JavaScript interface to the Rust APIs. Outside of supporting a specific 3rd party library, how would...
> The benefit would be to show the dependency graph in a visual way in addition to existing ways, Well `deno info` without JSON does that. One visual way is...
> I see `deno` CLI interface also as a development kit. It is, and it comes with minimalistic but extensible tools to a) print a module graph (`deno info`), b)...
I knew summoning @danopia was a good idea! 😁
I have changed the title of this to better reflect what is being requested, which is easy static site generation of documentation from deno_doc, or integrated into deno_doc.
This isn't a defect, it is either a current design limitation and/or feature request, as we do not type inference (e.g. inferred return types, or in this case, object literals....
Correction, we do infer some trivial types for const variables, just not more complex types like object literals.
As mentioned in #113, we should also ensure that when we infer types for an object literal, we infer the associated JSDoc block.
#146 will be part of the problem, but we need to be able to represent "standalone" JSDoc blocks in the doc nodes. That would just get a JSDoc block with...
The use cases make sense. They always have to me. > Does this mean that JSDoc type annotations are not actually resolved to same type constructs as TS type annotations...