This page contains general information how to set up a Docusaurus instance everywhere. It follows the workflow used at KIT using Linux (Ubuntu), GitHub and npm, but the principles can also be adapted to other hosts and OS etc.
- Install NodeJS
- Install npm or yarn
- On Linux, macOS or WSL: Install NVM to install Node and npm. If you prefer yarn over npm, you can install yarn through npm, if you have npm already installed.
Docusaurus can then be installed via npm. For detailed explanation have a look at the official Docusaurus Documentation.
All important configurations are placed in
docusaurus.config.js at the root directory of your Docusaurus installation. For further explanations look at the official documentation.
See the official documentation.
Assets (images, gifs, videos, files in general) are typically stored inside the
static directory. Look at the usage chapter to see how to import them. Video links from YouTube can also be embedded with HTML with a provided preview etc.
Custom CSS (also for SCSS) can be placed in
src/css and must be named in the configuration file. The CSS is then automatically imported in every content page.
The main content of Docusaurus is stored in Markdown files. There are
.mdx file endings possible.
.mdx is recommended, because it also supports the usage of React. For detailed description look into the usage chapter.
Setting paths can get complicated, when you are deploying your website under another directory on the server or if you are using versioning. Detailed informations can be found in the Docusaurus documentation about assets and versioning and in the usage chapter.
.js files saved in every directory, where content pages in MarkdownX can occur. Namely in:
The TOC (
id here. The structure of a nested TOC is also defined here.
Additionally there can be a search function added to docusaurus. It is integrated in the
@docusaurus/preset-classic. If another preset or plugins are used, there may be additionally steps needed for setting up a search function. The default search function is offered by Algolia and that is probably the easiest way to add a search function. The best way is to integrate the search function after Docusaurus is fully set up and went online, because you need a public available URL to apply for the Algolia search function.
If you plan to use a more customized search (e. g. with your own index) than look at the Docusaurus official documentation or the Algolia and DocSearch documentations. Algolia itself offers different options to use it. One of them is totally free, if you have a non-profit documentation website and the website is publicly available (i. e. not behind a firewall). It is also recommended to have a fixed URL that do not change, otherwise you have to tell Algolia your new URL. Algolia needs the URL to crawl your website every 24 hours. The built index is then stored on the Algolia servers.
For the free plan you must register your website for DocSearch provided by Algolia. After that it could take several days until Algolia has checked your website and sent you an e-mail with instructions how to set up their search function. It is important to know that the instructions from the e-mail are general for clients and more complicated than it is necessary and useful(!) for Docusaurus. Do not follow all instructions from Algolia when using Docusaurus! It is mostly just necessary to insert a key and the index name in
docusaurus.config.js and save the inserted values (key and index name) as environment variables:
Do not insert another app id provided by Algolia if you are using the free plan from Algolia. Otherwise the search does not work because Algolia itself inserts the app id. There is no need for an app id with free plan.
Algolia also provides the ability to create an account for accessing statistics and configurating their products: Algolia Sign Up. But if you are using a free plan it is not necessary to use an account because you are very limited in configurations and your configuration possibilities are on the Docusaurus site.
Error messages are also disṕlayed in the Browser console of an production Docusaurus.
If you want to modify how Docusaurus displays the search results retrieved from the Algolia API you can change the Algolia Search Code in React by creating the directories and adding the code into it
src/theme/SearchPage. For example if you want to display every pages with multiple hits just once in the search results then get an inspiration for that from GitHub. Of course you can also modify other functions of the Algolia React code in Docusaurus.
Presets are a bundle of themes and plugins, define the layout and offer functionalities like the search bar. More information about presets. The default preset is the classic one. A preset maintains one docs and one blog instance. If you want to serve multiple docs instance, e. g. for versioning you need to replace this property in the preset with multiple plugins in the configuration file.
For example you want to install two versions of the documentation for manual A, one for version 0.8 the other for version 0.9, then set
docs:false in the
preset property and add a property
@docusaurus/plugin-content-docs under the
plugins property on the level of the preset. If you also want to serve another manual B in the same docusaurus instance, you need to add a second property
@docusaurus/plugin-content-docs. The blog instance is still initialized in the classic preset.
Themes are an addition to presets and plugins, but define more the layout than the underlying structure.
For more options look in the official Docusaurus Documentation. You can also create your own themes under
See the official Docusaurus Documentation.
For adding multiple versions of one documentation to Docusaurus look at the plugin chapter to see how it is configured in the configuration file. To know how to install it look at the example in the usage chapter.
The Docusaurus instance can be saved in a VCS to enable development by multiple people. A VCS is also needed to enable online editing and online Continuous Integration/Deployment.
Docusaurus supports the usage of the
dotenv npm package. For that, import it in the configuration file. Environment variables are typically used there.
Environment variables can be safed in a
.env file or stored as secrets in GitHub or GitLab. The last option is also useful for Continuous Deployment. If Docusaurus is developed locally in addition to Continuous Deployment on GitHub or GitLab, it is necessary, that every developer has access to the
.env file, which is usually not shared via a VCS. For that, save it in another place or create dummy environment variables.
There are two main ways to contribute to Docusaurus instance: either develop within a local Docusaurus installation or change the content of an online Docusaurus website via Version Control System (e. g. GitHub or GitLab). One of the important features of Docusaurus is the ability to edit a Documentation page via a VCS without the need of a locally installed Docusaurus and advanced programming knowledge.
The Docusaurus development is based on npm. To change the configurations or script some JSX it is needed to install or clone Docusaurus locally and install the necessary things from the requirements. There are to possible ways: either your are the creator and maybe admin of an Docusaurus instance or you are a developer contributer to an existing Docusaurus instance.
If you are a creator than you have probably the task to set up a new Docusaurus instance. A common workflow could be this:
- Install Docusaurus locally on your developer machine: See the installation chapter.
- Configure and develop the Docusaurus instance
- Create a repository of your favorite VCS
- Push the whole locally developed Docusaurus instance to your VCS. It is very important to push the whole code of the instance because then other developers can easily clone the code and it is also helpful for deployment.
Normally hidden files, node, yarn or Docusaurus packages, build directories and maybe additional files are in the
.gitignore(or corresponding configurations for other VCSs), so they will not be pushed. But they can also be created easily locally or for deployment and it is also not useful to share them.
If you are a normal developer than probably a creator or an admin has already set up Docusaurus and pushed to a VCS. A common workflow could be this:
- Clone a repository that contains a Docusaurus instance to your local developer machine
- Maybe it is necessary to install the requirements
- Change code or write documentation or blog content
- Commit and push
To check your local development for your Docusaurus instance you can use common npm commands.
To run a Docusaurus instance on localhost on default port 3000:
To run Docusaurus instance on localhost on port 3001 or another port number, if 3000 is already in use:
Check if your Docusaurus instance could be build correctly. That command is also helpful before you push code to solve errors and a hint if your links are solved correctly:
Sometimes useful if you encouter errors, e. g. during build process:
Because Docusaurus is a high level framework, there is no dedicated way of live debugging. You can use the debug plugin to get some static information of your docusaurus site. Another solution is to look into the
Every documentation page can be edited online without deeper knowledge of Docusaurus via an
Edit this page button. To enable this, insert a link for editions in your VCS (e. g.
https://github.com/ComPlat/chemotion_saurus/edit/master/) in the configuration file, usually under
A static Docusaurus website can easily be build with a npm or yarn command and then only this
build directory needs to be pushed to a server:
If you are serving your Docusaurus website under another directory than the default
/ you may encounter problems with paths for assets (images, files etc.). Look in the Docusaurus documenation for solutions: https://docusaurus.io/docs/static-assets.
Docusaurus can be fully built and deployed via GitHub or GitLab. For that a workflow file in yml is needed, where the current code is checked out (e. g. on every push), build via npm or yarn and the so created build directory pushed to a server via SSH. An example workflow for Continious Deployment via SSH can be found on GitHub. For detailed explanations see the testing chapter.