[DOMPurify] Gatsby production build fails after @carbon/ibmdotcom-react v1.8.0

[bkfrye]

Detailed description

When running gatsby build with the @carbon/ibmdotcom-react package >v1.8.0, the build will fail. Output is below.

Generating SSR bundle failed

Can't resolve 'canvas' in '/Users/brandonfrye/Sites/9892-ibm-security-managed-security-services-demo/node_modules/jsdom/lib/jsdom'

If you're trying to use a package make sure that 'canvas' is installed. If you're trying to use a local file make sure that the path is correct.

File: node_modules/jsdom/lib/jsdom/utils.js

This issue occurs when any ibmdotcom-react component is added and there are no instances of canvas elements being used. Expected outcome should be a successful Gatsby production build. This works as expected up to v1.8.0, but any releases after that version result in the failed production build.

This has been a common issue since the release of v1.9.0 and has interrupted the agencies workflow (Centerline Digital) for producing pages for multiple business units within IBM. We have been limited to using v1.8.0 with manual updates to match the latest releases, but this has become cumbersome.

Steps to reproduce the issue

1. Setup Gatsby project and install @carbon/ibmdotcom-react
2. Include an IBM dotcom component(s) such as <Masthead /> or <DotcomShell />
3. Run gatsby build

Additional information

• Node v12.18.4
• GatsbyJS v2.24.68

[jeffchew]

Hi @bkfrye , thank you for your issue report!

Adding @kennylam here as he took a look at the issue, and believe it may have been introduced by an unrelated component from the Masthead (which involves handling of markdown), which is why canvas is missing. We will take a look and see if it's a missing dependency for that particular component, but can suggest a couple of things on your end to get around this issue:

1. Instead of importing as import { Masthead } from '@carbon/ibmdotcom-react';, it's possible that the tree-shaking is finding some side effects which we will look into as to why that is happening. For now, you can pull the es module directly instead:

import Masthead from '@carbon/ibmdotcom-react/es/components/Masthead/Masthead';

or

import DotcomShell from '@carbon/ibmdotcom-react/es/components/DotcomShell/DotcomShell;

2. Other option is to install canvas on your end for now, which could get rid of this issue. But I would suggest the above first as this would put less heavy lifting on the webpack side to rely on the treeshaking.

cc: @raphaelamadeu

[kennylam]

@jeffchew @bkfrye Confirmed importing the module directly does not result in build errors.

[jeffchew]

Noticing that even when installing canvas if you do want to use a component that needs it, the build is breaking:

[asudoh]

Seems that isomorphic-dompurify code runs during Gatsby's build process, which is reported at kkomelin/isomorphic-dompurify#35. isomorphic-dompurify runs DOMPurify in JSDOM environment in node.js environment. Unless DOMPurify depends on JSDOM understanding <canvas> (instead of treating it as an HTMLUnknownElement), adding below to gatsby-node.js seems to workaround this:

plugins: [
  new webpack.IgnorePlugin(/canvas/)
]