ReferenceError: process is not defined (Docusaurus)

[pomber]

Hi. I was testing sandpack-react with Docusaurus, but there's a fatal error as soon as I import a sandpack component:

client.js?e6b8:10 Uncaught (in promise) ReferenceError: process is not defined
    at eval (webpack-internal:///./node_modules/@codesandbox/sandpack-client/esm/client.js:21)
    at Module../node_modules/@codesandbox/sandpack-client/esm/client.js (:3000/vendors-node_modules_codesandbox_sandpack-react_dist_esm_presets_SandpackRunner_js.js:23)
    at __webpack_require__ (:3000/runtime~main.js:36)
    at fn (:3000/runtime~main.js:339)
    at eval (webpack-internal:///./node_modules/@codesandbox/sandpack-react/dist/esm/contexts/sandpackContext.js:8)
    at Module../node_modules/@codesandbox/sandpack-react/dist/esm/contexts/sandpackContext.js (:3000/vendors-node_modules_codesandbox_sandpack-react_dist_esm_presets_SandpackRunner_js.js:143)
    at __webpack_require__ (:3000/runtime~main.js:36)
    at fn (:3000/runtime~main.js:339)
    at eval (webpack-internal:///./node_modules/@codesandbox/sandpack-react/dist/esm/hooks/useSandpack.js:6)
    at Module../node_modules/@codesandbox/sandpack-react/dist/esm/hooks/useSandpack.js (:3000/vendors-node_modules_codesandbox_sandpack-react_dist_esm_presets_SandpackRunner_js.js:183)
    at __webpack_require__ (:3000/runtime~main.js:36)
    at fn (:3000/runtime~main.js:339)
    at eval (webpack-internal:///./node_modules/@codesandbox/sandpack-react/dist/esm/common/Layout.js:8)
    at Module../node_modules/@codesandbox/sandpack-react/dist/esm/common/Layout.js (:3000/vendors-node_modules_codesandbox_sandpack-react_dist_esm_presets_SandpackRunner_js.js:79)
    at __webpack_require__ (:3000/runtime~main.js:36)
    at fn (:3000/runtime~main.js:339)
    at eval (webpack-internal:///./node_modules/@codesandbox/sandpack-react/dist/esm/presets/SandpackRunner.js:7)
    at Module../node_modules/@codesandbox/sandpack-react/dist/esm/presets/SandpackRunner.js (:3000/vendors-node_modules_codesandbox_sandpack-react_dist_esm_presets_SandpackRunner_js.js:215)
    at __webpack_require__ (:3000/runtime~main.js:36)
    at fn (:3000/runtime~main.js:339)
    at eval (webpack-internal:///./src/pages/index.js:12)
    at Module../src/pages/index.js (:3000/component---site-src-pages-index-jsc-4-f-f99.js:47)
    at __webpack_require__ (:3000/runtime~main.js:36)
    at Function.fn (:3000/runtime~main.js:339)

Made a repro repo here, but it's basically the default docusaurus template with this added to pages/index.js:

import { SandpackRunner } from "@codesandbox/sandpack-react";

const CustomSandpack = () => <SandpackRunner />;

Using version 0.0.6.

[alexnm]

this is strange, feels like the error is coming from this line: https://github.com/codesandbox/sandpack/blob/main/sandpack-client/src/client.ts#L91 but that should be solved by the bundler?! Not familiar with docusaurus, this happens at build time?

[JayaKrishnaNamburu]

So, i spent some time around this. And here are some of the observations. This should be handled in many ways, but the first solution is the best way to do it imo.

Solution

First @codesandbox/codesandbox-client is using process and it's a pure node thing. Which is being polyfilled by bundlers all these years, but from webpack~5 the node built-ins are not polyfilled anymore. So,

• Any packages that target browser shouldn't use process inside them. If they still do so, it's good to remove it in build or anything shipped to npm. And as i see currently sandpack is just transpiling and not doing a build.
• If the usage is mandatory, then the process needs to be polyfilled by the library and so people who consumes it don't need to do it again on their side. (But if every package stat's doing it, then we have node-polyfiils duplicated everywhere in the end build). So, the best way is to remove process from the end build.

I tried making the existing 0.0.6 work. But here the hurdles.

• Docusaurus uses webpack~5 so no auto polyfills. And so, the npm start is failing. It doesn't happen in one of my sandpack use here because it's a nextjs which has a server running and stuff. And so process and some node-builtins are polyfilled to have backwards compatibility with next~10 (Add browser polyfils for Node.js modules (webpack 5 backwards compat) vercel/next.js#16022).
• So, i wrote a custom docusaurus plugin which polyfills node-buildins. Which you can find here https://github.com/JayaKrishnaNamburu/docusaurus-node-polyfills. It's just a simple wrapper, that injects webpack-node-polyfills inside docusaurus config. Here i added and tested it out in a fork of the above example https://github.com/JayaKrishnaNamburu/sandpack-docusaurus-test/blob/trail/node-polyfill/docusaurus.config.js#L80
• And this solves the process polyfill issue with sandpack. But there is one more blocker. Sandpack internally uses codemirror and codemirror internall uses lezer (https://unpkg.com/browse/lezer@0.13.5/package.json).
• And lezer again uses process. Which is ok as we got a polyfill, but lezer is configured as esm with type:module flag. And so, the polyfill need to mention the import extensions .mjs or .js. Here are more details [Question] Is it possible to add extensions for the polyfill routes like .js and .mjs Richienb/node-polyfill-webpack-plugin#14.

So, currently these are all the things, if process/browser resolves in lezer esm. Then docusaurus-node-polyfills unblocks the webpack error.

Here is the fork of the example above
https://github.com/JayaKrishnaNamburu/sandpack-docusaurus-test/blob/trail/node-polyfill/docusaurus.config.js
https://github.com/JayaKrishnaNamburu/sandpack-docusaurus-test/blob/trail/node-polyfill/package.json#L20

Docusaurus plugin for polyfills
https://github.com/JayaKrishnaNamburu/docusaurus-node-polyfills

[alexnm]

wow, nice research @JayaKrishnaNamburu! thanks for taking the time!

On our side we can remove the usage of process in sandpack-client and rely on props when setting up storybook or anything else to run with a local bundler, but we would still have the issue from codemirror I guess.

[JayaKrishnaNamburu]

Yes, the issue still exists with codemirror. Unfortunately, we will run into such issues unless the browser targeted libraries stop using process in end build 😅. So, now only two things left

• Either this PR get's merged and this plugin upgrades it.
• Or just write the fallback in the plugin directly since it's a small change. I will see today if i can write the fallback in the docusaurus plugin itself :)

[alexnm]

Unfortunately, we will run into such issues unless the browser targeted libraries stop using process in end build 😅

I feel like this is almost impossible, since a lot of libraries rely on env variables, even just for checking NODE_ENV

[JayaKrishnaNamburu]

Yes, yes. So, for the moment polyfilling is the right way to solve those problems. Unless web standards come up with something for in browsers 😄

[JayaKrishnaNamburu]

Here is a update, I have the working repo here https://github.com/JayaKrishnaNamburu/sandpack-docusaurus-test/tree/trail/node-polyfill

Just added a new package docusaurus-node-polyfills which i just released by wrapping up the changes https://github.com/JayaKrishnaNamburu/docusaurus-node-polyfills

[pomber]

None of my use cases use the editor, I use sandpack for running the preview, so I don't need codemirror. Not sure how often other people use/will use sandpack without the editor, but have you considered having the preview runner in its own separated package?

[danilowoz]

Hey, we believe that this issue has been solved in the latest release (v0.1.13); please let me know if this bug still persists.

Thanks for reporting it!