Upgrading to v12.17.4 broken node 17 support

[MCFreddie777]

Current behavior

After recent upgrade to v12.17.4, which contains related changes to webpack@5, on node 17, cypress fails with following:

Your configFile threw an error from: cypress.config.js

We stopped running your tests because your config file crashed.

Error: error:0308010C:digital envelope routines::unsupported
    at new Hash (node:internal/crypto/hash:71:19)
    at Object.createHash (node:crypto:133:10)
    at module.exports (/Users/feri/Desktop/e2e-tests/node_modules/webpack/lib/util/createHash.js:135:53)
    at NormalModule._initBuildHash (/Users/feri/Desktop/e2e-tests/node_modules/webpack/lib/NormalModule.js:417:16)
    at handleParseError (/Users/feri/Desktop/e2e-tests/node_modules/webpack/lib/NormalModule.js:471:10)
    at /Users/feri/Desktop/e2e-tests/node_modules/webpack/lib/NormalModule.js:503:5
    at /Users/feri/Desktop/e2e-tests/node_modules/webpack/lib/NormalModule.js:358:12
    at /Users/feri/Desktop/e2e-tests/node_modules/loader-runner/lib/LoaderRunner.js:373:3
    at iterateNormalLoaders (/Users/feri/Desktop/e2e-tests/node_modules/loader-runner/lib/LoaderRunner.js:214:10)
    at Array.<anonymous> (/Users/feri/Desktop/e2e-tests/node_modules/loader-runner/lib/LoaderRunner.js:205:4)
    at Storage.finished (/Users/feri/Desktop/e2e-tests/node_modules/enhanced-resolve/lib/CachedInputFileSystem.js:55:16)
    at /Users/feri/Desktop/e2e-tests/node_modules/enhanced-resolve/lib/CachedInputFileSystem.js:91:9
    at /Users/feri/Desktop/e2e-tests/node_modules/graceful-fs/graceful-fs.js:123:16
    at /Users/feri/Library/Caches/Cypress/12.17.4/Cypress.app/Contents/Resources/app/packages/server/node_modules/graceful-fs/graceful-fs.js:123:16
    at /Users/feri/Library/Caches/Cypress/12.17.4/Cypress.app/Contents/Resources/app/packages/server/node_modules/graceful-fs/graceful-fs.js:123:16
    at FSReqCallback.readFileAfterClose [as oncomplete] (node:internal/fs/read_file_context:68:3)

I am still using webpack v4 preprocessor (plugins/index.ts):

import * as path from 'path';
import * as fs from 'fs';
import toMatchTruthScreenshot from './to-match-truth-screenshot.plugin';
import addPublicKeyToRemoteServer from './add-public-key-to-remote-server.plugin';
import PluginEvents = Cypress.PluginEvents;
import { getVariable } from '../../../ci/scripts/env';
import PluginConfigOptions = Cypress.PluginConfigOptions;

const webpack = require('@cypress/webpack-preprocessor');
const webpackOptions = {
    resolve: {
        extensions: ['.ts', '.js'],
    },
    module: {
        rules: [
            {
                test: /\.ts$/,
                exclude: /node_modules/,
                use: [
                    {
                        loader: 'ts-loader',
                        options: {
                            configFile: path.resolve(__dirname, '../../tsconfig.json'),
                        },
                    },
                ],
            },
        ],
    },
};

// @ts-ignore-next-line no-unused-vars
module.exports = (on: PluginEvents, config: PluginConfigOptions) => {
    on('file:preprocessor', webpack({ webpackOptions }));

Therefore, I have manually babel & webpack dependencies installed. With these dependencies explicitly defined in package.json, it fails.

Desired behavior

If you check out to 12-17-3 branch, everything works fine and the tests pass.

Test code to reproduce

The code is available here: https://github.com/MCFreddie777/cypress-12-17-4

Cypress Version

12.17.4

Node version

v18.4

Operating System

macOS 13.4.1

Debug Logs

No response

Other

No response

[AtofStryker]

Hi @MCFreddie777 . Thank you for opening an issue. The issue you are experiencing is a Webpack 4 compatibility issue with Node 17 and above. Cypress was previously working around this by setting NODE_OPTIONS=--openssl-legacy-provider in the node process for users with node versions above 16. To resolve this on your end, there are a few options you can explore.

• set NODE_OPTIONS=--openssl-legacy-provider with node 17 and above when invoking cypress which will allow your node process to work with webpack 4 (ex: NODE_OPTIONS=--openssl-legacy-provider npx cypress open)
• update to webpack 5. The @cypress/webpack-preprocessor is backwards compatible between Webpack 4 and 5, so it just uses the installed version. I don't know how complex your actual preprocessor setup/webpack setup is (if your app is using the same version in a repo), but based on the reproduction provided this should be a simple bump from 4.46.0 to 5.88.2.
• downgrade to Node 16 as node 16 uses the older ssl provider by default, which is going EOL on September 11th, 2023 (not recommended).

The first option should be suitable to get things up and running as a workaround until you are able to update to webpack 5. I have a few details in the pull request, which is a bit wordy and don't expect anyone to read, but there is a snippet in there I do want to share for reference for other users who might run into this issue.

If users are using the file:preprocessor hook inside plugins, users can still use webpack@4 still and will not be broken, even though cypress is bundled with webpack 5. The only stipulation to continuing using webpack@4 is that users remain on Node 16 as webpack@4 has this issue that will not be backpatched from webpack. We recommend users upgrade to recent versions of webpack and node, as Node 16 will be EOL in Q3 of 2023

[MCFreddie777]

If this can be a breaking change for some users like me, shouldn't this be a major version update , respecting the semantic versioning? Due to complications with other packages I'm unable to update webpack as it is pure esm package and not all of my packages are esm.

…

On Fri, 18 Aug 2023 at 4:23 PM, Bill Glesias ***@***.***> wrote: Hi @MCFreddie777 <https://github.com/MCFreddie777> . Thank you for opening an issue. The issue you are experiencing is a Webpack 4 compatibility issue <webpack/webpack#14532> with Node 17 and above. Cypress was previously working around this by setting NODE_OPTIONS=--openssl-legacy-provider in the node process for users with node versions above 16. To resolve this on your end, there are a few options you can explore. - set NODE_OPTIONS=--openssl-legacy-provider with node 17 and above when invoking cypress which will allow your node process to work with webpack 4 (ex: NODE_OPTIONS=--openssl-legacy-provider npx cypress open) - update to webpack 5. The @cypress/webpack-preprocessor is backwards compatible between Webpack 4 and 5, so it just uses the installed version. I don't know how complex your actual preprocessor setup/webpack setup is (if your app is using the same version in a repo), but based on the reproduction provided this should be a simple bump from 4.46.0 to 5.88.2. - downgrade to Node 16 as node 16 uses the older ssl provider by default, which is going EOL on September 11th, 2023 <https://nodejs.org/en/blog/announcements/nodejs16-eol> (not recommended). The first option should be suitable to get things up and running as a workaround until you are able to update to webpack 5. I have a few details in the pull request <webpack/webpack#14532 (comment)>, which is a bit wordy and don't expect anyone to read, but there is a snippet in there I do want to share for reference for other users who might run into this issue. If users are using the file:preprocessor hook inside plugins, users can still use ***@***.*** still and will not be broken, even though cypress is bundled with webpack 5. The only stipulation to continuing using ***@***.*** is that users remain on Node 16 as ***@***.*** has this issue that will not be backpatched <webpack/webpack#14532 (comment)> from webpack. We recommend users upgrade to recent versions of webpack and node, as Node 16 will be EOL in Q3 of 2023 <https://nodejs.org/en/blog/announcements/nodejs16-eol> — Reply to this email directly, view it on GitHub <#27589 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AGUUGG665UOA6EGNNAX6NILXV53FFANCNFSM6AAAAAA3VNC63A> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[AtofStryker]

Due to complications with other packages I'm unable to update webpack as it
is pure esm package and not all of my packages are esm.

AFAIK you can update webpack without being entirely on ESM, as we were in a similar boat. But the upgrade is definitely a large lift and I can understand that it isn't something that can be accomplished easily. It was definitely a large lift for us and is the main reason it took us years to upgrade.

If this can be a breaking change for some users like me, shouldn't this be
a major version update , respecting the semantic versioning?

We had extensive conversations internally on whether we wanted to consider this update a breaking change, and opted not to due to the rare likelihood of complications likely contained to a small subset of users with workarounds readily available. In addition to Cypress v13 right around the corner, the team felt it was best to merge this change in sooner rather than later so we can help separate concerns of v13 issues vs a subset of minor issues coming in through possible webpack problems.

That being said, if updating webpack is not an option, leveraging NODE_OPTIONS=--openssl-legacy-provider should work in your scenario if on a Node version greater than 16. If you intend to use webpack 4 with a version of node greater than 16, this option must be present. We no longer provide it for our process as we don't need it, but any user who is using webpack 4 with node greater than 16 should be providing this option independently of Cypress to guarantee compatibility.

That being said, providing NODE_OPTIONS=--openssl-legacy-provider should work. I gave it a run with the reproduction repository provided and did not run into any issues. Can you confirm this also works on your end?

[MCFreddie777]

We had extensive conversations internally on whether we wanted to consider this update a breaking change, and opted not to due to the rare likelihood of complications likely contained to a small subset of users with workarounds readily available. In addition to Cypress v13 right around the corner, the team felt it was best to merge this change in sooner rather than later so we can help separate concerns of v13 issues vs a subset of minor issues coming in through possible webpack problems.

Still, according to semver methodology, this should not be released as a "hotfix". Definitely not a hotfix, rather then a new feature.

[AtofStryker]

Still, according to semver methodology, this should not be released as a "hotfix". Definitely not a hotfix, rather then a new feature.

I don't know if I agree as Cypress has considered the possibilities extensively and used our best judgement accordingly, which is in alignment with semver's FAQ and practices. At least to us, this doesn't seem like a new feature of the product, rather a dependency update with possible rare side effects depending on the user and would highly unlikely affect a significant population of our users.

Regardless, I want to make sure that you are able to continue running Cypress and that the workarounds provided are sufficient to help resolve your issue.

[khitrenovich]

If this can be a breaking change for some users like me, shouldn't this be a major version update , respecting the semantic versioning?

Agree here - We are on Webpack 5, and this "patch" broke things for us also.
If there is a remote possibility the change will be breaking for some users, it should be a major version.

Error Details

Error: Webpack Compilation Error
Module not found: Error: Can't resolve 'process/browser' in '....../node_modules/ts-invariant/process'
Did you mean 'browser.js'?
BREAKING CHANGE: The request 'process/browser' failed to resolve only because it was resolved as fully specified
(probably because the origin is strict EcmaScript Module, e. g. a module with javascript mimetype, a '*.mjs' file, or a '*.js' file where the package.json contains '"type": "module"').
The extension in the request is mandatory for it to be fully specified.
Add the extension to the request.

[AtofStryker]

@khitrenovich this looks related to webpack but a separate problem. Would you be able to open an issue and provide a reproduction for the issue you are facing?

[khitrenovich]

@khitrenovich this looks related to webpack but a separate problem. Would you be able to open an issue and provide a reproduction for the issue you are facing?

Sure, I'll try to spend some time on that next week. Regardless, my main point was about versioning.

[AtofStryker]

@khitrenovich #27599 looks to be the issue you are describing, which I am working on investigating this morning. The issue I am linking looks to be an unintended break from the update.

[AtofStryker]

Unfortunately we have to close this issue due to inactivity. I believe this issue is solved and has a reasonable workaround. Please comment if there is new information to provide concerning the original issue and we can reopen.

[poreddybindusarika]

Hi, when I updated to Node V20.9.0 my scripts are failing. Right side pane after launching browser is not visible. The web page is blank and scripts couldn't detect web elements, hence failing. Any solution, I have been trying to fix it for 2 days now. Any help is appreciated.
Cypress: 13.4.0
Node: 20.9.0
Npm: 10.1.0

[AtofStryker]

@poreddybindusarika are you able to open a separate issue with a reproduction of the problem?