Allow getting insight to unexported types

[dsherret]

https://doc.deno.land/https://deno.land/std@0.133.0/http/file_server.ts/~/serveDir

In the definition of serveDir it has a opts parameter with ServeDirOptions type. The ServeDirOptions type is not exported and so it's not possible to see the type.

In these scenarios, ideally the API would export the type (and we should have a lint rule for that... especially in std. Edit: denoland/deno_lint#1035), but there will always be cases where this doesn't happen and so we should handle it.

One possible solution is that clicking on the type should go to the declaration of ServeDirOptions in the source. I don't think we should show it on the documentation page because that could give the false impression that it's exported.

[surma]

One possible solution is that clicking on the type should go to the declaration of ServeDirOptions in the source. I don't think we should show it on the documentation page because that could give the false impression that it's exported.

I am not sure I agree. TypeScript handles exported functions with non-export parameter types (even auto-completion does), so some libraries will pro-actively use this (and I know some that do). My personal preference would be to inline the definition, regardless of whether it’s exported. If we want to distinguish export vs non-export, we can put the word “export” in front of the definition (or something along those lines).

The problem I worry about is that people are gonna publish code in the style they prefer, and docland should support developers in finding the info they need.

[kitsonk]

I think there is a difference between linking to a symbol and allowing it to be displayed, and displaying the symbol on an index page of a module. For those, I think we should keep it only for the exported symbols.

Linking to symbols is related to #62 where we need to come up with some sort of index for symbols.