Posting my notes from the commit message of 562e635 (from PR #678), in case it is helpful:

We can't use NodeJS 18 until we work through this issue:
webpack/webpack#14532

There was a default hashing algorithm for webpack (md4) that is now
considered quite old/obsolete/flawed. It was removed from OpenSSL 3.0.
OpenSSL 3.0 is the version of OpenSSL used in NodeJS 17 and up.

In order to use an LTS version of Node that will receive long-term
support over the next months, but not hit this issue where webpack
errors out due to the md4 hash algorithm not being available in Node
17+, we need to stay on NodeJS 16.x for the time being.

NOTE: NodeJS 16.x will be EOL on the 11th of September 2023, matching
the EOL date for OpenSSL 1.1.1.

See:
https://nodejs.org/en/blog/announcements/nodejs16-eol/
https://github.com/nodejs/release#release-schedule

So this workaround only buys us time until September of this year!!

The "proper" fix for this would be updating to webpack 5 and webpacker
6.x (which was never given a final release, but got as far as a
release candidate), or move to something that is actively supported,
like the alternatives discussed here:
https://world.hey.com/dhh/rails-7-will-have-three-great-answers-to-javascript-in-2021-8d68191b
https://rubyonrails.org/2021/12/6/Rails-7-0-rc-1-released

Hey @DeeDeeG I did some work on this one and from what I can tell, it looks like webpacker did release a version 6.0.0.rc, but the npm package @rails/webpacker did not, which is something else this project relies on. I'll attempt a few other things, but not sure this one is going to be possible without upgrading rails to v7 (which probably needs its own issue if it doesn't already have one).

On the topic of webpacker 6:

I believe the closest thing is either the @rails/webpacker 6.0.0.rc.6 tag (https://github.com/rails/webpacker/tags), as you mentioned, or shakapacker, the "official successor ro rails/webpacker" (whatever that means, since it's rather unconventional): https://github.com/shakacode/shakapacker.

As for the git tag of @rails/webpacker, it is possible to specify JS dependencies as a git URL, such as "@rails/webpacker": "https://github.com/rails/webpacker#v6.0.0.rc.6" in package.json. Although I have not tested to see if this works or required the webpacker team to do some further packaging steps before publishing it, in order for it to be usable.

I did try to upgrade to newer webpack + webpacker myself, but the configuration files and project setup for using Webpack are very unfamiliar to me, the docs weren't clear enough to me, and I got stuck somewhere through attempting this myself. Anyone more familiar with Webpack might have more success with this, hopefully.

On the topic of Rails 7:

Yes, if we can manage to upgrade to Rails 7 in all this, or even by itself without breaking anything else, that would be welcome in its own right.

Last time we got to Rails 6, I was expecting it to require a large migration effort, but someone upgraded Rails 6 in-place over Rais 5 with essentially no further changes. (Here: 520e8c5 from #675.)

(I have been nervous to attempt this myself, but perhaps it will "just work" updating Rails to version 7 in the Gemfile? Even if not, upgrading to Rails 7 would be welcome.)

It's possible we can "cheat" a bit, or use a workaround, by exporting the environment variable NODE_OPTIONS=--openssl-legacy-provider in the environment where the app runs.

I can easily add it as an env var (and bump to newer NodeJS) in the Dockerfile in the root of this repo, to test that out with a newer NodeJS version. And then it would require one of the other maintainers' cooperation in order to set this env var in our Heroku environment as well, if this is something proven to work.

I will take some time to test this today, as a quick/minimal approach with the goal of getting to Node 18.

(I reviewed the issue thread webpack/webpack#14532 again recently, and from a comment in that thread, I noticed this suggested workaround. Not sure why I hadn't tried this earlier, other than the want to properly upgrade anyway making "workarounds" seem like the wrong approach at the time. But since NoeJS 16 support is over, now may be the time for whatever quickest/smallest fix is possible.)

The workaround env var + bumping to NodeJS 18 (or 20) seems to be working.

And I believe I can set the env var for production via the Heroku app configuration file app.json. So, I will propose this as a PR and give the other maintainers a chance to review it, otherwise I will wish to go ahead with it if no feedback from them.

Being stuck on unsupported NodeJS isn't great. I consider this part of my ongoing dependency bumps.