Project fails to compile on Node.js >= 17 (Error: error:0308010C:digital envelope routines::unsupported)

[winghouchan]

Hello! I've got an upcoming technical interview and was checking everything runs smoothly before the session. I did find an issue and here's the report.

---

Environment

• Node.js: 17.x, 18.x (LTS)

Steps to reproduce

1. Run yarn start.

Expected behaviour

The project compiles successfully.

Actual behaviour

The project fails to compile. The error in the output from yarn start is:

Failed to compile.

ERROR in ./src/assets/logo.svg

Module build failed (from ./node_modules/file-loader/dist/cjs.js):
Error: error:0308010C:digital envelope routines::unsupported
    at new Hash (node:internal/crypto/hash:67:19)
    at Object.createHash (node:crypto:135:10)
    at getHashDigest (/Redacted/cleo-frontend-interview/node_modules/loader-utils/lib/getHashDigest.js:46:34)
    at /Redacted/cleo-frontend-interview/node_modules/loader-utils/lib/interpolateName.js:113:11
    at String.replace (<anonymous>)
    at interpolateName (/Redacted/cleo-frontend-interview/node_modules/loader-utils/lib/interpolateName.js:110:8)
    at Object.loader (/Redacted/cleo-frontend-interview/node_modules/file-loader/dist/index.js:29:48)

On Node.js 16, the project compiles successfully.

⚠️ Note for prioritisation

Node.js 16 is over 2 years old and reaches end-of-life on 2023-09-11. There will likely be more users on Node.js versions >= 17.

Investigation

The error comes from loader-utils. yarn why shows 2.0.0 is being used:

$ yarn why loader-utils
yarn why v1.22.19
[...]
=> Found "loader-utils@2.0.0"
info Has been hoisted to "loader-utils"
info Reasons this module exists
   - Hoisted from "react-scripts#@pmmmwh#react-refresh-webpack-plugin#loader-utils"
   - Hoisted from "react-scripts#@svgr#webpack#loader-utils"
   - Hoisted from "react-scripts#babel-loader#loader-utils"
   - Hoisted from "react-scripts#file-loader#loader-utils"
   - Hoisted from "react-scripts#resolve-url-loader#loader-utils"
   - Hoisted from "react-scripts#resolve-url-loader#adjust-sourcemap-loader#loader-utils"
info Disk size without dependencies: "84KB"
info Disk size with unique dependencies: "528KB"
info Disk size with transitive dependencies: "632KB"
info Number of shared dependencies: 4
[...]

The hashType passed into crypto.createHash is likely the start of the problem, see loader-utils@2.0.0/lib/getHashDigest.js:46:34.

Node.js 17 updated from OpenSSL 1.x to OpenSSL 3.0 (see Node.js 17 release notes). OpenSSL 3.0 deprecated some hashing algorithms (see OpenSSL 3.0 Migration Guide and list of legacy of algorithms). loader-utils@2.0.0 is likely using MD4 (its default should no algorithm be specified) or some other algorithm that's been deprecated in OpenSSL 3.0 so when it is run in an environment with Node.js >= 17 the reported error is thrown.

Resolution

The recommended resolution is to:

Upgrade to loader-utils@^2.0.1

loader-utils fixes this issue in 2.0.1 (changelog, PR). ^2.0.1 is within the existing acceptable dependency range of ^2.0.0 so I don't foresee any problems. My own testing yielded no side effects.

Alternative resolutions

Configure Node.js to use OpenSSL legacy provider

If loader-utils can't be upgraded for some reason then Node.js can be configured to use the OpenSSL legacy provider. The OpenSSL legacy provider allows usage of legacy algorithms. Node.js can be configured to use this through the --openssl-legacy-provider option (Node.js documentation). This can be done by providing the option in the start script as react-scripts will forward the option to Node.js (reference):

package.json

  "scripts": {
-    "start": "react-scripts start",
+    "start": "react-scripts start --openssl-legacy-provider",

There's no significant risk here as the hashing algorithms are only generating file hashes. However, upgrading the dependency should be the preferred option.

Configure a Node.js version

For users that use a Node.js version manager (e.g. fnm), configuring the relevant configuration file (e.g. .node-version) will ensure a Node.js version without problems is used. The risk here is not everyone uses a Node.js version manager; and even for those that do, the configuration file is not a standard (many support .node-version but some, like nvm, do not (reference)). However, this option could be done anyway, in combination with one of the above, to improve the chance of running the project in a consistent environment.

Additional notes

It may be worth notifying folks who have recently cloned the repo of this issue so that they can either resolve themselves or pull if the issue is resolved here.