Make a pass over the docs, fixing a bunch of problems #274
Conversation
…ndex In order to make TypeDoc happy, it looks like I have to manually deal with types from other packages that appear in the API. In this case, that's BaseEngineSetting.
Including a whole new support module provided by a typedoc developer
| } from "./store"; | ||
|
|
||
| export { WWTAwareComponent } from "./wwtaware"; | ||
|
|
||
| // Can't figure out a one-liner way to re-export the default export from | ||
| // Component.vue under a specific name, so: | ||
| import WWTComponent from "./Component.vue"; |
There was a problem hiding this comment.
export { default as WWTComponent } from "./Component.vue"
| @@ -1,5 +1,33 @@ | |||
| declare module "*.vue" { | |||
| import { defineComponent } from "vue"; | |||
|
|
|||
| // For reasons unclear to me, the docstring for the WWTComponent component | |||
There was a problem hiding this comment.
This is probably TypeStrong/typedoc#2283, which I haven't gotten to yet...
| readonly lm: LayerManagerObject; | ||
|
|
||
| /** The [`ScriptInterface`](../../engine/classes/ScriptInterface.html) associated with this instance. */ |
There was a problem hiding this comment.
This makes me sad... @link ought to work here...
There was a problem hiding this comment.
We have a bunch of separate NPM packages that we manage in a monorepo. From the configuration that we have, I don't see how typedoc would have any way of knowing how to construct a URL to a type defined in (e.g.) @wwtelescope/engine while preparing the docs for @wwtelescope/engine-pinia — it has no way of knowing that those docs also live in the monorepo and are also built using typedoc.
This basically seems like the problem addressed by Intersphinx in Python-land. If typedoc has any support for solving it, I'd be happy to adopt it, but I didn't see a way to do that built in. It seems like it wouldn't be hard for us to write a plugin to help with linking in our specific case, but I simply haven't sat down to look into that.
There was a problem hiding this comment.
Ah, yeah... that's a problem that TypeDoc kind of has a solution for, in that it has the necessary hooks in place that it could be built, but doesn't have a canonical solution -- third party symbols
Our API docs have gotten pretty busted, between changes to typedoc and the port to Pinia. Here I try to fix them up and improve some wayfinding. Big shout-out to TypeStrong/typedoc#2409 in which our Vue/Pinia component docs were un-broken!