Use a specific mtime when packing, rather than none at all

[isaacs]

Thank god I found you. Listen, can you meet me at Twin Pines Mall tonight at 1:15? I've made a major breakthrough, I'll need your assistance.

[zkat]

💯

[zkat]

cc @simonua

[MylesBorins]

when this tarball hits 88... we are going to see some serious 💩

[MylesBorins]

Jokes aside, is there a reason to set a date in the past as opposed to using the original mtime of the file?

If I'm not mistaken older versions would maintain the original mtime, see googleapis/google-p12-pem#27 (comment)

[zkat]

The reason for this is that, by setting mtimes like this, we're able to make it so two computers with two checkouts of the same project at the same commit, barring extra noise in the signal, will both generate tarballs with the exact same hash. It means npm packages can be made compliant with reproducible builds. Obvs, npm isn't the only part of this story, and this also depends on people's own run-scripts modifying things, but at least npm's packer no longer gets in the way of this.

For a while now, we were using the noMtime option because it allowed those stable times, but it turns out there's some implementations that can't handle beginning-of-epoch timestamps (or timestamps before 1980), so this is the compromise.

[MylesBorins]

A++ explanation thanks.

I know that Node is interested in exploring reproducible builds, and timestamps are definitely an issue for this.

[simonua]

Thanks, Doc!