Sourced from diff's changelog.
9.0.0
(All changes part of PR #672.)
ES5 support is dropped.
parsePatchnow usesTextDecoderandUint8Array, which are not available in ES5, and TypeScript is now compiled with the "es6"target. From now on, I intend to freely use any features that are deemed "Widely available" by Baseline. Users who need ES5 support should stick to version 8.C-style quoted strings in filename headers are now properly supported.
When the name of either the old or new file in a patch contains "special characters", both GNU
diffand Git quote the filename in the patch's headers and escape special characters using the same escape sequences that are used in string literals in C, including octal escapes for all non-ASCII characters. Previously, jsdiff had very little support for this;parsePatchwould remove the quotes, and unescape any escaped backslashes, but would not unescape other escape sequences.formatPatch, meanwhile, did not quote or escape special characters at all.Now,
parsePatchparses all the possible escape sequences that GNU diff (or Git) ever output, andformatPatchquotes and escapes filenames containing special characters in the same way GNU diff does.
formatPatchnow omits file headers whenoldFileNameornewFileNamein the provided patch object areundefined, regardless of theheaderOptionsparameter. (Previously, it would treat the absence ofoldFileNameornewFileNameas indicating the filename was the word "undefined" and emit headers--- undefined/+++ undefined.)
formatPatchno longer outputs trailing tab characters at the end of---/+++headers.Previously, if
formatPatchwas passed a patch object to serialize that had empty strings for theoldHeaderornewHeaderproperty, it would include a trailing tab character after the filename in the---and/or+++file header. Now, this scenario is treated the same as whenoldHeader/newHeaderisundefined- i.e. the trailing tab is omitted.
formatPatchno longer mutates its input when serializing a patch containing a hunk where either the old or new content contained zero lines. (Such a hunk occurs only when the hunk has no context lines and represents a pure insertion or pure deletion, which for instance will occur whenever one of the two files being diffed is completely empty.) PreviouslyformatPatchwould provide the correct output but also mutate theoldLinesornewLinesproperty on the hunk, changing the meaning of the underlying patch.Git-style patches are now supported by
parsePatch,formatPatch, andreversePatch.Patches output by
git diffcan include some features that are unlike those output by GNUdiff, and therefore not handled by an ordinary unified diff format parser. An ordinary diff simply describes the differences between the content of two files, but Git diffs can also indicate, via "extended headers", the creation or deletion of (potentially empty) files, indicate that a file was renamed, and contain information about file mode changes. Furthermore, when these changes appear in a diff in the absence of a content change (e.g. when an empty file is created, or a file is renamed without content changes), the patch will contain no associated---/+++file headers nor any hunks.jsdiff previously did not support parsing Git's extended headers, nor hunkless patches. Now
parsePatchparses some of the extended headers, parses hunkless Git patches, and can determine filenames (e.g. from the extended headers) when parsing a patch that includes no---or+++file headers. The additional information conveyed by the extended headers we support is recorded on new fields on the result object returned byparsePatch. SeeisGitand subsequent properties in the docs in the README.md file.
formatPatchnow outputs extended headers based on these new Git-specific properties, andreversePatchrespects them as far as possible (with one unavoidable caveat noted in the README.md file).Unpaired file headers now cause
parsePatchto throw.It remains acceptable to have a patch with no file headers whatsoever (e.g. one that begins with a
@@hunk header on the very first line), but a patch with only a---header or only a+++header is now considered an error.
parsePatchis now more tolerant of "trailing garbage"That is: after a patch, or between files/indexes in a patch, it is now acceptable to have arbitrary lines of "garbage" (so long as they unambiguously have no syntactic meaning - e.g. trailing garbage that leads with a
+,-, orand thus is interpretable as part of a hunk still triggers a throw).This means we no longer reject patches output by tools that include extra data in "garbage" lines not understood by generic unified diff parsers. (For example, SVN patches can include "Property changes on:" lines that generic unified diff parsers should discard as garbage; jsdiff previously threw errors when encountering them.)
This change brings jsdiff's behaviour more in line with GNU
patch, which is highly permissive of "garbage".The
oldFileNameandnewFileNamefields ofStructuredPatchare now typed asstring | undefinedinstead ofstring. This type change reflects the (pre-existing) reality thatparsePatchcan produce patches without filenames (e.g. when parsing a patch that simply contains hunks with no file headers).