A freelance React and React-Native developer near Paris and Docusaurus maintainer. Also runs ThisWeekInReact.com, a newsletter to stay updated with the React ecosystem.
This release drops support for Node.js 18, adds support for Algolia DocSearch v4 with AskAI, improves i18n support, adds Mermaid ELK layout support, and comes with various other improvements and bug fixes.
Upgrading is easy. We follow Semantic Versioning, and minor version updates have no breaking changes, accordingly to our release process. Note that we consider dropping End-of-Life Node.js versions as non-breaking changes.
Docusaurus Faster has been introduced in Docusaurus v3.6, and permits you to opt-in for our upgraded build infrastructure and helps you build your site much faster. The experimental flags can be turned on individually, but we recommend to turn them all at once with this convenient shortcut:
In practice, your site should build much faster if you run docusaurus build a second time.
This feature depends on using the Rspack bundler, and can be turned on with the rspackPersistentCache flag:
const config ={ future:{ experimental_faster:{ rspackBundler:true,// required flag rspackPersistentCache:true,// new flag }, }, };
Preserving the cache
The persistent cache requires preserving the ./node_modules/.cache folder across builds.
Popular CDNs such as Netlify and Vercel do that for you automatically. Depending on your CI and deployment pipeline, additional configuration can be needed to preserve the cache.
In #10826, we introduced a Node.js Worker Thread pool to run the static side generation code. With this new strategy, we can better leverage all the available CPUs, reduce static site generation time, and contain potential memory leaks.
Result: On average, you can expect your site's static site generation time to be ~2× times faster 🔥. This was measured on a MacBook Pro M3 and result may vary depending on your CI.
We identified and resolved several major bottlenecks, including:
In #11007, we optimized the dev server startup time for macOS users. We figured out that the code to open your browser used expensive synchronous/blocking calls that prevented the bundler from doing its work. From now on, the bundler and the macOS browser opening will run in parallel, leading to a faster docusaurus start experience for all macOS users.
In #11163, we noticed that the docs showLastUpdateAuthor and showLastUpdateTime are quite expensive, and require to run a git log command for each document. On large sites, running these commands in parallel can exhaust the system and lead to Node.js EBADF errors. We implemented a Git command queue to avoid exhausting the system, which also slightly increased performance of our plugin's loadContent() lifecycle.
In #10885, we implemented an SVG sprite for the external link icon. Due to its repeated appearance in various places of your site (navbar, footer, sidebars...), using a React SVG component lead to duplicated SVG markup in the final HTML. Using a sprite permits to only embed the icon SVG once, reducing the generated HTML size and the static generation time. We plan to use more SVG sprites in the future.
In #11176, we fine-tuned the webpack/Rspack configuration to remove useless optimizations.
팁
If bundling time is a concern, consider disabling the optional concatenateModule bundler optimization. We explain the tradeoffs and how to do it here. It only saves 3% JS, and for a very large site, this change was incredibly impactful: 4x faster on cold builds, x16 faster rebuilds 🔥.
We have upgraded the React Native website to Docusaurus v3.8 already. Here's an updated benchmark showing the global Docusaurus Faster impact on total build time for a site with ~2000 pages:
ReactNative.dev
Cold Build
Warm Rebuild
🐢 Docusaurus Slower
120s (baseline)
33s (3.6 × faster)
⚡️ Docusaurus Faster
31s (3.8 × faster)
17s (7 × faster)
We measured similar results on our website:
Docusaurus.io
Cold Build
Warm Rebuild
🐢️ Docusaurus Slower
146s (baseline)
45s (3.2 × faster)
⚡️ Docusaurus Faster
42s (3.5 × faster)
24s (6.1 × faster)
You can also expect memory usage improvements, and a faster docusaurus start experience.
The Docusaurus v4 Future Flags let you opt-in for upcoming Docusaurus v4 breaking changes, and help you manage them incrementally, one at a time. Enabling all the future flags will make your site easier to upgrade to Docusaurus v4 when it's released.
not invented here
The concept of Future Flags is not our invention. It has been popularized in the Remix community. You can read more about this gradual feature adoption strategy here:
You can turn all the v4 Future Flags on at once with the following shortcut:
const config ={ future:{ v4:true, }, };
This way, you are sure to always keep your site prepared for Docusaurus v4. Be aware that we'll introduce more Future Flags in the next minor versions. When upgrading, always read our release blog posts to understand the new breaking changes you opt into.
In Docusaurus v4, we plan to leverage CSS Cascade Layers. This modern CSS feature is widely supported and permits to group CSS rules in layers of specificity. It is particularly useful to give you more control over the CSS cascade. It makes the CSS rules less dependent on their insertion order. Your un-layered rules will now always override the layered CSS we provide.
In #11142, we implemented a new experimental @docusaurus/plugin-css-cascade-layers that you can turn on through the v4.useCssCascadeLayers flag if you use the classic preset:
We consider this feature as a breaking change because it can slightly alter the CSS rules application order in customized sites. These issues are usually limited, and relatively easy to fix (see for example the React Native CSS changes). Sites that do not provide custom CSS and do not swizzle any component should not be affected.
In practice, it permits to automatically apply built-in CSS Cascade Layers to all the CSS we provide, including our opinionated CSS framework Infima:
Layers can help solves our long-standing Global CSS pollution issue. Our built-in global CSS rules may conflict with yours, making it harder to use Docusaurus to create playgrounds, demos and embedded widgets that are isolated from our CSS. Thankfully, CSS Cascade Layers can be reverted to create HTML subtrees that are not affected by the CSS Docusaurus provides.
Reverting layers
As this issue and this blog post explain, it is possible to revert layers to isolate an HTML subtree from the CSS that comes from that layer.
In practice, you can create a .my-playground class to revert the global CSS coming from Infima:
/* The "impossible" :not() selector helps increase the specificity */ .my-playground:not(#a#b){ &, *{ @layer docusaurus.infima{ all: revert-layer; } } }
Then you can apply this class to any HTML element, so that Infima doesn't apply to any of its children. The HTML subtree becomes isolated from our built-in CSS.
In #10850, we added a new removeLegacyPostBuildHeadAttribute Future Flag that slightly changes the signature of the postBuild() plugin lifecycle method, removing the head attribute.
While technically a breaking change, we believe this change will not affect anyone. We couldn't find any open source plugin that uses the head parameter that this method receives. If turning this flag on breaks your site, please let us know here.
In #11058, #11059, #11062 and #11077, the theme code block components have been significantly refactored in a way that should be much easier to swizzle and extend.
According to our release process, this is not a breaking change, but sites that have swizzled these components may need to upgrade them.
We also removed useless npm packages and internalizing unmaintained ones:
In #11010 and #11014, we internalized the unmaintained react-ideal-image and react-waypoint package used in @docusaurus/plugin-ideal-image, and made them compatible with React 19.
In #10956, we removed our dependency to the unmaintained react-dev-utils package (from Create-React-App).
In #10358, we replaced the unmaintained shelljs package by execa
In #11138, we removed the reading-time package in favor of the built-in Intl.Segmenter standard API to compute blog post reading times.
In #11037, we removed the useless clean-webpack-plugin.
This built-in support has been the source of various bug reports due to the inability to customize the SVGR Options, in particular the SVG Optimizer options.
In #10677, we extracted a new @docusaurus/plugin-svgr that you can now configure according to your needs. It is included by default in our classic preset:
exportdefault{ presets:[ [ 'classic', { svgr:{ svgrConfig:{ // Your SVGR options ... svgoConfig:{ // Your SVGO options ... // Use "svgoConfig: undefined" to use a svgo.config.js file }, }, }, }, ], ], };
Rspack doesn't support persistent caching yet, but it's on the roadmap and should be implemented soon. We think it's not a problem for the adoption of Rspack considering a cold Rspack build is usually as fast as a warm Webpack build using persistent caching.
mdxCrossCompilerCache: Compile MDX files once for both browser/Node.js environments instead of twice
Experimental but safe
Don't be afraid to turn this feature on. What's experimental is the config options.
The new infrastructure is robust and well-tested by our CI pipeline. The Docusaurus site already uses it in production, and we plan to use it on other Meta docs sites as well.
The new infrastructure uses Rspack. By chance, Rspack is almost 100% compatible with webpack, and Rspack shouldn't break our plugin ecosystem.
Most Docusaurus plugins should work out of the box with Rspack, even those implementing configureWebpack.
However, some of them will require small modifications to make them compatible with Rspack. The general idea is to avoid importing webpack directly, and use the "dynamically provided" webpack instance instead:
-import webpack from 'webpack'; export default function (context, options) { return { name: 'custom-docusaurus-plugin', - configureWebpack(config, isServer) { + configureWebpack(config, isServer, {currentBundler}) { return { plugins: [ - new webpack.DefinePlugin({}), + new currentBundler.instance.DefinePlugin({}), ] }; }, }; }
It's only the beginning: we will continue working on the Docusaurus Faster project and already have a few more performance improvements planned.
Depending on your feedback, we plan to make this new infrastructure the default in an upcoming major version of Docusaurus.
🙏 We'd like to thank the authors of all these great tools that already helped us make Docusaurus much faster than before. In particular the Rspack team that supported us along the way, handled our feedback very quickly and implemented all the missing features we needed to make it happen. 👏
In #10588, we created a Docusaurus plugin for Rsdoctor. It analyzes the bundling phase of Docusaurus and helps you figure out what slows down the bundler in terms of loaders, plugins and minimizers. It works for both webpack and Rspack.
In #10510, we relaxed our Mermaid diagrams dependency range to allow newer major versions of Mermaid. We now support both Mermaid 10/11, and expect upcoming versions to be compatible, letting you upgrade on your own terms.
In #10222, we added the possibility to associate social links to blog authors, for inline authors declared in front matter or global through the authors.yml file.
Icons and handle shortcuts are provided for pre-defined platforms x, linkedin, github and stackoverflow. It's possible to provide any additional platform entry (like newsletter in the example above) with a full URL.
In #10216, we added the possibility for global blog authors (declared in authors.yml) to have their own dedicated page listing all the blog posts they contributed to.
This feature is opt-in and mostly relevant for multi-author blogs. You can turn it on for a specific author by setting the page: true property:
blog/authors.yml
slorber: name: Sébastien Lorber # the description will be displayed on the author's page description:'A freelance React and React-Native developer...' page:true# Turns the feature on
In #9252, we added support for styling your blog feeds by providing custom XSLT .xls files for the RSS and Atom feeds. This allows browsers to render the feeds in a more visually appealing way, like a regular HTML page, instead of the default XML view.
We believe large multi-blogs are easier to manage by using global authors, declared in authors.yml. This notably permits to avoids duplicating author information across multiple blog posts, and now permits to generate author pages.
In #10224, we added the onInlineAuthors option. Use onInlineAuthors: 'throw' to forbid inline authors, and enforce a consistent usage of global authors.