This repository was archived by the owner on Aug 11, 2022. It is now read-only.
Repository navigation
This repository was archived by the owner on Aug 11, 2022. It is now read-only.
npm version 6.0.0 published with incorrect modification dates for files of October 26 1985 #20439
Description
I'm opening this issue because:
- npm is crashing.
- npm is producing an incorrect install.
- npm is doing something I don't understand.
- npm is producing incorrect or undesirable behavior.
- Other (see below for feature requests):
What's going wrong?
I noticed that the npm docs show "Last modified October 26, 1985" on some pages. For example here is the footer of the folders doc page:
I was curious why that would be the case and it looks like the v6.0.0 was published with those incorrect modification dates for a number of files:
$ npm install npm@6.0.0
...
$ ls -lah node_modules/npm/doc/files/npm-folders.md
-rw-r--r-- 1 coryforsyth staff 7.6K Oct 26 1985 node_modules/npm/doc/files/npm-folders.mdThere are a number of files at the root of the installed npm package with the incorrect modification date as well. When the docs are built, they use that incorrect modification date. This is reported at the docs site, too: https://github.com/npm/docs/issues/990.
How can the CLI team reproduce the problem?
Install npm@6.0.0, look at last-modification time for the files.
supporting information:
npm -vprints: 5.8.0node -vprints: v8.2.1npm config get registryprints: http://registry.npmjs.org/- Windows, OS X/macOS, or Linux?: macOS
- Network issues:
- Geographic location where npm was run: NYC
- I use a proxy to connect to the npm registry.
- I use a proxy to connect to the web.
- I use a proxy when downloading Git repos.
- I access the npm registry via a VPN
- I don't use a proxy, but have limited or unreliable internet access.
- Container:
- I develop using Vagrant on Windows.
- I develop using Vagrant on OS X or Linux.
- I develop / deploy using Docker.
- I deploy to a PaaS (Triton, Heroku).
Activity
bantic commentedon Apr 25, 2018
I looked a little more closely and discovered that other versions have the same problem. The most recent one that has expected modification timestamps is v5.7.1. All of the versions after that have the incorrect modified-time for their files:
ryan-roemer commentedon Apr 25, 2018
Yep, we hit this on https://unpkg.com/victory-docs@6.6.8/ and unfortunately, our current publish-to-production infrastructure uses dates to determine "what's new".
Looks like introduced in #20027 ?
And in terms of impact for us, our publishing tools pull packages from npm, check dates for "newer files" and then upload them to our ultimate destination (AWS S3 static site). We have a number of files in our repo now indicating the specific back-to-the-future-1985 date instead of their real timestamp, defeating our publishing logic and leading to a broken site. (We can definitely hack around this on our publishing end, but I'd prefer that real date stamps per file be preferred if at all possible from the normal
npm publish-to-npm installworkflow).Thanks!
zkat commentedon Apr 27, 2018
This is intentional. The website needs to be updated to stop using the published tarballs, but as of
npm@6, we're locking tarball dates to a single date. This makes it so tarballs generated off the same code will have consistent shasums, enabling reproducible-builds.orgryan-roemer commentedon Apr 28, 2018
@zkat -- Can you explain the goal a little bit more for reproducible-builds.org? Are you saying you need builds on end user machines (like my laptop) when doing an arbitrary build like say:
that adds non-git-committed files to
distandliband stuff that become part of thenpmpackage as part of annpm publishshould be completely identical across machines and that's why we need the1985date?zkat commentedon Apr 29, 2018
Yes
arvindpdmn commentedon Jun 27, 2018
Noticed the wrong date today. I think it should be fixed. Anyone try to cite NPM docs in their research will end up using the wrong date. They will have to come to GitHub to pick up the correct date.
gscottolson commentedon Jun 27, 2018
Could this be intentional? This is the exact date that appears in Back to the Future.
ryan-roemer commentedon Jun 27, 2018
@gscottolson -- it is intentional by the npm folks as a part of an overall scheme of "deterministic builds". If I understand correctly, they're trying to provide more opportunities for having different builds of the same source at different times end up byte-for-byte the same -- here the part they're working with is nuking all file metadata.
If I'm guessing as to how the npm folks build things, their own website uses https://unpkg.com/npm@6.1.0/doc/cli/npm-pack.md which is published with modern npm which then ends up with https://docs.npmjs.com/cli/pack having:
... so looks like they're dogfooding bleached file metadata same as the rest of us 😉
UPDATE: Yep, npm's docs have an open PR to stop using
npmto consume docs source from the registry, and now have to get it directly fromgitsource. https://github.com/npm/docs/pull/1014/filesSo presumably, the rest of us have to adjust with something analogous if we were previously relying on any file timestamp metadata.
e2tox commentedon Jul 2, 2018
I don't buy this intentional.
tarballs generated off the same code will definitely have different shasums.
Because of the version field of package.json is always different. npm not allow publish same code with same version.
I spend days to investigate production issue before I found here. npm was the most trustworthy component in my build process. I am very sad about this.
UPDATE: The latest npm to publish your package without reset the modify date is npm@5.6.0