docusaurus: TypeError when building project, after upgrading to v2.0.0-beta.19

Can I get a confirmation that everyone running into this issue is using some kind of redoc/open API plugin? I did some preliminary hacks and found that the content.replace problem is coming from a stripBom function, which does not sound familiar to me.

Reproduces Type Errors Observed in 2.0.0-beta.20

Variant 1

PR: https://github.com/PaloAltoNetworks/docusaurus-openapi-docs/pull/81 Build output: https://github.com/PaloAltoNetworks/docusaurus-openapi-docs/runs/6396242136?check_suite_focus=true Description: Reproduces the TypeError: chalk_1.default.bold is not a function error.

Variant 2

PR: https://github.com/PaloAltoNetworks/docusaurus-openapi-docs/pull/82 Build output: https://github.com/PaloAltoNetworks/docusaurus-openapi-docs/runs/6396568165?check_suite_focus=true Description: Reproduces the TypeError: content.replace is not a function error.

Variant 3

Description: Reproduces the TypeError: content.replace is not a function error on a standalone site. Repo: https://github.com/sserrata/docusaurus-type-error Note: Repo intentionally contains entire build directory and node_modules to aid in troubleshooting.

I just tried upgrading Redux Toolkit’s website from beta.7 to beta.21, and I’m seeing a variation on this error as well:

TypeError: source_default(...).bold is not a function
TypeError: source_default(...).bold is not a function
TypeError: source_default(...).bold is not a function
[ERROR] Unable to build website for locale en.
[ERROR] Error: Failed to compile with errors.
    at D:\Projects\redux\redux-toolkit\node_modules\@docusaurus\core\lib\webpack\utils.js:180:24

edit

Hmm. After going into serverEntry.js inside of node_modules, and commenting out every use of chalk in the error handling, and adding an additional console.error('Actual error: ', err) statement, I’m finally getting something meaningful:

[ERROR] Docusaurus server-side rendering could not render static page with path /rtk-query/usage/error-handling.
Actual error:  ReactContextError
    at useDocsVersion (main:9127:99)
    at DocVersionBanner (main:9136:814)
    at zb (main:81525:195)
    at Cb (main:81528:254)
    at W (main:81534:89)
    at Db (main:81537:98)
    at Eb (main:81536:122)
    at W (main:81534:345)
    at Db (main:81537:98)
    at Cb (main:81529:131) {
  message: 'Hook useDocsVersion is called outside the <DocsVersionProvider>. '
}

except that seems to be internal to Docusaurus and I have no idea why that provider doesn’t exist.

so, three problems here:

• The actual error isn’t being printed at all
• The chalk usages appear to be broken
• I’m getting this useDocsVersion error just from upgrading DS

*edit 2

And confirmed that I’m seeing the same build failures in CI:

https://github.com/reduxjs/redux-toolkit/pull/2458

If it’s fixed, can I close this now? I’d like the folks who joined this thread to give a confirmation that the latest patch fixes everything.

The redocusaurus update to 1.1.0 fixed it for us! Thanks everyone for hopping on and figuring this out! 🥇

Thanks. I’m a bit busy these days with other business, while @slorber is on holiday. I’ll try to spare some time in the next few days to debug this. Thanks again to everyone for staying around and helping out!

For what it’s worth, we encountered a similar issue when attempting to upgrade our plugin from beta.18 to beta.19 and then beta.20. Seeing same exact errors. Can reproduce it and link to a PR if it could be helpful?

If you don’t mind the bother, you can also help us track down the actual issue by bisecting the canary releases. beta.18 corresponds to 0.0.0-4778, while beta.20 is 0.0.0-4982. If something broke your plugin, it must occur in one of the 126 versions in between. 7 install/builds would be enough to narrow it down to one version.

@sserrata That would definitely be helpful, our repo is private so to create a demo with the issue reproduced will likely take some time. Thanks!

1. Please upgrade to beta.20, which fixed the “moduleIdentifier” warnings you mentioned.
2. Please clear your node_modules entirely, and delete your lockfile, and re-install. Every time someone reports this chalk_1.default error, re-installing seems to fix it.

Works for me ❤️

In any case, I’ve merged https://github.com/facebook/docusaurus/pull/7453 which avoids using some “risky” globals in SSR. I’m hoping 0.0.0-5034 would fix everyone’s errors; I don’t really want to think too deeply about this😄

If you don’t mind the bother, you can also help us track down the actual issue by bisecting the canary releases. beta.18 corresponds to 0.0.0-4778, while beta.20 is 0.0.0-4982. If something broke your plugin, it must occur in one of the 126 versions in between. 7 install/builds would be enough to narrow it down to one version.

@Josh-Cena, after some testing, I believe that our builds start failing at 0.0.0-4875 with the TypeError: chalk_1.default.bold is not a function error. The last canary release with a successful build is (the one right before) 0.0.0-4873.

@rohit-gohri How the SSG plugin works is, it first builds your entire SPA into a single bundle, then run that bundle, which contains a ReactDOM.renderToString call, in Node.js, and writes the output to disk. Therefore, every single build time error will be coming from @slorber/static-site-generator-webpack-plugin because that’s where the SSR process starts. (And you can see that further above it’s coming from doRender which tells you it’s from the bundle itself instead of the plugin malbehaving)

any other suggestions for how we can derive the real error being thrown?

@sserrata You can use the debugger to break at caught exceptions when the server build is about to complete. I followed this: https://indepth.dev/posts/1166/this-will-make-you-more-efficient-at-debugging-webpack-unspecified-build-errors

I tried for the minimal repo and got this as the error that triggers the build failure:

Hook useTabGroupChoice is called outside the <TabGroupChoiceProvider>.
ReactContextError
    at useTabGroupChoice (main:38645:1282)
    at ResponseCodeTabs (main:56136:584)
    at d (main:118177:498)
    at bb (main:118180:16)
    at a.b.render (main:118186:43)
    at a.b.read (main:118185:83)
    at Object.exports.renderToString (main:118196:138)
    at doRender (main:29440:417)
    at async serverEntry_render (main:29437:290)

@Josh-Cena This is the call stack for the content.replace issue:

stripBom (<node_internals>/main:89284)
_readFile (<node_internals>/main:89198)
async function (Unknown Source:1)
_readFile (<node_internals>/main:130054)
doRender (<node_internals>/main:29441)
async function (Unknown Source:1)
serverEntry_render (<node_internals>/main:29437)
<anonymous> (/Users/user/Projects/docusaurus-type-error/node_modules/@slorber/static-site-generator-webpack-plugin/index.js:78)
renderPaths (/Users/user/Projects/docusaurus-type-error/node_modules/@slorber/static-site-generator-webpack-plugin/index.js:64)
<anonymous> (/Users/user/Projects/docusaurus-type-error/node_modules/@slorber/static-site-generator-webpack-plugin/index.js:53)
fn (/Users/user/Projects/docusaurus-type-error/node_modules/webpack/lib/Compilation.js:509)
_next0 (<eval>/VM46948915:32)
eval (<eval>/VM46948915:49)
eval (<eval>/VM46948916:6)
CALL_ASYNC_DELEGATE (/Users/user/Projects/docusaurus-type-error/node_modules/tapable/lib/Hook.js:18)
<anonymous> (/Users/user/Projects/docusaurus-type-error/node_modules/webpack/lib/Compilation.js:515)
<anonymous> (/Users/user/Projects/docusaurus-type-error/node_modules/copy-webpack-plugin/dist/index.js:909)
async function (Unknown Source:1)
fn (/Users/user/Projects/docusaurus-type-error/node_modules/webpack/lib/Compilation.js:509)
eval (<eval>/VM46948915:44)

It seems to be coming from https://github.com/slorber/static-site-generator-webpack-plugin

And I think reason it’s happening for openapi plugins maybe because of the Buffer polyfill most of them are using? Because the runtime value of content in content.replace is still a Buffer and that is why replace is not a function. The Buffer.isBuffer check in stripBom fails.

instead of TypeError: content.replace is not a function I am seeing the original TypeError: chalk_1.default.bold is not a function error,

Sigh I’m tempted to say that TypeError: content.replace is not a function and TypeError: chalk_1.default.bold is not a function are both garbage messages. I’m pretty confident to say that the chalk_1.default.bold error is due to a bad tslib behavior with __importDefault in our SSR pipeline. For content.replace, I still have zero idea where it’s coming from.

any other suggestions for how we can derive the real error being thrown

I suggest reducing the build to one page that still reproduces the error, then doing a binary search on your source to see which part causes the error. If you can make a minimal repro for me to look at, I can also take a try.

Not sure if this will be helpful to anyone, but I was experiencing the same error as OP after upgrading from beta 18, and it had to do with using shorthand <>fragment</> syntax in my docs. Switching to <React.Fragment>long form</React.Fragment> fixed it, but if this is the issue for you, you may want to wait for the next beta that addresses it.

The only place in Docusaurus with content.replace that could choke SSR is our code block:

https://github.com/facebook/docusaurus/blob/b7448865fe78ae1ed7585f9793ffeebd7a75a52f/packages/docusaurus-theme-common/src/utils/codeBlockUtils.ts#L160

But it has been like that in a while, so I’m almost optimistic that it’s not the culprit. The hypothesis that it’s coming from gray-matter doesn’t make a lot of sense, because gray-matter is run on server-side, but if it fails at that time, the SSR process shouldn’t even be able to start at all!

It’s always been painful that SSR doesn’t print the stack traces. We can only work backwards.

I wish I could give more useful information. We have docusaurus-node-polyfills in our project, which includes tty, so I don’t think that is causing our problems. I even tried reproducing the tty fix in the PR you linked, but it doesn’t change anything for us.

All I can say for sure is our build breaks when upgrading from beta.18 -> beta.19 or beta.20. No other changes on our side. Maybe another plugin or customization is involved or even the cause, but upgrading docusaurus triggers the problem and apparently it doesn’t only happen for projects using redocusaurus.

Seems to be ok with 1.0.4 of redocusaurus, my project now builds ok.

but this was not showing up due to chalk errors.

Yeah, the chalk error only shows up when SSR throws because of some other error. It doesn’t reproduce consistently, so I can’t say what’s wrong (I haven’t seen it myself in SSR failures in a while). Hopefully, when we emit ESM code during SSR (which will not be very distant), this will be gone since we won’t worry about all the interop mess 😃

If it’s fixed, can I close this now? I’d like the folks who joined this thread to give a confirmation that the latest patch fixes everything.

Is there anyway we can declare compatibility with docusaurus versions in the plugin’s package.json?

There isn’t an official way to do this, but you can import @docusaurus/core/package.json to read its version.

It takes quite some time and effort to support the latest beta and fix the builds.

I’m still not sure if it’s a Docusaurus bug or a bug in redocusaurus yet…