swagger-ui-react broken with react-scripts 5.0.0

[haavardw]

Q&A

• OS: Linux
• Method of installation: yarn
• Swagger-UI version: 4.6.1

To reproduce...

Steps to reproduce the behavior:

$ nvm use 14
$ npx create-react-app my-app --template typescript
$ yarn add swagger-ui-react @types/swagger-ui-react
$ cat <<EOF > src/App.tsx
import React from 'react';
import './App.css';
import SwaggerUI from "swagger-ui-react";
import "swagger-ui-react/swagger-ui.css";


function App() {
  return (
    <SwaggerUI spec="" />
  );
}

export default App;
EOF
$ yarn build

Expected behavior

Successful build

Actual behaviour

yarn run v1.22.17
$ react-scripts build
Creating an optimized production build...
Failed to compile.

Module not found: Error: Can't resolve 'buffer' in '/home/haavardw/tmp/my-app/node_modules/swagger-ui-react'
BREAKING CHANGE: webpack < 5 used to include polyfills for node.js core modules by default.
This is no longer the case. Verify if you need this module and configure a polyfill for it.

If you want to include a polyfill, you need to:
        - add a fallback 'resolve.fallback: { "buffer": require.resolve("buffer/") }'
        - install 'buffer'
If you don't want to include a polyfill, you can use an empty module like this:
        resolve.fallback: { "buffer": false }


error Command failed with exit code 1.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.

[brookjordan]

This is due to the dependency on the unmaintained deep-extend module, which uses Buffer without checks which breaks now that CRA uses a version of webpack which doesn’t include polyfills by default. Would it be reasonable to migrate to something maintained, possibly lodash?

Related issue: #6869

[teodorlu]

There's also a transitive dependency on Buffer.

• src/core/utils.js - generateCodeVerifier -

  swagger-ui/src/core/utils.js

  Lines 893 to 897 in 08829b1

  	export function generateCodeVerifier() {
  	return b64toB64UrlEncoded(
  	randomBytes(32).toString("base64")
  	)
  	}

• which depends on "randombytes"
• which depends on "safe-buffer"

I'm hitting errors here when I try to use Swagger UI from a Vite.js application. safe-buffer works on Node.js, but doesn't work on browsers without a polyfill.

Perhaps it's possible to write a function to generate a 32 bytes of base64 randomness without pulling in two dependencies that are written to run on Node.js?

// adapted from https://auth0.com/docs/flows/guides/auth-code-pkce/includes/create-code-verifier
export function generateCodeVerifier() {
  return b64toB64UrlEncoded(
    randomBytes(32).toString("base64")
  )
}

Edit: made a PR that removes the dependency on randombytes. I've yet to create a unit test - so PR is in draft for now.

#7898

[tim-lai]

@haavardw

Buffer and process/browser are the two known required Node.js polyfills, and SwaggerUI webpack configuration specifically loads them as a plugin here. There are also known fallbacks and aliases specified here

So in your CreateReactApp project, you need to manually include these dependencies buffer and process.

[haavardw]

@tim-lai I'm really surprised this issue got closed. Are you saying a component, swagger-ui-react, clearly made specifically for react, is not meant to work out of the box with the standard way of creating react applications (react-scripts)? At the very least, there's some missing documentation telling people how to make use of it. (No, the links you provided are not that helpful).

[DanielFrontD]

@haavardw I was having the same issue, and the best "solution" that I found is install buffer dependecy and add this line in the src/index.tsx file:

window.Buffer = window.Buffer || require('buffer').Buffer;

EDIT: There is another dependencies that I forgot to mention:

"is-plain-object": "^5.0.0",
"stream": "0.0.2",
"stream-browserify": "^3.0.0",

[teodorlu]

I did some testing, and removing the dependency on Buffer from Node.js shouldn't is an option: #7898. That would let us avoid the polyfills. Note - there may be more work required. I only ran Swagger UI's unit tests, I expect more problems might show up when building.

Tim commented that he'd welcome contributions to documentation - for the fix/walkaround.

I went with something similar with @DanielFrontD's "solution" (:smile:).