Release 0.8, or 0.7.4?

[robhogan]

Hi - I just ran into #432. This was fixed by 48f90d5 back in 2018. The only npm release since then has been 0.8.0-beta.0, which hasn't been widely adopted (eg, by terser) presumably because it's a beta.

Would it be possible to either release 0.8.0 or hotfix 0.7 for that issue, please?

[eemeli]

Having looked into this a bit, I think a 0.7.4 version could be released from commit d69af14, the last one before any breaking changes were made for what has been released as 0.8.0-beta.0.

@loganfsmyth @fitzgen @jkrems I got ping'd in nodejs/node#42638 as a Mozillian, due to [email protected] breaking in Node.js v18. It looks like you've been some of the most active contributors here in the past; would you be ok with me making such a release?

[jkrems]

@eemeli I'd be happy to do a release but I currently don't have access to the npm package. But (assuming https://www.npmjs.com/~eemeli is you) it looks like you do.

I'm currently trying to figure out if it's worth making the necessary changes in 0.7 to make the tests work. It's using an old version of webpack that requires support for md4 as a hash function - and that doesn't work with modern node's crypto module. I ddi take the commit above and created a v0.7.x branch from it.

P.S.: The tests do pass on node 18 at that commit, at least after manually replacing the references to md4 with md5 in the webpack deps.

[jkrems]

Via webpack/webpack#14532: It's still possible to run the test suite without additional changes but it requires NODE_OPTIONS=--openssl-legacy-provider npm t. So - afaict, the code at that commit is in a good state and could be released as 0.7.4.

[jkrems]

I would like to include #456 if we release to ensure that the code in dist/ is in sync with the original sources and is fully reproducible.

[jkrems]

would you be ok with me making such a release?

@eemeli To directly answer your question - I think making that release would be great! It would be nice if we could re-generate dist/ (#456) but that's likely optional if you want to focus on unbreaking people asap.

[maxmilton]

Since the beta release 0.8.0-beta.0 is already being used liberally in the wild, might it make sense to publish the next release as 0.8.0? That way dependency automation tools like Dependabot and Renovate will definitely pick up the new version.

[eemeli]

My initial focus here is indeed in un-breaking things. 0.7.3 currently has 28M weekly downloads, and fixing things for those users with a minimal but sufficient release should be the first step here.

The previously released 0.8.0-beta.0 includes breaking changes, so releasing a new version based on that wouldn't necessarily be sufficient. Really this package ought to be released a 1.0.0 as it's been used in all sorts of production for years now.

@jkrems How about this: If you could update the v0.7.x branch with a re-built dist/ and an updated package.json version, I'll release that on npm?

[robhogan]

WRT the fetch issue that now seems pressing - given typical semver dependencies, a 0.7.4 release would fix issues pretty much automatically - in a lot of cases before people even notice a problem.

A 0.8.0 release would be welcome too of course, but anyone already (transitively) depending on 0.8.0-beta.0 already has the fix, so I'm purely practical terms it's moot for them. Projects transitively dependent on ^0.7.3 would need to wait for intermediate author(s) to update and publish their packages.

So if this fix needs to reach the "end users" actually affected by the bug in a useful timeframe, it needs to be a 0.7.x release, IMO :)

[jkrems]

0.7.3...v0.7.x - I created a tag for 0.7.4 (npm version patch) and pushed it to the v0.7.x branch. @eemeli This should be ready for a npm publish.

[eemeli]

And published: https://www.npmjs.com/package/source-map/v/0.7.4 🎉

[janodvarko]

@eemeli @jkrems Thank you working on the 0.7.4 release!