Generated zip files always have new timestamps and force stack updates

[troyready]

Every invocation of bestzip generates a zip file with a different sha256 hash because of the contents' timestamps. Similar issue exists for serverless-webpack as well.

When Serverless is creating zips, it avoids this by explicitly setting the files' timestamps to the epoch. Bestzip could copy this for platforms without a zip executable, but it would require a different approach for when it shells out to zip (which doesn't have a flag to override timestamps).

[troyready]

Some solutions that come to mind:

• Switch to a deterministic zip provider
  • serverless-webpack is likely going back to archiver
• Modify the files' timestamps before zipping them
  • Something like the javascript equivalent of find . -exec touch -t 197001010000 {} +

I'm partial to switching to archiver, but curious for your thoughts/preference.

[olup]

Very interesting. I'd second going back to archiver, as I am no fan of bestzip.

However, as this was an improvement for some heavy duty use cases, it might be a good idea to follow the (still unmerged it seems) PR of serverless webpack, and add a nativeZip option to let user opt-in best zip.

[floydspace]

Hey, @olup, I can't remember exactly what benefit we got from migrating to bestzip? are those improvements worth the issues we have currently? I'd also vote for reverting back to archiver.
This week I went through the zip-it-and-ship-it by Netlify, they also are using archiver.

[olup]

The original issue should be here somewhere. Someone argued, with benchmarks, that it made a huge performance difference when zipping many many functions. My concerns with bestzip were low maintenance and no typings.

[github-actions]

🎉 This issue has been resolved in version 1.18.0 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀