Closed Cinedin closed 8 months ago
Hmm. This PR is roughly a duplicate of https://github.com/kpdecker/jsdiff/pull/384. I have the same doubt about it as I do about #384, though: wouldn't it make more sense to update structuredPatch
to include a linedelimiters
property in its output, thus making its return type consistent with parsePatch
, rather than modifying applyPatch
to accommodate the (arbitrary-seemingly, probably accidental?) inconsistency between the two patch formats?
I provisionally plan to fix this by fixing structuredPatch
, and to leave applyPatch
alone (and close both this and #384), but I am interested in hearing out any argument for why modifying applyPatch
would be better!
After looking more closely, I think we should just rip out all the linedelimiters
logic from parsePatch
and always assume, in there and in applyPatch
, that the line delimiter is a \n
. The stuff parsePatch
is doing, letting you have a patch where lines of the patch are delimited by, say, vertical tab characters, is inconsistent with the diff
and patch
Unix tools, seems kinda pointless to me, and breaks jsdiff's ability to correctly parse a unified diff format diff generated using diff -u foo bar
if foo
or bar
contained any of the characters (like vertical tabs) that jsdiff treats as line breaks in the diff but that the diff
and patch
CLI tools just treat as ordinary characters.
I'm gonna merge this, and then put up another PR fixing the linedelimiters
stuff.
Fixes #228
Since a structured patch does not define its line delimiters (#157), this change is needed to prevent an error when the returned value of
structuredPatch
is used inapplyPatch
. The current API does not change: