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.
As highlighted in various issues (#24, #30), the library is currently failing at computing correct and reliable diffs for arrays, and more specifically whenever the size of the "left" array is less than the "right" one:
case 1: len(left) < len(right) (bogus diffs)
case 1 (continuation): len(left) < len(right) (unreliable diffs)
case 2: len(left) == len(right) (OK)
case 3: len(left) > len(right) (diffs are OK, but there is a lingering duplicate element at the bottom of the array)
Both issues highlighted in case 1 are the most serious ones, while the one in case 3 is mostly visually confusing.
I believe the cause of these issues are two:
maybe
matrixes here, you are missing the last element of each row/columnWhat I'm proposing here is a simple fix for the (1) and to use
strutil
to calculate the similarity for (2).Changes don't break current test cases:
The code is quite complex, so I may be missing some obvious things, so please let me know if that's the case!
I'm also introducing
go.mod
in the same PR, which is resulting in a giant bulk of changes. The actual code changes are very minimal and all under thegojsondiff.go
file.