How not to behave on GitHub issues
github.com
github.com
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.
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.
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.
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.
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.
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.
I think it's pretty clear which side here is acting inappropriately.