"Module not found" in latest release (5.1.7)

[VasylBoyko]

Can't build the app anymore after your last release:

Module not found: Error: Can't resolve 'vm' in '~/app/node_modules/asn1.js/lib/asn1'
@ ./node_modules/asn1.js/lib/asn1.js 5:14-42
@ ./node_modules/parse-asn1/asn1.js 6:11-29
@ ./node_modules/parse-asn1/index.js 3:11-28
@ ./node_modules/browserify-sign/browser/sign.js 9:16-37
@ ./node_modules/browserify-sign/browser/index.js 7:11-28
@ ./node_modules/crypto-browserify/index.js 39:11-37

Looks like problem is here: f230870

[ljharb]

vm is a node core module; presumably your bundler is failing to properly handle node core modules in its browser build?

[VasylBoyko]

Yes, bundler is webpack 5, and it requires to add fallback: vm: require.resolve("vm-browserify").
Now i've added this fallback, and got new crash:
Uncaught TypeError: Cannot read properties of undefined (reading 'slice')
at ./node_modules/browserify-sign/node_modules/readable-stream/lib/_stream_writable.js (_stream_writable.js:57:72)

[ljharb]

Unfortunately webpack 5 decided to stop being a working node core module bundler by default. You'll have to manually configure a bunch of replacements. https://web3auth.io/docs/troubleshooting/webpack-issues#react-create-react-app has an example config that may prove useful.

Specifically, the readable-stream issue is that process.version isn't a string - but https://unpkg.com/readable-stream@2.3.8/lib/_stream_writable.js shows that if your bundler replaces process.browser with true, and then does dead code elimination, that entire line after && would be deleted and wouldn't run.

[VasylBoyko]

but guys, 5.1.7 causes problems in live projects, when 5.1.6 was perfectly worknig. Isn't it a reason to revert this commit?

[ljharb]

@VasylBoyko again, unfortunately, sometimes bugfixes (which this one was) can still break people (obligatory xkcd 1172). i can't conceive of an application, including a RN one, where you wouldn't need to configure webpack and/or metro to properly and implicitly handle node globals and core modules, so I continue to be surprised people run into this.

[porteneuve]

Seeing that you folks downgraded asn1.js one full major down to keep supporting Node 4 when this thing was EOL'd 6.5 years ago and the oldest supported Node LTS is 18, considering this ends up transitively breaking a ton of Webpack 5 / Vite builds, really puzzles me.

Why break everyone's builds just for the sake of a Node version no-one uses anymore, especially in terms of bundling?

[aryzing]

The bugfix version bump was unfortunate. Seems the real bugfix here would be a 5.1.8 that reverts the downgrade, and a v6 with the breaking changes. Reverting a major dependency version to support an EoL'd version of Node that breaks consumers very much looks like a breaking change, not a bug fix.

But what's the upside of the downgrade? Is there a usecase or need for it? Were users asking for it?

[ljharb]

Reverting a bugfix (really, an improvement - it's not a bug to use eval) is not a breaking change.

Yes, downstream dependencies broke without the revert.

A node version being EOL matters precisely zero to semver; a breaking change requires a major bump no matter what. The "bug" existed previously, so restoring it simply isn't a breaking change.