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:

• 5.8.0-next.0
• 5.8.0
• 6.0.0-next.0
• 5.9.0-next.0
• 5.10.0-next.0
• 6.0.0-next.1
• 6.0.0-next.2
• 6.0.0

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 install workflow).

Thanks!

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.org

@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:

$ webpack

that adds non-git-committed files to dist and lib and stuff that become part of the npm package as part of an npm publish should be completely identical across machines and that's why we need the 1985 date?

Yes

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.

Could this be intentional? This is the exact date that appears in Back to the Future.

@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:

Last modified October 26, 1985

... 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 npm to consume docs source from the registry, and now have to get it directly from git source. https://github.com/npm/docs/pull/1014/files

So presumably, the rest of us have to adjust with something analogous if we were previously relying on any file timestamp metadata.

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