npm install of 2.8.28 is downloading files with timestamp of Dec 31, 1969
et304383 opened this issue · comments
[etucker: npm_test]$ ll
total 0
[etucker: npm_test]$ npm install uglify-js@2.8.28
npm WARN saveError ENOENT: no such file or directory, open '/home/etucker/play/npm_test/package.json'
npm notice created a lockfile as package-lock.json. You should commit this file.
npm WARN enoent ENOENT: no such file or directory, open '/home/etucker/play/npm_test/package.json'
npm WARN npm_test No description
npm WARN npm_test No repository field.
npm WARN npm_test No README data
npm WARN npm_test No license field.
+ uglify-js@2.8.28
added 17 packages in 2.86s
[etucker: npm_test]$ ll node_modules/uglify-js/
total 64
drwxrwxr-x 2 etucker etucker 4096 Jun 5 11:57 bin
drwxrwxr-x 2 etucker etucker 4096 Jun 5 11:57 lib
-rw-rw-r-- 1 etucker etucker 1348 Dec 31 1969 LICENSE
-rw-rw-r-- 1 etucker etucker 2086 Jun 5 11:57 package.json
-rw-rw-r-- 1 etucker etucker 41915 Dec 31 1969 README.md
drwxrwxr-x 2 etucker etucker 4096 Jun 5 11:57 tools
This does not happen with 3.x:
[etucker: npm_test]$ rm -rf *
[etucker: npm_test]$ npm install uglify-js
npm WARN saveError ENOENT: no such file or directory, open '/home/etucker/play/npm_test/package.json'
npm notice created a lockfile as package-lock.json. You should commit this file.
npm WARN enoent ENOENT: no such file or directory, open '/home/etucker/play/npm_test/package.json'
npm WARN npm_test No description
npm WARN npm_test No repository field.
npm WARN npm_test No README data
npm WARN npm_test No license field.
+ uglify-js@3.0.15
added 4 packages in 1.417s
[etucker: npm_test]$ ll node_modules/uglify-js/
total 60
drwxrwxr-x 2 etucker etucker 4096 Jun 5 11:57 bin
drwxrwxr-x 2 etucker etucker 4096 Jun 5 11:57 lib
-rw-rw-r-- 1 etucker etucker 1348 Jan 15 06:32 LICENSE
-rw-rw-r-- 1 etucker etucker 1846 Jun 5 11:57 package.json
-rw-rw-r-- 1 etucker etucker 39419 Jun 1 08:33 README.md
drwxrwxr-x 2 etucker etucker 4096 Jun 5 11:57 tools
[etucker: npm_test]$
I'm afraid not much can be done over here - may be try asking npm about this?
One thing I can add is uglify-js 3.0.15 was published with npm that was bundled with node 7.10.0, whereas IIRC uglify-js 2.8.28 was done with node 8.0.0 - so you may add that to your issue report for them.
Pretty sure the issue is on your side. 2.8.27 is fine as well. It's only 2.8.28 that is "corrupted."
Unless the package is unusable, I wouldn't be too bothered by it. And there is no way I can influence the behaviour of npm publish, so your best course of action is to ask them about this.
The package is not usable. I cannot zip up the build folder because zip cannot handle files with a creation date before 1980.
I had to switch to 2.8.27. Can you not just republish 2.8.28 to fix these timestamps?
npm does not allow re-publishing the same version. Why does using uglify-js involves creating a zip file anyway? I'm under the impression that it's npm install uglify-js followed by require("uglify-js") in your code somewhere?
So that I can create a package for deploying the application along with npm dependencies to a test environment.
Edit: can you try pushing a new version, 2.8.29?
And even if I were to publish 2.8.29 which is identical to 2.8.28, what guarantees npm would produce the correct result this time?
As advised above, please contact npm to make sure the issue is diagnosed/resolved first.
I can almost guarantee that if I open a ticket with npm and/or nodejs about a specific npm module on a specific version having corrupted timestamps they're going to point the finger back at this module.
I just downloaded your tgz file DIRECTLY from npm, and it's corrupted IN the tgz file:
[etucker: npm_test]$ npm view uglify-js@2.8.28 | tail -n 10
optionalDependencies: { 'uglify-to-browserify': '~1.0.0' },
browserify: { transform: [ 'uglify-to-browserify' ] },
scripts: { test: 'node test/run-tests.js' },
gitHead: '23876a84a51835ca791afa12931e747df048178f',
dist:
{ integrity: 'sha512-WqKNbmNJKzIdIEQu/U2ytgGBbhCy2PVks94GoetczOAJ/zCgVu2CuO7gguI5KPFGPtUtI1dmPQl6h0D4cPzypA==',
shasum: 'e335032df9bb20dcb918f164589d5af47f38834a',
tarball: 'https://registry.npmjs.org/uglify-js/-/uglify-js-2.8.28.tgz' },
directories: {} }
[etucker: npm_test]$ wget https://registry.npmjs.org/uglify-js/-/uglify-js-2.8.28.tgz
--2017-06-05 13:59:16-- https://registry.npmjs.org/uglify-js/-/uglify-js-2.8.28.tgz
Resolving registry.npmjs.org (registry.npmjs.org)... 151.101.0.162, 151.101.64.162, 151.101.128.162, ...
Connecting to registry.npmjs.org (registry.npmjs.org)|151.101.0.162|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 129468 (126K) [application/octet-stream]
Saving to: ‘uglify-js-2.8.28.tgz’
uglify-js-2.8.28.tgz 100%[==================================================================================>] 126.43K --.-KB/s in 0.07s
2017-06-05 13:59:16 (1.69 MB/s) - ‘uglify-js-2.8.28.tgz’ saved [129468/129468]
[etucker: npm_test]$ tar xf uglify-js-2.8.28.tgz
[etucker: npm_test]$ ll
total 132
drwxrwxr-x 5 etucker etucker 4096 Jun 5 13:59 package
-rw-rw-r-- 1 etucker etucker 129468 Jun 3 10:54 uglify-js-2.8.28.tgz
[etucker: npm_test]$ ll package
total 64
drwxrwxr-x 2 etucker etucker 4096 Jun 5 13:59 bin
drwxrwxr-x 2 etucker etucker 4096 Jun 5 13:59 lib
-rw-rw-r-- 1 etucker etucker 1348 Dec 31 1969 LICENSE
-rw-rw-r-- 1 etucker etucker 1139 Dec 31 1969 package.json
-rw-rw-r-- 1 etucker etucker 41915 Dec 31 1969 README.md
drwxrwxr-x 2 etucker etucker 4096 Jun 5 13:59 tools
[etucker: npm_test]$
Regardless of who is to blame here, you have to resolve this somehow. You have a corrupted tarball on the latest 2.x version available. It's not my responsibility to figure out why your publish corrupted the timestamps on these files.
Why is this issue closed? The package you published to npm has corrupt file metadata. There are developers here at The Atlantic who have lost a whole afternoon of work trying to debug an issue caused by 2.8.28.
@alexlamsl npm publish will package up whatever files you have locally. That would have been where the problem was introduced, in the directory on your filesystem where you did the npm publish. If you were to publish 2.8.29 from a fresh clone of the repository I'm sure there would be no issue with the files.
There are developers here at The Atlantic who have lost a whole afternoon of work trying to debug an issue caused by 2.8.28.
What issue?
$ node_modules/.bin/uglifyjs -V
uglify-js 2.8.28
$ echo 'console.log(1 + 2);' | node_modules/.bin/uglifyjs -c
console.log(3);
2.8.28 still functions correctly regardless of the bad timestamps produced by npm publish with node 8/npm 5.
It caused errors with the filesystem in our dockerized development environment. Of course it still functions as it's supposed to, provided the package can actually be installed.
It caused errors with the filesystem in our dockerized development environment. Of course it still functions as it's supposed to, provided the package can actually be installed.
The next 2.x release can be made with a non-npm@5 version of npm, but the issue you're describing concerns the docker project or is a bug with npm on the docker filesystem.
Same issue here. Our private deployment system reject the tarball.
If I extract the tarball and stat package/README.md for instance, I get an incorrect/strange date :
16777220 33434588 -rw-r--r-- 1 francetv wheel 0 41915 "Jun 6 16:03:41 2017" "Jan 1 01:00:00 1970" "Jun 6 16:03:41 2017" "Jan 1 01:00:00 1970" 4096 88 0 package/README.md
@alexlamsl please stop trying to defer blame here. The issue is with this specific npm package for a specific version. Push a new version so people can move on.
tar tvf uglify-js-2.8.28.tar gives :
-rw-rw-rw- 0 0 0 1139 1 jan 1970 package/package.json
-rw-rw-rw- 0 0 0 41915 1 jan 1970 package/README.md
-rw-rw-rw- 0 0 0 1348 1 jan 1970 package/LICENSE
-rw-rw-rw- 0 0 0 1982 1 jan 1970 package/bin/extract-props.js
-rw-rw-rw- 0 0 0 21426 1 jan 1970 package/bin/uglifyjs
-rw-rw-rw- 0 0 0 11096 1 jan 1970 package/lib/utils.js
...
Should I post a tar issue ?
This is blocking my deployments also...
Any workaround?
@mishagray use 2.8.27 until the module author decides that this isn't a problem with node / npm.
This seems related to npm/npm#10052, which (if resolved) would alleviate your issue.
It's true that npm/npm#10052 would incidentally fix this issue, because it would reset modification times on files, but there is a much simpler fix that would not require waiting for an 18-month-old issue on npm to be fixed. Make a fresh clone of the repository, bump the version, and publish to npm. I am certain that whatever condition caused the initially packaged files to have corrupted metadata will not be reproduced and the problem will be solved. It doesn't matter what version of npm you use to publish because it is not a bug in npm.
This is a bug in the package you pushed to the npm registry, @alexlamsl, plain and simple. Your refusal to acknowledge this or to take even the simplest steps to address it reflects very poorly on you and on this project.
@fdintino This is not a bug in UglifyJS.
Who cares what the cause of the issue is? Fix it first then point fingers after. This attitude of "not my problem" when your package is broken solves nothing.
I'm baffled by your attitude, frankly. An immeasurable amount of time has been put into this project by people in their own spare time, and you expect them to fix your environment for you?
UglifyJS is not broken.
(And to be honest, it is exactly this attitude that drives me away from doing OSS at all)
Fix MY Environment? Wtf are you talking about? It's been demonstrated that the tarball on npm has corrupted timestamp data. How is that MY environment?
I'm baffled by your attitude, frankly.
Then the bafflement is mutual. You have four different people telling you that the file metadata in the 2.8.28 package is causing issues with their environments and deployments. And you have a (likely) easy solution—push a bumped version from a directory other than the corrupted one that published 2.8.28. But you ignore the former and don't seem to care about the latter. It goes without saying that everyone here appreciates the hard work that is poured into this project, otherwise we wouldn't be using it! I maintain several popular open source projects as well, and I appreciate the challenges that come with it. But if a package I published caused issues in multiple peoples environments, and it was in my power to fix it, I would do so!
I think it's safe to assume that the odd modification time of the files in uglify-js is not intentional—it has no functional benefit and it's also plainly incorrect, these files were not modified in 1969. You have multiple people telling you that this causes incompatibilities in various different systems.
I can only speak for myself, but here's a demonstration of how the files are incompatible in our system. To reproduce, you just need to install unison, a tool for performing two-way directory syncing:
mkdir /tmp/{a,b}
cd /tmp/a
npm init -y
npm install --save uglify-js@2.8.28
cd ..
unison a/ b/ -auto -batch -times -prefer newer || echo "EXITED WITH ERROR CODE $?"
Outputs the following:
Contacting server...
Looking for changes
Reconciling changes
new dir ----> node_modules
new file ----> package.json
Propagating updates
UNISON 2.48.4 started propagating changes at 17:48:06.09 on 06 Jun 2017
[BGN] Copying node_modules from /tmp/test/a to /tmp/test/b
Failed: Failed to set modification time of file
/tmp/test/b/.unison.node_modules.08b6882f.unison.tmp/uglify-js/bin/extract-props.js
to 1969-12-31 at 19:00:00 (0.000000): the time was set to 2017-06-06 at 17:48:06
(1496785686.000000) instead
99% 00:00 ETA
Failed [node_modules]: Failed to set modification time of file
/tmp/test/b/.unison.node_modules.08b6882f.unison.tmp/uglify-js/bin/extract-props.js
to 1969-12-31 at 19:00:00 (0.000000): the time was set to 2017-06-06 at 17:48:06
(1496785686.000000) instead
[BGN] Copying package.json from /tmp/test/a to /tmp/test/b
[END] Copying package.json
UNISON 2.48.4 finished propagating changes at 17:48:06.12 on 06 Jun 2017
Saving synchronizer state
Synchronization incomplete at 17:48:06 (1 item transferred, 0 skipped, 1 failed)
failed: node_modules
EXITED WITH ERROR CODE 2
Is it a bug that unison cannot sync files with a ctime and mtime of 0? Yes, perhaps, and I can open a ticket on that project. But judging by the others who have posted on this issue, the file metadata in the npm tgz are causing problems in other systems. And there is an easy way to ensure compatibility with everyone's system—a clean build and publish of a new version. I apologize for my tone earlier in this thread—I'm just frustrated by the refusal to even try to help.
Fix MY Environment? Wtf are you talking about? It's been demonstrated that the tarball on npm has corrupted timestamp data. How is that MY environment?
@eric-tucker: "I cannot zip up the build folder because zip cannot handle files with a creation date before 1980."
Even with the incorrect timestamps, npm install uglify-js@2.8.28 works on every platform I've tried and runs correctly.
The problem with your zip program is out of scope of uglify. It's trivial to write a command to touch the files for your broken zip command.
Is it a bug that unison cannot sync files with a ctime and mtime of 0? Yes, perhaps, and I can open a ticket on that project.
+1
Am I correct in interpreting your response to mean that you will publish a clean build of 2.8.29 to see if that resolves our issues?
@kzc are you seriously suggesting I run npm install directly on my production systems?
Wow.
Am I correct in interpreting your response to mean that you will publish a clean build of 2.8.29 to see if that resolves our issues?
@fdintino The next 2.x release will be made in due course likely with something other than npm@5. The +1 was for your making a unison bug report.
are you seriously suggesting I run npm install directly on my production systems?
@eric-tucker Please read the last sentence in #2054 (comment)
This is absurd. This is no different than someone reporting a bug and you saying "it's trivial to write a patch to apply against the code."
The issue is not with zip. I can't even process the level of arrogance in the statement "your broken zip command". As if zip and every other tool out there is to blame for not handling epoch 0.
Seriously, does it cost money to publish a new version to npm? Why is this conversation still going on when multiple people have complained?
You're essentially saying your time (to publish a fixed package) is worth more than the time of everyone who is going to encounter this issue, spend countless combined hours debugging, find this issue, then fix their build processes to do a touch command?
How much wasted developer and operations hours will it take for you to say "I guess we should fix the issue on our end"?
We're also experiencing this issue and it's frustrating. uglify-js is being used way down our dependency tree so no easy way for us to force this to the previous version. Implementing a horrible hack to change the dates on the files after npm install doesn't seem viable.
@fdintino Why did you delete your comment slagging @rvanvelzen?
It is exactly that attitude that drives people away from contributing to OSS.
Uglify is as good as it is because of the efforts of volunteers like @rvanvelzen and @alexlamsl.
Another reason to look at alternatives like rollup.
Please do. Share your sunshine with other projects.
I deleted the comment because I thought better of it. It was mean-spirited and singled out a specific developer for no good reason. I had let my frustration get the better of me and for that I apologize.
I also see that uglify-js has had a huge increase in new and useful features lately, largely thanks to the developers in this thread. I hadn't intended to belittle that work over what is a relatively minor issue, but despite myself I did. Sorry.
Hello, please could you release a fix. This issue is by any measure a fault with the uglify-js NPM package. It's causing an unknown number of wasted hours throughout the NPM ecosystem and is breaking the deployment of many live systems. We don't use Uglify explicitly; our dependency is due to Webpack. Many thanks for your work.
Wow. Look at all the related issues, ALL being caused by this broken npm package.
But no, please tell the rest of the world to deal with it because it's not a problem with uglify-js.
@kzc @alexlamsl @rvanvelzen is there anything we can help out with? We understand you all are under constant pressure and we are happy to lend a hand.
CC @isaacs is there anything npm related that would cause this issue.
@TheLarkInn thanks for the offer. My plan is to try and reproduce this in the first place, so I can figure out what to do next.
Having said that, this is not on top of my list right now, and eventually when the next backport comes along before any definite conclusions, I'd just use Node.js Carbon for npm publish 🤞
🤞🤞 understandable let us know if there's anything we can do to help. If there's busy work or higher priority stuff we can help free up for you to prioritize we are happy to do so. Good luck!
Not at the top of your list? Look how many projects are affected by this! Consider how many are affected that have not complained.
What on earth are you doing that's higher priority that this issue breaking potentially thousands of builds across the planet?
It would take two minutes to publish a new version. This is mind boggling.
@alexlamsl could you at least re-open the issue? Having the issue closed is potentially confusing for people who are searching google or github for this problem. It would also help avoid more people opening duplicate tickets.
So we're just not going to fix this huh? We're going to leave the entire world broken and having to implement work-arounds in their build process?
@eric-tucker Still trying to hack in a workaround into ours this morning :/
@felipekm thanks for that. I pointed out in this thread that Uglify-JS must be locked at 2.8.27 until the maintainers decide to fix this extremely wide spread issue that apparently isn't top priority.
@alexlamsl at least reopen this issue. It should not be closed. It's a real issue affecting many projects.
This is causing an issue for us with CircleCI & CodeDeploy. https://discuss.circleci.com/t/zip-does-not-support-timestamps-before-1980/13110/8
Also, reading this issue puts uglifyJS in a really bad light...
why is this issue closed? been trying to figure out what has been going wrong with my app all day, just now finding this, @alexlamsl can you please reopen?
I'll grant, for the sake of argument, that the broken behavior re: epoch 0 in zip, unison, and other tools is a bug.
That means it's a really common bug, in really ubiquitous utilities. In much the same way that it's risky to put unicode characters in filenames for projects that will be deployed on many different filesystems (filesystems without good normalization may choke, causing problems), it's a very risky choice to install highly unusual date metadata on files in this repository. Past a certain point, when enough of the universe of deployment targets shares a defective behavior, it's time to start thinking about working around that behavior--even if it is technically "working around someone else's bug".
Where I think this went off the rails is with the conflict over the refusal to release an update. To be very clear: there is incorrect and likely to surface very common bugs data that was uploaded to NPM. This is not a problem introduced by NPM any more than an SQL injection attack is introduced by a web form: NPM is vulnerable to problematic use; not responsible for the problem data.
Regardless of whether NPM should, can, or will eventually correct such errors, that is obviously not happening for a lot of users.
Given that sometimes it is necessary to work around others' defective behavior, and given how simple the workaround is, I think that it's a very good idea to release a bumped version with correct file metadata.
I'd say kudos to the UglifyJS contributors for standing firm and not re-opening this issue even in the face of what I would have found overwhelming pressure. Finding all these other bugs in other software can only improve things for everyone in the long run, and this really helped smoke out a lot of problems!
This is just a sad state if affairs. Please push a new release or at least reopen the issue.
Folks can also vote with their feet: https://github.com/google/closure-compiler
@pink-mist I can't tell if you're being serious or sarcastic.
If you're being serious please leave. Files aren't supposed to have time stamps prior to or equal to epoch's creation. Tools shouldn't have to deal with this.
I can't tell if you're being serious or sarcastic.
While I do find the situation humorous, I was being perfectly serious. This whole issue isn't something to get so worked up over though, this software works completely fine.
Files aren't supposed to have time stamps prior to or equal to epoch's creation.
Why not? Being able to have whatever timestamp you can on your files shouldn't be dictated by some buggy software.
Tools shouldn't have to deal with this.
Do you really think this is the first and last time this issue will ever arise? If tools can't deal with it, they should definitely be fixed.
Everybody complaining here should read the LICENSE file.
If you decide to make something that becomes a crucial dependency of many things, and then push a broken version, you don't get to fairly claim "no warranty" and absolve yourself of all responsibility.
@eric-tucker: To quote the license:
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDER “AS IS” AND ANY
EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
PURPOSE ARE DISCLAIMED.
Great. So every issue on every open source project should be dealt with by quoting the license and saying "when we feel like it."
That's exactly the point of giving your project a license - to make clear you have this option.
That's exactly the point of giving your project a license - to make clear you have this option.
I think the point of a license is for legal protection. However we don't have to like what is happening here.
UglifyJS is not broken.
While this isn't exactly a "program breaking bug", it is still an issue. If this wasn't affecting anyone, we could mark it as a weird accident and go on with our lives, but this is directly affecting people and their software. Yes, you are not legally obligated to fix it, but you must agree that "I don't have to" is a bullshit reason for not helping someone in need. Taking a couple minutes out of your day to deal with a quirk that could possibly be detrimental to someone and their software would be a nice thing to do. Obviously this code isn't flying spaceships to Mars, but if it's fucking up @eric-tucker's code then that's one person who is relying on your software, and one person you can help.
I'm not trying to sound like an asshole, but it's difficult to sound nice when I'm criticizing you for not being nice. If there's nothing you can do, there's nothing you can do. Whipping out your license as an excuse to not help someone is just plain awful.
I think this comment on Reddit sums this up rather nicely:
asdfasdafas 16 points 3 hours ago
Uglify devs sound like major assholes. In the time it took to post their rants they could have fixed it and saved everyone time.
To help narrow down the issue, I have put together a reproducable case in another issue, but am moving the details here as it was closed:
v2.8.28's .tgz contains corrupt timestamps, causing errors from zip command and others:
Bug report or feature request?
Bug report
Uglify version (uglifyjs -V)
$ ./node_modules/.bin/uglifyjs -V
uglify-js 2.8.28
Steps to reproduce
$ npm init -y
$ npm install uglify-js@2.8.28
$ ls node_modules/uglify-js
total 104
-rw-r--r-- 1 jess.telford staff 1.3K 1 Jan 1970 LICENSE
-rw-r--r-- 1 jess.telford staff 41K 1 Jan 1970 README.md
...
Notice the Jan 1st, 1970 timestamp.
This is causing issues on certain platforms where the timestamp is actually reported as December 31st, 1969, causing POSIX tools to fail. (ie; it's a -1 unix timestamp).
Edit: The actual error is: ZIP does not support timestamps before 1980 on Ubuntu 14.04 (our build machine)
Analysis
It looks like it's the actual files inside the package, which implies it's not anything to do with npm, but instead to do with the state of the filesystem at the time of publish (I've accidentally caused bad publishes like this myself in the past):
$ curl https://registry.npmjs.org/uglify-js/-/uglify-js-2.8.28.tgz | tar -tvf -
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0-rw-rw-rw- 0 0 0 1139 1 Jan 1970 package/package.json
-rw-rw-rw- 0 0 0 41915 1 Jan 1970 package/README.md
-rw-rw-rw- 0 0 0 1348 1 Jan 1970 package/LICENSE
-rw-rw-rw- 0 0 0 1982 1 Jan 1970 package/bin/extract-props.js
-rw-rw-rw- 0 0 0 21426 1 Jan 1970 package/bin/uglifyjs
-rw-rw-rw- 0 0 0 11096 1 Jan 1970 package/lib/utils.js
-rw-rw-rw- 0 0 0 6938 1 Jan 1970 package/lib/transform.js
-rw-rw-rw- 0 0 0 3644 1 Jan 1970 package/lib/sourcemap.js
-rw-rw-rw- 0 0 0 23483 1 Jan 1970 package/lib/scope.js
-rw-rw-rw- 0 0 0 8895 1 Jan 1970 package/lib/propmangle.js
-rw-rw-rw- 0 0 0 57351 1 Jan 1970 package/lib/parse.js
-rw-rw-rw- 0 0 0 47999 1 Jan 1970 package/lib/output.js
-rw-rw-rw- 0 0 0 22265 1 Jan 1970 package/lib/mozilla-ast.js
-rw-rw-rw- 0 0 0 179487 1 Jan 1970 package/lib/compress.js
-rw-rw-rw- 0 0 0 34888 1 Jan 1970 package/lib/ast.js
-rw-rw-rw- 0 0 0 10194 1 Jan 1970 package/tools/node.js
-rw-rw-rw- 0 0 0 688 1 Jan 1970 package/tools/exports.js
100 126k 100 126k 0 0 232k 0 --:--:-- --:--:-- --:--:-- 232k
-rw-rw-rw- 0 0 0 1640 1 Jan 1970 package/tools/props.html
Note that this is not a problem in 2.8.27:
$ curl https://registry.npmjs.org/uglify-js/-/uglify-js-2.8.27.tgz | tar -tvf -
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0-rw-rw-rw- 0 0 0 1139 19 May 19:53 package/package.json
-rw-rw-rw- 0 0 0 41915 19 May 19:53 package/README.md
-rw-rw-rw- 0 0 0 1348 15 Jan 21:32 package/LICENSE
-rw-rw-rw- 0 0 0 1982 19 May 19:53 package/bin/extract-props.js
-rw-rw-rw- 0 0 0 21426 19 May 19:53 package/bin/uglifyjs
-rw-rw-rw- 0 0 0 34888 19 May 19:53 package/lib/ast.js
-rw-rw-rw- 0 0 0 179487 19 May 19:53 package/lib/compress.js
-rw-rw-rw- 0 0 0 22265 19 May 19:53 package/lib/mozilla-ast.js
-rw-rw-rw- 0 0 0 47845 19 May 19:53 package/lib/output.js
-rw-rw-rw- 0 0 0 57351 19 May 19:53 package/lib/parse.js
-rw-rw-rw- 0 0 0 8895 19 May 19:53 package/lib/propmangle.js
-rw-rw-rw- 0 0 0 23483 19 May 19:53 package/lib/scope.js
-rw-rw-rw- 0 0 0 3644 22 Mar 22:18 package/lib/sourcemap.js
100 127k 100 127k 0 0 132k 0 --:--:-- --:--:-- --:--:-- 132k
-rw-rw-rw- 0 0 0 11096 19 May 19:53 package/lib/utils.js
-rw-rw-rw- 0 0 0 688 19 May 19:53 package/tools/exports.js
-rw-rw-rw- 0 0 0 10194 19 May 19:53 package/tools/node.js
-rw-rw-rw- 0 0 0 142838 19 May 19:53 package/tools/domprops.json
-rw-rw-rw- 0 0 0 1640 15 Jan 21:32 package/tools/props.html
Edit: Related to #2054
Edit 2: here's an incomplete list of other issues that appear to have a root cause as outlined above:
- aws/aws-cli#2639
- https://discuss.circleci.com/t/zip-does-not-support-timestamps-before-1980/13110
- Shippable/support#3634
- aws/aws-cli#2646
- webpack/webpack#5022
@alexlamsl @kzc Is there anything else I can do to help? I understand your time is valuable, so I might be able to help debug some more if required?
If you're using Babel, you can try switching to using Babili minifier:
https://github.com/babel/babili
since it's clear this issue isn't going anywhere.
I highly recommend it, there's even a webpack plugin!
A thread so frustrating it made it to Hacker News.
i have the same issue that cost me a serious amount of time because this package is way down our dependency chain in the build process. please publish a fix or at least reopen the issue so people can find and help each other! This issue being closed was a hurdle by itself. We currently cannot release new builds doe to this problem.
(in response to a deleted comment)
Forking doesn't solve all your problems. A friend recommended butternut, which claims to run 3 times faster than UglifyJS.
And you know you've got a problem when a Pythoner is having problems with your JavaScript package. That "dependency chain" must be large...
If you don't provide even this tiny amount of effort to support your users then I hope you don't tout this project as a reason people should hire you. Supporting users, in some sense, is at least some small part of nearly every engineers job, and given how vanishingly small the effort required on your part to fix this problem is, your obstinate refusal to lift a finger really reflects badly on your ability and willingness to cooperate.
For anyone in need of a workaround, I was able to avoid this issue by installing uglifyJS 2.8.27 as an exact version (no ~ or ^) at the top level of our dependency tree and shrinkwrapping, even though it is not used directly in our top level repo.
Then, the sub dependencies that actually require uglify were able to use the version I had installed (2.2.27) and did not attempt to install the latest (2.2.28) which causes problems in CircleCI. I'm unsure how exactly NPM determines whether it's ok to reuse an existing version for sub dependencies or install the latest available, but this worked for us. It may not work with Yarn though, untested.
It's a hack, but the author looks like they're just not going to fix this and we could not wait.
And you know you've got a problem when a Pythoner is having problems with your JavaScript package. That "dependency chain" must be large...
I looked at a recent rails project, gem included: uglifier - A ruby wrapper for UglifyJS. Luckily that project depends on an earlier version of this package but it shows how long those dependency chains can be.
A bystander watching the whole conversation. Why not workaround the mtimes in a Dockerfile and move on? Not sure demanding a fix from an open-source developer is the way to go, despite the original reply or what reddit told you to do.
stat -f %c package.json | xargs -I{} date -j -f %s {} +%y%m%d%H%M | xargs -I[] find . -type f -exec touch -am [] {} \;
As a consumer and maintainer of opensource software (https://github.com/i18next/i18next) i can understand both sides. Both sides work equal hard to get their work done. Both sides are equal right and wrong. Personally i would just go the way and bump the version and put that patch out even knowing that i patch the issues of other tools out there. Reason...i could do it. Putting an end to this - while i can't solve the issues in the other projects. Just take a step back. Breath. Get over it. All people would be thankful.
Publishing a new patch version that solves this issue for everyone out there would take such little time.
Republishing wouldn't have helped, because they'd be using the same set of broken tools and would just upload another dodgy tarball for you all to have mtime issues with.
But behold.
Now that @gabor has put some actual effort in (instead of choosing the popular alternative of crying his eyes out in this thread) the UglifyJS2 developers know what the actual problem is and can avoid using that version of npm on Windows the next time they release a version.
In the meantime, just touch all your files.
Ah, I owe the UglifyJS2 developers an apology then, if this was in fact the cause of the problem. Windows strikes again, I guess.
That makes things a little different, if the corruption is indeed unavoidable on windows using that version of the tool, they would only be able to fix it by switching OSes.
At the very least most of this thread (including infamy on other sites) could have been avoided (or at least reduced) if the issue hadn't been closed despite numerous confirmations.
That contributed to the frustration more so than anything IMO. I started out quite civil and only became frustrated / hostile when the author(s) refused to give gravity to the situation that I knew was breaking builds across the planet.
Regardless of whether who's right or wrong, or what the actual problem is, what's the technical debt in pushing a release even if it is just pushing the same tag with a new version? It's already been QA'd I'd assume and the only change would be the updated file metadata. This project seems to release regularly anyway (I'm not a web developer but this issue has gotten a lot of attention), so why not just bite the bullet?
I will offer my apology regarding assuming this wasn't an npm issue and for any hostility shown previously.
However, I stand by my affirmation that this should have been handled more professionally (by everyone), including keeping the issue open while people tracked down the root cause.
Edit: side note - I wouldn't have been able to create any kind of helpful issue on npm as I have no idea what the author's build environment and/or npm/node versions were/are at the time of publish. The author should have created the ticket with npm saying "this is my environment and this is what happened."
My two cents here:
It's important for maintainers of open-source projects to accept bugs as valid, even if they are not directly caused by their own code. Given that the maintainers are the only people who are intimately familiar with the codebase and all of its dependencies, they are also the only people who are in a good position to report bugs upstream and track them, essentially acting as a middleman towards their users.
This is also why issues should only be closed if there's clear evidence that they're invalid, not just "looks like not our problem". If there's doubt about whether it's user error or a bug in the maintainer's stack, then it's the job of the maintainer to ask the right questions to assess that (and prepare issue templates, and so on). The user can't know what information you need, until you ask.
Put more succinctly: the user doesn't care whether it's the fault of the maintainer or not. They also shouldn't need to care, for open-source software to be sustainable and competitive in the long run.
That having been said, there's a big difference between informing a maintainer that it's their job to handle bug reports, and personally accusing them of being responsible for your woes. Especially when you're a developer (read: a professional), you're expected to have the infrastructure in place to deal with upstream issues when they inevitably occur.
While it is the maintainer's responsibility to pick up the bug and trace where it originates from, they are not responsible for your loss of work time, unless you have a support contract with an SLA.
In the end, nothing is accomplished by pointing blame back and forth. Let's just each take our part of the responsibility - maintainers are responsible for tracking down bugs and getting them fixed regardless of where in the stack they occur, and developers ("users") are responsible for having their own contingency plans when things do eventually break, despite best efforts of all parties.
@joepie91 all excellent points. I would add though that, while I can only speak for myself, my expectation isn't that the uglifyjs maintainers should fix this for me. Yes it cost me some time to troubleshoot and then fix myself, but I committed a fix to our codebase shortly after my first comment in this issue thread. I agree with you that this is my responsibility. What concerns me are the countless people who have run into this issue but haven't spoken up, or who are yet to encounter it. Particularly now that the problem has been identified and the solution is clear (push out a bumped version with either node 6.x or 8.1.0), it still bothers me that there is no will to fix this before the next backport release.
Very good points @joepie91 .
I would agree with @fdintino that waiting until the next backport release to address this problem is definitely downplaying the severity of this issue. It's almost always brought in as a transitive dependency so for someone starting a new project who hasn't yet encountered this issue they are most certainly going to encounter this bug. This will continue to consume a lot of development hours across many companies until 2.8.29+ is released.
I agree with using open source is always "at your risk" but this is an incredibly important issue that still remains closed when it's been confirmed to be an issue with the author's publish environment (even if not caused by the author).
Closed means non-issue, can't reproduce, or some other status of "not something we can or will address." This issue falls under none of those categories.
Just to recap and to get a more clear vision of how we can proceed. The issue will not be fixed, although the problem is identified. At least until the next backport release? Is there any vague time frame when this happens? I am asking because we have no easy way to fix the current corrupted package by ourself in our current build chain. Any of the current workarounds flying around here are not really applicable in the way our build process works currently. So the only way to get our system running again is removing dependencies that pulled in UglifyJS2 and try to write the functionality ourself? I would be glad to get a statement about this so we can make an informed decision and work out a solution plan and start taking action to get our system back to life.
@pythoneer if you npm install --save uglify-js@2.8.27 and you are using npm >= 3.x then it will satisfy all intermediate dependencies that have 'uglify-js': '~2.8.x' or 'uglify-js': '^2.8.x' in their package.json. And as a proactive measure you can use npm shrinkwrap or yarn to recursively freeze all dependencies, to guard against future backwards-breaking changes in other packages.
When there's a complaint about a specific package version like this, please consider either using one of the many npm API tools to directly download the package and verify it, or using npm pack to verify the packaging behavior yourself. Either would have let you confirm the issue relatively quickly and could have prevented a lot of this chatter. Closing it and leaving it closed was not appropriate, as the issue still exists in a published package version that you've left as the latest in that version range. Even if the root of the problem is upstream, that doesn't resolve the current problem users have with the published version.
One thing I can add is uglify-js 3.0.15 was published with npm that was bundled with node 7.10.0, whereas IIRC uglify-js 2.8.28 was done with node 8.0.0 - so you may add that to your issue report for them.
I understand that the root cause of this issue wasn't in uglify-js. But the tools you use when you build packages is still your responsibility. If you're using a tool (or a version of that tool) that produces incorrect output, the expectation is that you recall the release and/or you downgrade your tools until that issue is fixed - not that you leave everyone in limbo until upstream figures out what your problem is and fixes it for you. If you're going to wait on upstream, unpublishing or retagging the offending build should be a strong suggestion. Just letting people sit with broken builds isn't your only option. And it shouldn't be an option at all. Especially on a maintenance branch like this.
Many developers (myself included) like to use the latest versions of their tools and software, and that's understandable. But sometimes this can introduce bugs. I'd like to suggest that you set up a free account with https://travis-ci.org/. You can do automated builds on there and set it up to publish directly from there, so the setup on your local machine won't matter at that point. If your personal setup is going to change frequently, it makes sense to use a more static configuration that's not as fragile.
Good luck in dealing with the remaining pieces of the issue.
Obligatory XKCD:
Is it a matter of pride that the issue is still closed? I've already implemented fixes in our build processes and told the company wide to lock any new package.json entries to version 2.8.27. That doesn't mean that a new point release shouldn't be published immediately.
Yes, it is a small inconvenience in terms of individual persons or projects, but you should consider the collective time spent across all people dealing with this issue, including the numerous other projects having reported issues that lead back to this issue (that leads back to the fixed npm issue).
@alexlamsl please, at least reopen this issue, and mark it fixed when you have time to update node/npm and republish. This is going to continue to break builds until a fix is implemented. Put at least a little consideration into the time of all the people who will ultimately see this issue pop up.
@eric-tucker I'm glad that you were able to fix your build process, but I don't think it's a productive use of your time to continue repeating your opinions here. I'm pretty certain you've made your beliefs crystal clear. I think that everyone on both sides of this have had ample opportunity to express their opinions, and many valid points were made from both sides. At this point, the only logical thing to do is to sit back and see what the maintainers do. I do not believe that continuing to berate them will offer much incentive for them to grant your wishes.
And always remember people:
If people had put as much effort into being helpful as into writing meme comments, this would have been fixed a week ago.
I never actually had this problem, but the response of the maintainers and community is making me think that I am unsafe to depend on this tool.
Time to move to Clojure Compiler, this debacle is embarrassing.
@schwitzerm A fixed release was pushed out to npm, 2.8.29. I really appreciate it @alexlamsl. I don't benefit from it personally, but I'm glad this won't cause issues going forward for fellow developers. You have gotten a lot of grief (some, admittedly, from me). And you aren't likely to be thanked by any of the people who would have been frustrated by the node bug that crept into the 2.8.28 build but now will not, because people only notice when things break. The same goes for all of the other bug fixes you continue to push out for the 2.x backport branch and the features being added to 3.x. I would imagine, particularly after this episode, that this can sometimes be a thankless job. So I'd like to personally express my gratitude for your work.
@alexlamsl this is honestly the most brutal silent treatment from a maintainer of a popular repo I've seen till now.
With the amount of pisspoor attitude from most people in this thread, can you blame them? Also, this was never a problem caused by this project, it was always third party tools that couldn't handle timestamps properly, and the only reason it was found out was because of a bug in yet another tool. None of this was caused because of UglifyJS.
However, they already have released a fixed version. https://github.com/mishoo/UglifyJS2/releases/tag/v2.8.29
So why are you still harping on on this obsolete and outdated issue that doesn't mean anything to anyone anymore?