website/versioned_docs/version-3.1.1/guides/docs/docs-multi-instance.mdx
The @docusaurus/plugin-content-docs plugin can support multi-instance.
:::note
This feature is only useful for versioned documentation. It is recommended to be familiar with docs versioning before reading this page. If you just want multiple sidebars, you can do so within one plugin.
:::
Sometimes you want a Docusaurus site to host 2 distinct sets of documentation (or more).
These documentations may even have different versioning/release lifecycles.
If you build a cross-platform mobile SDK, you may have 2 documentations:
v1.0, v1.1)v1.0, v2.0)In this case, you can use a distinct docs plugin instance per mobile SDK documentation.
:::warning
If each documentation instance is very large, you should rather create 2 distinct Docusaurus sites.
If someone edits the iOS documentation, is it really useful to rebuild everything, including the whole Android documentation that did not change?
:::
Sometimes, you want some documents to be versioned, while other documents are more "global", and it feels useless to version them.
We use this pattern on the Docusaurus website itself:
Suppose you have 2 documentations:
In this case, you should use the same plugin twice in your site configuration.
:::warning
@docusaurus/preset-classic already includes a docs plugin instance for you!
:::
When using the preset:
export default {
presets: [
[
'@docusaurus/preset-classic',
{
docs: {
// highlight-start
// id: 'product', // omitted => default instance
// highlight-end
path: 'product',
routeBasePath: 'product',
sidebarPath: './sidebarsProduct.js',
// ... other options
},
},
],
],
plugins: [
[
'@docusaurus/plugin-content-docs',
{
// highlight-start
id: 'community',
// highlight-end
path: 'community',
routeBasePath: 'community',
sidebarPath: './sidebarsCommunity.js',
// ... other options
},
],
],
};
When not using the preset:
export default {
plugins: [
[
'@docusaurus/plugin-content-docs',
{
// highlight-start
// id: 'product', // omitted => default instance
// highlight-end
path: 'product',
routeBasePath: 'product',
sidebarPath: './sidebarsProduct.js',
// ... other options
},
],
[
'@docusaurus/plugin-content-docs',
{
// highlight-start
id: 'community',
// highlight-end
path: 'community',
routeBasePath: 'community',
sidebarPath: './sidebarsCommunity.js',
// ... other options
},
],
],
};
Don't forget to assign a unique id attribute to plugin instances.
:::note
We consider that the product instance is the most important one, and make it the "default" instance by not assigning any ID.
:::
Each plugin instance will store versioned docs in a distinct folder.
The default plugin instance will use these paths:
website/versions.jsonwebsite/versioned_docswebsite/versioned_sidebarsThe other plugin instances (with an id attribute) will use these paths:
website/[pluginId]_versions.jsonwebsite/[pluginId]_versioned_docswebsite/[pluginId]_versioned_sidebars:::tip
You can omit the id attribute (defaults to default) for one of the docs plugin instances.
The instance paths will be simpler, and retro-compatible with a single-instance setup.
:::
Each plugin instance will have its own CLI command to tag a new version. They will be displayed if you run:
npm run docusaurus -- --help
To version the product/default docs plugin instance:
npm run docusaurus docs:version 1.0.0
To version the non-default/community docs plugin instance:
npm run docusaurus docs:version:community 1.0.0
Each docs-related theme navbar items take an optional docsPluginId attribute.
For example, if you want to have one version dropdown for each mobile SDK (iOS and Android), you could do:
export default {
themeConfig: {
navbar: {
items: [
{
type: 'docsVersionDropdown',
// highlight-start
docsPluginId: 'ios',
// highlight-end
},
{
type: 'docsVersionDropdown',
// highlight-start
docsPluginId: 'android',
// highlight-end
},
],
},
},
};