Next 13/14 - Isomorphic DOMPurify - Build Error

[mikeriley131]

Summary

isomorphic-dompurify version - 1.9.0
Node version - 18.18.0
Next.js version - 13.5.4 (also reproduced with Next 14)
React version - 18.2.0

I am importing my company's React component library that makes use of Isomorphic DOMPurify.
No issues when using it in a client-side app.
However, when running yarn build in my Next.js project I am getting ReferenceError: window is not defined and the path in the logs points to the following line of code: var ti=window.DOMPurify||(window.DOMPurify=Vl().default||Vl());

In the issue for the package - kkomelin/isomorphic-dompurify#228 - it was suggested that possibly Next treats the browser field in the package.json as a server entry point. Could this be the culprit?

Additional information

No response

Example

No response

[icyJoseph]

Hi,

Without much knowledge into the matter, it seems to me that the problem is that, this library is doing a strange check... typeof process === "undefined" is not a reliable check for client side. They should do typeof window !== "undefined", since after all, they expect to work with the window object.

If you copy their code, and tweak it a bit:

"use client";

function resolveDOMPurify() {
  const isClientSide = typeof process === "undefined";
  return isClientSide ? console.log("client") : console.log("server");
}

resolveDOMPurify();

export const Button = () => {
  return (
    <button type="button" >
      +1
    </button>
  );
};

It'll log server on the client.

I am not sure in what context you use it, but that's more or less the problem.

I am gonna drop something from the Apollo GraphQL Docs:

It's impossible for Apollo Client to use a guard statement like typeof process !== "undefined" && process.env.NODE_ENV !== 'production' because some bundlers, such as esbuild, cannot replace a statement like typeof process at build time. The development-only code would remain after the build, resulting in no bundle size reduction.

In contrast, checking for globalThis.DEV does not crash the browser and can be eliminated by every bundler.

As for your issue, perhaps defer usage of this library to the client side, by using next/dynamic, or hiding it behind a boolean that is set on the client only, for example within a use-effect. This of course has implications for the initial HTML string that you'll send to your clients.

[mikeriley131]

@icyJoseph Any thoughts since seeing the error in the demo repo?

[icyJoseph]

Oh, sorry, I thought it was clear. You are bundling your components library incorrectly.

Forget about Next.js for a moment, and go to the pyrographic-react-component-library, build it and inspect the contents of dist/main.js I guess? Or maybe it is button or something, but you'll see that Rollup has inlined everything in there, so that when it is imported, say in a Node env, the parser finds a window reference, and it explodes.

I haven't worked with Rollup for a while now, it ought to be a Vite setting or a Rollup specific, that you have to look at.

Edit

Yeah you had it:

../pyrographic-react-component-library/dist/components/Button/index.js (509:9) @ window

  507 | }(Ce)), Ce.exports;
  508 | }
> 509 | var fn = window.DOMPurify || (window.DOMPurify = ht().default || ht());

It is dist/components/Button/index.js, where the bundler has inlined everything. You have to figure out how to create proper bundles for node/browser, etc, through Rollup/Vite, not sure which one is not properly configured.

[mikeriley131]

Hmmmm, OK. Thanks for clarifying.
I followed this tutorial - https://dev.to/receter/how-to-create-a-react-component-library-using-vites-library-mode-4lma
I have no idea what the improper configuration might be.

[icyJoseph]

Mmm like I said it has been a while since I bundled stuff using rollup, but I think you need to tell it to output two bundles, one for the server and one for clients.

And your package.json should expose a main pointing to the server, and a browser key pointing to the browser bundle.

[mikeriley131]

Thank you. I found this post that seems to replicate what you're describing - https://stackoverflow.com/questions/62459725/how-to-import-a-different-bundle-for-server-and-client-using-rollup-in-sapper

I appreciate the help.

[kkomelin]

Hey everyone,

The isomorphic-dompurify maintainer is here.

I do think the browser.js is for some reason used here because the code which causes the error is:

var ti=window.DOMPurify||(window.DOMPurify=Vl().default||Vl());

and the content of the browser.js is:

module.exports = window.DOMPurify || (window.DOMPurify = require('dompurify').default || require('dompurify'));

which I think are almost identical.

[icyJoseph]

Mmm I don't think the "use client" directive was necessary.

Are we talking about the same issue as OP? I remember that OPs case was happening because their library already packed the wrong Dom purify version, so it had nothing to do with Next.js

[mikeriley131]

Was it the wrong DOMPurify version? I'm on the latest version. I understood the replies to suggest that I needed to somehow generate a version for SSR apps that does not include references to window. But unfortunately have not yet found any guides on how to do that. Did I misunderstand the responses?

[BohdanYavorskyi]

@mikeriley131 seems the latest v 3.0.5 is on this isomorphic package. I checked the app 2h ago and it still fails on nextjs app router server pages.

I understood the replies to suggest that I needed to somehow generate a version for SSR apps that does not include references to window

I guess yeah

[silasabbott]

This may or may not be related, but I'm experiencing the same error with isomorphic-dompurify when deploying SvelteKit on Vercel Edge Functions. Not sure who's the culprit in these situations. When deploying with Vercel Serverless Functions everything works great.

Here's the package.json browser field spec for reference. Bundlers/tooling should be respecting this field for browser environments as far as I know.

[kkomelin]

I agree with @silasabbott