Uglifyjs: Changelog & Release Quality Control

[bdkjones]

Hi Guys,

This issue has two parts.

1. Can we get an official changelog added to the repo? It's virtually impossible to tell what the heck is in each release of Uglify because a lot of the commit messages require a solid understanding of the codebase. Adding a changelog and updating it for each release would really help us see what's going on.

2. In the past few months, as @alexlamsl has been working on Uglify, the pace of releases has become...well...pretty crazy. There's a new version every few days. That's not a bad thing in-and-of-itself, but a lot of these releases seem to introduce bugs and the subsequent release is designed to fix those. In short, it seems like the quality of releases has declined as the pace has accelerated. I'm not sure what your CI and testing/coverage stats are, but would it be possible to perhaps let releases bake a little longer so these issues are caught before shipping?

[alexlamsl]

@bdkjones this is Open Source & everyone here contributes for free - if you need anything, consider doing the work rather than typing up unsolicited opinions.

Closing as there isn't anything directly actionable.

[bdkjones]

Hmm. I'm not sure that was a constructive response. I think the request for a changelog is pretty actionable---in fact Uglify is the only tool I use/know-of that doesn't have one.

I've known @mishoo since at least 2011 and have routinely found him to be the most responsive, professional developer of the many tools I use. I regret that you and I have gotten off on the wrong foot, @alexlamsl, but I look forward to the day when I can say that about you as well.

As for "unsolicited opinions": I'd be happy to post the dozens and dozens of emails I got when I shipped an officially-released version of Uglify that broke minification for my users. I've been using Uglify since 2011 and have found it to be virtually bulletproof before you began cutting releases.

In the meantime, please add a changelog. Thanks!

[bdkjones]

@mishoo If you'd consider the Changelog request, I'd appreciate it. Uglify is still your project, right?

[alexlamsl]

@bdkjones please file issue reports with reproducible details for the failures you and/or your users have encountered.

Better yet, submit Pull Requests that fix said issues.

[bdkjones]

Mmmhmm. I came here to do that when the issue occurred a few months ago and found that the bug (which was introduced in one release) was fixed in a release two days later. For years I've always shipped the latest official release of Uglify because I knew I could trust it. Now, I've adjusted that strategy so that I stay a few releases behind because it seems like the latest release has turned into a bit of a beta channel.

I don't mean that as a personal attack---I'm actually very happy to see you contributing monumental amounts of effort to the project. I just can't help but notice the reliability of the officially tagged releases has been a bit questionable the last few months.

[kzc]

It is good practice to always test your code extensively with any npm package and use version lock files.

Every uglify patch release - even for bug fixes - has the potential to break code. This has been the case for years. It's just that the pace of development has accelerated in order to achieve smaller minified output. Bugs are never intentionally introduced. Automated testing is more extensive now than Uglify has had in its history. But there's no such thing as bug free code.

[bdkjones]

@kzc I agree completely. That's why I suggested the addition of an official changelog. Just like Babel, or Libsass, or ESLint or Webpack, etc. Every major tool
I can think of publishes one so that folks can figure out what's changed and where they should look for potential problems when upgrading. UglifyJS is the sole outlier. Here, it's really tough to know what's in each release, even if you go read the commit history, because many commit messages are brief and only really make sense to the developers actively working on the project. So you end up with a slew of releases separated by a few days and no clue what's changing between them.

I'm actually a little surprised at the vitriolic response to a changelog request. Every major tool I can think of publishes one and many (like those of ESLint and Babel) are absolutely excellent. The response here makes it seem like I asked you guys to rewrite the project in Java or something.

That said, your competitors do this. Closure. Babili. Here's the Changelog for the latter: https://github.com/babel/babili/blob/master/CHANGELOG.md

If Uglify had a similar document, that would make using, testing and updating the tool much easier for implementors.

Sent from my iPhone

On Jun 20, 2017, at 19:11, kzc [e-mail] wrote:

It is good practice to always test your code against any npm package and use version lock files.

Every uglify patch release - even for bug fixes - has the potential to break code. This has been the case for years. It's just that the pace of development has accelerated in order to achieve smaller minified output. Bugs are never intentionally introduced. Automated testing is more extensive now than Uglify has had in its history. But there's no such thing as bug free code.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

[Alhadis]

I'm actually pretty disgusted by the maintainer's attitude. The OP's request was a sane and well-justified one, especially considering UglifyJS has gone six years without logging at least the peripherals of its evolution. If you don't have time to write it up, fine, but don't give your contributors crap over the request. One of them might end up writing the whole damn thing.

And let me tell you, with the file-icons change-log pushing almost 1500 lines of condensed, compressed summaries, I'm damn glad I got the log written and out of the way sooner rather than later.

[bdkjones]

Thanks @alhadis. I thought so, too. I've started looking into the feasibility of replacing Uglify with other tools.

[Alhadis]

Lack of manpages are what convinced me to consider an alternative, too. I only use uglifyjs from command-line... and for years, this has driven me crazy:

~console
$ man uglify-js
No manual entry for uglify-js
~

Then again, neglecting terminal users is unfortunately widespread in the Node community...

~console
$ man mocha
No manual entry for mocha
$ man coffee-script
No manual entry for coffee-script
$ man clean-css
No manual entry for clean-css
$ man you-gotta-be-fuckin-kidding-me
~

[bathos]

I just upgraded from 3.2.2 to 3.3.2. I got a useful message that cascade is not a recognized option. I had had it disabled because I’m doing a very limited transform to remove dead branches as part of a more complex build process, but am not minifying.

So I went to check the changelog to see what I should do next — was the option renamed? removed? had it been replaced with multiple, more granular options? I didn’t know if this meant I should just remove my previous usage or if I needed to update it to something else.

When I looked for the changelog, I found this (and other similar) threads instead. Following the advice inside, I began searching the commit history. After a not-so-brief search, I did come across what I was looking for — 49 commits back:

https://github.com/mishoo/UglifyJS2/commit/ef618332ea92db57e59f90f166035a0e7cf8a509#diff-04c6e90faac2675aa89e2176d2eec7d8

Ultimately, this did answer my question. It worked. But this really is an unusual approach to communicating with users about changes, because commits don’t usually communicate what users need to know, and bug fixes, refactoring, maintenance tasks etc bury changes that impact users. Especially for a library that changes its API on minor version releases, I think it represents a pretty significant usability issue.

Given the earlier exchange in this thread, I want to emphasize that is is merely feedback on usability. It’s not a demand or an expectation — like most people here probably, I work on OSS stuff too and know that it’s up to the maintainers what they decide is worth their time. But it does seem to be in-bounds to give feedback on "meta" problems that come up when using a package via Github issues, right?

[bdkjones]

Sadly, I think that message is falling on deaf ears. I thought a request for a changelog was pretty reasonable, but was taken aback by the response. My eventual goal is to replace Uglify with a different minifier that is more professionally maintained.

Sent from my iPhone

On Dec 25, 2017, at 22:52, Darien Maillet Valentine [e-mail] wrote:

I just upgraded from 3.2.2 to 3.3.2. I got a useful message that cascade is not a recognized option. I had had it disabled because I’m doing a very limited transform to remove dead branches as part of a more complex build process, but am not minifying.

So I went to check the changelog to see what I should do next — was the option renamed? removed? had it been replaced with multiple, more granular options? I didn’t know if this meant I should just remove my previous usage or if I needed to update it to something else.

When I looked for the changelog, I found this (and other similar) threads instead. Following the advice inside, I began searching the commit history. After a not-so-brief search, I did come across what I was looking for — 49 commits back:

ef61833#diff-04c6e90faac2675aa89e2176d2eec7d8

Ultimately, this did answer my question. It worked. But this really is an unusual approach to communicating with users about changes, because commits don’t usually communicate what users need to know — bug fixes, refactoring, maintenance tasks etc bury changes that impact users. Especially for a library that changes its API on minor version releases, I think it represents a pretty significant usability issue.

Given the earlier exchange in this thread, I want to emphasize that is is merely feedback on usability. It’s not a demand or an expectation — like most people here probably, I work on OSS stuff too and know that it’s up to the maintainers what they decide is worth their time. But it does seem to be in-bounds to give feedback on "meta" problems that come up when using a package via Github issues, right?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

[chevinbrown]

@bdkjones our team feels the same way. Have you found a good alternative?
I got a quick response here, but none more helpful: https://github.com/mishoo/UglifyJS2/issues/2950

[bdkjones]

I’ll probably use Google’s. I haven’t had time to switch them yet, so I just stopped updating Uglify until I can get onto a better-maintained minifier.

Sent from my iPhone

On Feb 23, 2018, at 07:57, Kevin Brown [e-mail] wrote:

@bdkjones our team feels the same way. Have you found a good alternative?
I got a quick response here, but none more helpful: #2950

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

[Alhadis]

The minifier needs a better maintainer. @alexlamsl should leave the hall.

[bdkjones]

@alexlamsl is very productive and appears to be a good developer. But his professionalism and people skills need a lot of work. What Uglify REALLY needs is a good manager who can oversee the releases and write a solid changelog so users know what they're getting. ESLint is an EXCELLENT example of how to do that correctly.

[bdkjones]

@bathos I agree that free projects have no obligation to provide anything. However, if you want your project to be embraced by the community, there are some baseline expectations such as:

1. It should be stable and reasonably bug-free.
2. It should clearly communicate what's changing in each release so folks know what to expect and what they need to update/change on their end to make the new version work.
3. It should be welcoming of feedback and ideas, even if those ideas are ultimately not used—it should not angrily reject reasonable requests with a dismissive, "If you want it, build it yourself" rant.

Of course, no project MUST provide those things. But projects that do not provide them generally fall by the wayside.

[bathos]

I agree @bdkjones that those are sensible things which many people, myself included, do take into account when deciding what software to use. However I’m pretty uncomfortable with the tone of some comments in this thread.

[Alhadis]

What Uglify REALLY needs is a good manager who can oversee the releases and write a solid
changelog

This repository's modification history is rapid and cryptic, and the commit summaries fail to communicate either the nature or motive behind their changes. Mediating and overseeing releases is precisely one of the duties of a maintainer - the responsibilities of maintaining a codebase don't stop at source code.

Furthermore, even if somebody were to step in and document everything, it'd likely be exhausting and fraught with miscommunication and frequent requests for elaboration.

[curiousdannii]

IMO if you can't adequately document a release's changes, you're not ready to publish that release.

There is still no migration guide covering the major changes from 2.0 to 3.0. See #1875 and #1881

A simple request I made was ignored: If you don't have the time to keep a changelog, could you at least tag commits and pull requests with their semver status?

The Babel minifier is not perfect, but for a lot of code bases it's pretty decent. Consider giving it a try if you are dissatisfied with Uglify and haven't yet chosen an alternative. I, sadly, only use Uglify now on legacy code bases.