I can see where both sides are coming from, but I think if it's as simple as just uploading a new package with a version bump then the maintainer should just go ahead and do it.
It's not worth it to interrupt the workflow of everyone else just because you want to "stand your ground" and not spend 5 minutes re-uploading a package.
Not surprised the maintainer gave such short shrift. These commenters should provide a clear fix or demonstration that re-publishing will fix the problem, or just use the previous release. There's also nothing stopping them forking the project and publishing their own 2.8.29-foo as uglify-js-bar and getting on with their lives. Being rude to open source maintainers is very unlikely to make them more helpful.
Users repeatedly screaming at a dev of an open source project cannot be said to be behaving appropriately, whether they're correct or not. One engages in polite discourse until it's obvious that the other side will not move, then you either fix the problem yourself or go elsewhere.
Inappropriate: Users being impolite and overly demanding.
Inappropriate: Maintainers (and supporters) insisting that a problem in their publishing process (whether or not they caused it) isn't their problem because the code works.
Both sides had legitimate grievances, and both sides did a poor job of trying to resolve them.
You make a stupid mistake and people politely ask you to fix it. If you dismiss the polite people it's only a matter of time before you run into someone who is not polite.
It also doesn't help if your attitude is that if you think everyone else is being an idiot you don't stop and check if maybe the problem is with yourself.
Yes, but there are actually some positive and negative side-effects of checking in dependencies. See “Should I check the Pods directory into source control?” at https://guides.cocoapods.org/using/using-cocoapods.html for a bit of discussion on the concept.
This whole thing seems to stem from the authors inability to reproduce and understand the problem.
Has anyone submitted a test case demonstrating the problem? I don't see one linked in the comments. It may also help to explain how you deploy and why you do it that way, not everyone does this as their day job so some perspective can be enlightening.
Closing an issue like this that is ostensibly a problem for a lot of people and projects isn't good etiquette. At the same time, Foss authors dont owe us or anyone else anything. The least we can do is help them reproduce the issue when they have trouble doing it themselves. Seems like failures on both sides here to me.
Edit: I also don't want to criticize the author for not pushing a patch they don't understand. I wouldnt merge a patch if I didn't understand the problem it was solving, but I would ask for details and a test case to understand it better instead of closing the ticket.
What are you talking about? It was explained multiple times that the released tarball had broken timestamps.
> I also don't want to criticize the author for not pushing a patch they don't understand.
This issue had absolutely nothing to do with patches. The maintainer published a broken tarball. The users were asking the maintainer to re-publish a non-broken tarball.
>The users were asking the maintainer to re-publish a non-broken tarball.
Yes, with such helpful suggestions as changing to a fresh directory because the original directory was "corrupt". Except that wouldn't have fixed it; the problem was eventually discovered to be a bug in npm on Windows[1], so every single "republished" package would have also been broken.
I understand the maintainers don't want to be held to fix other people's tooling issues but at the same time, when you release something that has invalid meta data in it, why would you ignore that and kick it further down the road while leaving the ticket closed even after acknowledging that it's an issue but low priority?
It certainly doesn't help that both parties are constantly being rude to each other.
This feels like a lot of work being taken for granted. That is why support services exist. You pay a fee and the developer agrees to fix things for you. Open-source doesn't have to be for free.
Took an interesting twist at the end and it turned out to be an npm build tooling problem om windows so republishing it without figuring that out wouldn't have fixed it.
Perfect demonstration of why you don't want to behave so dramatically like eric-tucker did. One bit of new information hits that changes the foundation of your stance and you look like a complete asshole.
To be fair republishing would have been really quick and saw the issue occur again which may have helped diagnose the issue. Unfortunately no one ever states how it was published or what versions / systems were used. node has had multiple different issues with running and doing things properly on Windows over the various releases; if it was stated earlier that Windows was used to publish I think people would have immediately started looking at that (I know I would have; anytime a friend of mine has an issue with node or npm that's the first thing I ask).
I know macOS is a popular system to do node development on but the node folks, at least seem to, forget Windows exists.
Also to be fair, a lot of them looked like complete assholes
The problem that eric-tucker raised, a very valid one, is that the corruption of file metadata in the published release posed a serious stability risk for anyone whose environment depends on uglify-js. At the very least, from the comments still present (i.e. not deleted) on the issue, it seems absurd to me that the maintainers closed the issue without either (1) publishing a workaround or (2) resolving the issue in production. Similarly, though, I find it reprehensible that it took so long for someone to step forward and help trace the issue - or even make an offer to do so.
On a broader note: by now, I think it is a true and established fact that there is no such thing as bug-free software. Bugs exist everywhere, and there is plenty of code out there to defend against the existence of such bugs. It is absolutely and undeniably negligent to say that you won't fix a demonstrable issue in a software release because it triggers known issues in other software, especially when a non-harmful remedy is at hand.
24 comments
[ 6.3 ms ] story [ 63.6 ms ] threadIt's not worth it to interrupt the workflow of everyone else just because you want to "stand your ground" and not spend 5 minutes re-uploading a package.
The first response (from which the whole thread devolves) claims "npm does not allow re-publishing the same version", which just isn't true anymore.
Both sides had legitimate grievances, and both sides did a poor job of trying to resolve them.
It also doesn't help if your attitude is that if you think everyone else is being an idiot you don't stop and check if maybe the problem is with yourself.
Anyone creating a fresh project right now with uglifyjs somewhere down the build chain will face this issue.
The only way to resolve this is by publishing a fresh, correct version to npm ragardless of what caused the issue.
The authors have failed to do this till now and the issue remains closed.
1. https://docs.npmjs.com/cli/shrinkwrap is a good thing. Please consider doing it for all of your projects using NPM.
2. Consider also putting your node_modules under version control.
Has anyone submitted a test case demonstrating the problem? I don't see one linked in the comments. It may also help to explain how you deploy and why you do it that way, not everyone does this as their day job so some perspective can be enlightening.
Closing an issue like this that is ostensibly a problem for a lot of people and projects isn't good etiquette. At the same time, Foss authors dont owe us or anyone else anything. The least we can do is help them reproduce the issue when they have trouble doing it themselves. Seems like failures on both sides here to me.
Edit: I also don't want to criticize the author for not pushing a patch they don't understand. I wouldnt merge a patch if I didn't understand the problem it was solving, but I would ask for details and a test case to understand it better instead of closing the ticket.
It's up to issue reporters to clearly demonstrate an issue, not for authors to try to recreate every rumoured bug.
> I also don't want to criticize the author for not pushing a patch they don't understand.
This issue had absolutely nothing to do with patches. The maintainer published a broken tarball. The users were asking the maintainer to re-publish a non-broken tarball.
Yes, with such helpful suggestions as changing to a fresh directory because the original directory was "corrupt". Except that wouldn't have fixed it; the problem was eventually discovered to be a bug in npm on Windows[1], so every single "republished" package would have also been broken.
[1]https://github.com/npm/npm/issues/16734
I think it's pretty clear which side here is acting inappropriately.
I understand the maintainers don't want to be held to fix other people's tooling issues but at the same time, when you release something that has invalid meta data in it, why would you ignore that and kick it further down the road while leaving the ticket closed even after acknowledging that it's an issue but low priority?
It certainly doesn't help that both parties are constantly being rude to each other.
Perfect demonstration of why you don't want to behave so dramatically like eric-tucker did. One bit of new information hits that changes the foundation of your stance and you look like a complete asshole.
I know macOS is a popular system to do node development on but the node folks, at least seem to, forget Windows exists.
Also to be fair, a lot of them looked like complete assholes
On a broader note: by now, I think it is a true and established fact that there is no such thing as bug-free software. Bugs exist everywhere, and there is plenty of code out there to defend against the existence of such bugs. It is absolutely and undeniably negligent to say that you won't fix a demonstrable issue in a software release because it triggers known issues in other software, especially when a non-harmful remedy is at hand.