-
-
Notifications
You must be signed in to change notification settings - Fork 21
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
Support multi-version docs gen at the same time for the same api #141
Comments
This plugin supports versioning, but it's based on docusuaurus versioning which is more of a snapshot, while yours is a bit different since I'm assuming they are both in development at the same time. How does this work for the TS types, do you have 2 separate TS config graphs?
Not really sure if this is a bug with the plugin, or docusaurus. |
Thanks for reply! Here are two versions of the same api, there are multiple packages in this api, and users can visit the different version api by simply modify the url. And in this case, they are being parsed and working at the same time and I can get (basiclly all by custom, 'cause the behavior of the plugin I've used is just generating the markdown docs) two individual sidebar confgs It's a bit different with the versioning which docusaurus vanilla support I think. In this case, all type docs and only the type docs are generated by plugins dynamicly and we can visit the result by any kind of method we want rather than just visit the static versioned docs by one fixed auto-generated sidebar |
About this issue:
It will report this bug in any instance of this plugin which got an id that is not "default"
I'm using another typedoc gen plugin right now, and it's multiple typedoc parsing is basicly implemented by the multiple instances of dosusaurus plugin system, and it works fine, you can take a look at the code here if you are interested: https://github.com/AbbottMc/BedrockTechWeekly/blob/master/docusaurus.config.js Here is the key part of it const minecraftTypeNames = [
'common',
'server',
'server-ui',
'server-admin',
'server-net',
'server-editor',
'server-gametest',
];
//...
plugins: [
...minecraftTypeNames.map((typeName)=>{
return [
'docusaurus-plugin-typedoc',
// Plugin / TypeDoc options
{
id: `preview-${typeName}`,
entryPoints: [`./static/typedoc/preview/${typeName}.d.ts`],
tsconfig: './static/typedoc/preview/tsconfig.json',
out: `sapi/preview/${typeName}`,
sidebar: {
categoryLabel: 'sapiPreviewSidebar',
collapsed: false,
position: 0,
fullNames: true,
}
}
];
}),
...minecraftTypeNames.map((typeName)=>{
return [
'docusaurus-plugin-typedoc',
// Plugin / TypeDoc options
{
id: `stable-${typeName}`,
entryPoints: [`./static/typedoc/stable/${typeName}.d.ts`],
tsconfig: './static/typedoc/stable/tsconfig.json',
out: `sapi/stable/${typeName}`,
sidebar: {
categoryLabel: 'sapiStableSidebar',
collapsed: false,
position: 0,
fullNames: true,
}
}
];
})
], You can see here are a bunch of multiple instances of the plugin, and all instances are working fine I'm thinking if it is caused by that you are just using the default plugin instance in the code? (I'm not familiar with the docusaurus plugin dev, it's just guessing by no reason...) |
We should support multiple instances: https://github.com/milesj/docusaurus-plugin-typedoc-api/blob/master/packages/plugin/src/index.ts#L88 Maybe there's a bug somewhere. |
The generation behavior is normal, I can see all the json files and sidebar.js files with the right plugin id been generated under
|
Recently, I've been upgrading my documentation site to Docusaurus v3 and stumbled upon this fantastic plugin!
Currently, I have a set of APIs divided into two versions: a preview version and a stable version, with each version containing multiple packages with corresponding name. My goal is to enable access to these two versions of the API via separate buttons, and ideally, they would have distinct sidebars for easy navigation. In theory, achieving this might be possible by employing multiple instances of the plugin
However, as I attempted to customize multiple instances, Docusaurus threw an error, indicating that the instance with an ID value other than the default one was not enabled...
The text was updated successfully, but these errors were encountered: