You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Docusaurus slow on a monorepo site due to globbing node_modules #12128
Our MonoRepo consists of below pnpm-workspace.yaml config.
hoist: truehoistWorkspacePackages: truelinkWorkspacePackages: deep
|packages
|--buttons
|----node_modules
|------icons-svg
|--------1k+ files
|--icons-svg
|----1k+files though symlinked
|--accordion
|----node_modules
|------icons-svg
|--------1k+ files
|------buttons
|--------button files again
We have around 180+ packages. Some packages like svg icons have around 1k+ files ( individual tsx files ). Since linked deeply, majority of packages will be dependencies of other packages.
It's still not clear enough to me. I see a monorepo with packages in it, but I don't see:
where your site lives
where are the docs files
how are the plugin configured, scanning which paths?
Your original issue only mentions the readCategoriesMetadata() docs plugin function.
But wouldn't you also need to prevent the plugins from scanning node_modules searching for md/mdx files?
Are you using the existing plugin's excludes options? Would it work if we wired that exclude option to the readCategoriesMetadata() globbing?
I’d like to investigate this performance issue and contribute a fix.
I understand that Docusaurus can become significantly slower on monorepo sites because globbing operations can scan node_modules unnecessarily.
I’d like to reproduce the performance issue, identify the relevant globbing calls, and evaluate whether adding targeted ignore patterns or narrowing the search scope can eliminate unnecessary filesystem traversal without changing the expected behavior.
I’ll also add regression/performance coverage where appropriate and keep the change scoped to the affected code path.
Could you please confirm the preferred implementation direction before I start?
Activity
beanscg commentedon Jun 9, 2026
slorber commentedon Jun 12, 2026
Could you please tell us more, giving an example tree of what your monorepo looks like? I'd like to understand better before applying a fix.
[-]Docusaurus is too slow on a monorepo site[/-]hariabinesh-l-4219 commentedon Jun 15, 2026
@slorber
Our MonoRepo consists of below pnpm-workspace.yaml config.
|packages
|--buttons
|----node_modules
|------icons-svg
|--------1k+ files
|--icons-svg
|----1k+files though symlinked
|--accordion
|----node_modules
|------icons-svg
|--------1k+ files
|------buttons
|--------button files again
We have around 180+ packages. Some packages like svg icons have around 1k+ files ( individual tsx files ). Since linked deeply, majority of packages will be dependencies of other packages.
Lokesh2704soni commentedon Jul 13, 2026
slorber commentedon Jul 16, 2026
It's still not clear enough to me. I see a monorepo with packages in it, but I don't see:
Your original issue only mentions the
readCategoriesMetadata()docs plugin function.But wouldn't you also need to prevent the plugins from scanning node_modules searching for md/mdx files?
Are you using the existing plugin's
excludesoptions? Would it work if we wired thatexcludeoption to thereadCategoriesMetadata()globbing?Jashvanthan commentedon Sep 29, 2026
Hi maintainers,
I’d like to investigate this performance issue and contribute a fix.
I understand that Docusaurus can become significantly slower on monorepo sites because globbing operations can scan
node_modulesunnecessarily.I’d like to reproduce the performance issue, identify the relevant globbing calls, and evaluate whether adding targeted ignore patterns or narrowing the search scope can eliminate unnecessary filesystem traversal without changing the expected behavior.
I’ll also add regression/performance coverage where appropriate and keep the change scoped to the affected code path.
Could you please confirm the preferred implementation direction before I start?
Thanks!