-
Notifications
You must be signed in to change notification settings - Fork 9
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
incompatible with entryPointStrategy "packages"? #23
Comments
tangentially related: it's unclear how my existing typedoc config files affect the behavior of this plugin. I can confirm they are being read. |
I'll make a branch for you. |
This is currently broken due to HiDeoo/starlight-typedoc#23 To run example: 1. Clone repo 2. Checkout this branch (`boneskull/starlight-typedoc`) 3. Run `npm install` 4. Run `npm run dev:docs` This should fail without any obvious error; this is because of the check for `groups` in `starlight-typedoc`. You can also run `npm exec typedoc` from the workspace root to see that the problem is unique to `starlight-typedoc`.
OK, see this PR. Also, if you want to push your code somewhere, I can try it myself. |
This is currently broken due to HiDeoo/starlight-typedoc#23 To run example: 1. Clone repo 2. Checkout this branch (`boneskull/starlight-typedoc`) 3. Run `npm install` 4. Run `npm run dev:docs` This should fail without any obvious error; this is because of the check for `groups` in `starlight-typedoc`. You can also run `npm exec typedoc` from the workspace root to see that the problem is unique to `starlight-typedoc`.
Thanks a lot, that was super helpful 🙌 The sidebar is now properly generating with the new changes: ![]()
Sure, I've pushed a draft PR in #24 |
This is currently broken due to HiDeoo/starlight-typedoc#23 To run example: 1. Clone repo 2. Checkout this branch (`boneskull/starlight-typedoc`) 3. Run `npm install` 4. Run `npm run dev:docs` This should fail without any obvious error; this is because of the check for `groups` in `starlight-typedoc`. You can also run `npm exec typedoc` from the workspace root to see that the problem is unique to `starlight-typedoc`.
Fixed with #24 that should be released relatively soon. |
This is currently broken due to HiDeoo/starlight-typedoc#23 To run example: 1. Clone repo 2. Checkout this branch (`boneskull/starlight-typedoc`) 3. Run `npm install` 4. Run `npm run dev:docs` This should fail without any obvious error; this is because of the check for `groups` in `starlight-typedoc`. You can also run `npm exec typedoc` from the workspace root to see that the problem is unique to `starlight-typedoc`.
Describe the bug
...or possibly just incompatible with Typedoc v0.52.4.
This is two problems with likely a single root cause.
I have a monorepo with several workspaces, and I use the
packages
entryPointStrategy
to create a single docs site from them. This works whentypedoc
is run from the command line (with or withouttypedoc-plugin-markdown@next
).However, this line will always throw an exception with this use case:
starlight-typedoc/packages/starlight-typedoc/libs/typedoc.ts
Line 50 in 64d367a
This is likely due to a breaking change in how Typedoc creates
ProjectReflection
files, but I don't know if that's due to the breaking changes in how thepackages
entryPointStrategy
works, or for some other reason. In this use case,groups
will always beundefined
. I think what you want to get at is deeper in theProjectReflection
.Once this conditional has been commented out, the plugin proceeds to generate the documentation and place it in the desired output directory. However, the sidebar appears empty (I'm guessing because
groups
isundefined
).To Reproduce
My setup involves a root typedoc config with
entryPointStrategy: 'packages'
, where theentryPoint
s are relative paths to workspace folders. Each workspace then has its own Typedoc config containing anentryPoint
and any other specific configuration.The configuration for this plugin I'm using is akin to this:
These workspaces live in a
packages/
folder, and my Astro config is inpackages/docs/astro.config.mjs
(thus the relative paths).Expected behavior
I'm not sure what I'd expect, exactly. Certainly, I want the sidebar to display something. It might mean extra nesting in the sidebar? Ideally, I'd have some control over how I wanted to arrange things without the need to override a component. Maybe pass in some option to a sidebar configurator which tells it which project to display; I could repeat this for each project.
How often does this bug happen?
Every time
System Info
Additional Context
No response
The text was updated successfully, but these errors were encountered: