Repository navigation
fix: the same document always saves to the same bytes - #33
Merged
Merged
Conversation
fflate stamps each ZIP entry with the current time when none is given, so two saves of an unchanged document differed whenever they straddled a two-second boundary of the DOS timestamp. That made idempotent-resave.test.ts fail now and then (CI on main after #32). Every entry now carries a fixed date. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Saving the same document now always produces the same bytes. Until now, the ZIP entries carried the time of saving. That made the output differ between saves and made
idempotent-resave.test.tsfail intermittently.Motivation
CI on
mainfailed after #32.idempotent-resave.test.ts › a single mutation produces exactly one new byte stream then stabilisesfailed on Node 24 and passed on Node 22, on the same commit (run 37884074956).The cause is in
writeZip. It gives fflate nomtime, so fflate stamps each entry withnew Date(). ZIP's DOS timestamps have a 2-second resolution. When two saves of an unchanged document fall on either side of a 2-second boundary, their bytes differ.This affects users too, not only the test: templating pipelines, caches and diff tools rely on re-saving an unchanged document being byte-stable. The test file describes that property.
Changes
writeZipdates every entry 1980-01-01 00:00, the earliest DOS date. TheDateis built from local-time fields, which is what fflate encodes, so the bytes do not depend on the time zone. Word and other readers ignore entry dates.@office-kit/docxpatch.Testing
pnpm test: 1294 passed, 8 skipped.pnpm typecheckpasses.oxlintreports the 2 known warnings.check:tree-shakepasses.unzip -lon a saved file shows01-01-1980 00:00for every entry.Breaking changes
None. The bytes of saved files change (the entry dates), but their contents do not.
Checklist
🤖 Generated with Claude Code