-
-
Notifications
You must be signed in to change notification settings - Fork 8.3k
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
RangeError: Invalid string length when building with a very large number of blogs #9907
Comments
A 30k blog post? 🤯 why do you have so many? Yes, it seems like we should not use For example https://github.com/dominictarr/JSONStream#jsonstreamstringifyopen-sep-close Note to myself: I'll probably take this opportunity to encapsulate this streaming, and expose simpler, more testable interfaces to create route data bundles because I'm not a fan of our historic plugin actions API for that: // Create a blog archive route
const archiveProp = await createData(
`${docuHash(archiveUrl)}.json`,
JSON.stringify({blogPosts: listedBlogPosts}, null, 2),
);
addRoute({
path: archiveUrl,
component: blogArchiveComponent,
exact: true,
modules: {
archive: aliasedSource(archiveProp),
},
}); That would be more convenient to have everything handled for you, and just write: addRoute({
path: archiveUrl,
component: blogArchiveComponent,
exact: true,
props: {
archive: {blogPosts: listedBlogPosts},
},
}); Note we'd still need to keep a way to create data bundles independent from routes (+ streaming support), because those data bundles can be shared between routes, reducing the amount of data to load when navigating from one route to another. (although this data could probably be added as a |
@slorber thanks for looking into this issue, I'm replacing Wordpress with Docusaurus and I'm migrating an existing news website. The reason for this is the simplicity, speed and the low maintenance cost of Docusaurus! You can see it in action: https://mesghalapp.com/en/news Currently I have two blockers: The screenshot above is for including only ~2K blogs is possible to split this file into smaller files as well? |
https://mesghalapp.com/en/news/archive/ To be honest I don't think Docusaurus is designed to support that kind of scale. It seems you have 2k entries just for 2024, and if it keeps growing at the same pace the build time will quickly become unsustainable. You'd rather use a docs framework that supports server-side-rendering. Note that the blog archive page can be disabled with option But even with that solution, I doubt Docusaurus will be the best choice for your need. |
@slorber thanks for info, currently I'm only keeping the news for 3 months by deleting the older ones to manage this limitation. |
You are lucky because I'm actively working on Docusaurus performance issues right now. The upcoming v3.2 release will be faster and have some basic perf logging that you can turn on with However, it does not fix all the problems yet, and the main unfixed bottleneck remains bundling your app with Webpack for both client consumption and SSR. Also, the bundle we assemble for server/node usage is historically a huge single JS file, that causes memory issues during the SSG phase. Yes the build process can be improved, but this is likely quite technical and I'd prefer it to handle it myself. Most likely we will try to swap Webpack by Rspack soon and provide a flag to enable Rspack to provider an incremental migration path. But Rspack is not yet 100% retrocompatible with Webpack so it might not even work right now. |
@slorber
it looks like that |
It's more 2min than 4min, because the log is unclear but one ask is composed of another. And yes that seems expected that rendering, minifying and wriing thousands of static files takes time. For a blog, the number of pages to generate can grow quickly depending on your usage of tags and your pagination setting. What takes the most time remains the bundling phase, which has not been optimized yet. |
I'm currently in the process of migrating from 2.4.3 to 3.4.0 and encountered the Full error portion of stack trace:
The site is rather large but currently builds fine on 2.4.3, although it takes upwards of 45 minutes. Should 3.x have necessarily impacted Docusaurus' ability to scale to large sites? Any other troubleshooting steps or workarounds I can/should try? I'm planning to scour the docs, release notes and issues to see if I may have missed someone else posting a solution. Thanks! |
@sserrata unfortunately I don't really know what's causing the issue above, but it looks like your JS assets are too big. Maybe under v2, you were just under the limit, and we added extra React components and features in v3 that contribute to the bundle size increase that makes you reach that limit? I don't know for sure but I don't remember anything that could have impacted the scalability. What I see is that the error gets emitted in |
Thanks @slorber! It looks like |
@sserrata I don't really know, maybe trying to configure the server to output more and smaller chunks could help. Worth tracking this PR (#10402), it's possible that Rspack will solve the problem, although it's supposed to be a port so it may have the same limitations in practice. I'd like to release an experimental Rspack support in v3.6 if I'm able to fix a few more edge cases. |
Have you read the Contributing Guidelines on issues?
Prerequisites
npm run clear
oryarn clear
command.rm -rf node_modules yarn.lock package-lock.json
and re-installing packages.Description
docusaurus build returns
RangeError: Invalid string length
when building the website with a very large number of blogs (~30K)Error:
Looking at the code, it looks like
JSON.stringify({ blogPosts: listedBlogPosts }
is the problematic partReproducible demo
No response
Steps to reproduce
Expected behavior
Actual behavior
it throws
RangeError: Invalid string length
Your environment
Docusaurus version: 3.1.1
Node version: v20.11.0
macOS 14.3.1 (23D60)
Self-service
The text was updated successfully, but these errors were encountered: