Rewrite the json-patch CLI tool to be more robust

[JeffFaer]

• It can now generate RFC7396 merge patches with the diff command
• It can now apply RFC7396 merge patches in addition to RFC6902 patches with the patch command.

I did some light manual testing (see below). The only particularly
things to note:

• The error messages could maybe be a little better (for instance
  "cannot unmarshal object into Go value of type jsonpatch.Patch" could
  mention that the user might want to tweak the --patch-format flag
  somehow)
• RFC6902 patches can be applied with RFC7396 logic. I'm not sure if
  this is intended or not, but it mildly surprised me.

$ cat foo.json
{
    "foo": [1, 2, 3],
    "baz": 1,
    "obj": {
        "1": null,
        "2": 4,
        "3": "foo"
    }
}
$ cat bar.json
{
    "foo": [1, 2, 4, 5],
    "baz": 1,
    "obj": {
        "1": null,
        "2": 3
    }
}
$ json-patch diff foo.json bar.json
{"foo":[1,2,4,5],"obj":{"2":3,"3":null}}
$ json-patch patch -p <(json-patch diff foo.json bar.json) <<< '{"obj": {"1": 2, "3": 99}}'
Error: could not decode patch #0: json: cannot unmarshal object into Go value of type jsonpatch.Patch
$ json-patch patch -p <(json-patch diff foo.json bar.json) -f RFC7396
<<< '{"obj": {"1": 2, "3": 99}}'
{"foo":[1,2,4,5],"obj":{"1":2,"2":3}}

$ cat orig.json
{
    "name": "John",
    "age": 24,
    "height": 3.21
}
$ cat patch.json
[
    {"op": "replace", "path": "/name", "value": "Jane"},
    {"op": "remove", "path": "/height"}
]
$ json-patch patch -p patch.json orig.json
{"age":24,"name":"Jane"}
$ json-patch patch -p patch.json orig.json -f RFC7396
[{"op":"replace","path":"/name","value":"Jane"},{"op":"remove","path":"/height"}]

[evanphx]

Hi @JeffreyFalgout,

So my big concern is that this changes how the tool can be used, so any existing users will have errors thrown. Since you have a bunch of new functionality, perhaps it should split out to it's own repo entirely?

[JeffFaer]

Yeah, this patch as it is isn't reverse compatible :/

My big hesitation with splitting this into a separate repository is that now we'd have two competing tools doing the same thing. What if I updated my changes so that it was reverse compatible? i.e. invoking json-patch without create or apply would do the same thing that the tool does today

Then we can have these improvements to the CLI, without breaking pre-existing uses of the tool. We could maybe even add a deprecation warning encouraging users to use the new apply sub-command

[JeffFaer]

Oops, looks like I forgot to comment after my most recent changes: I made the command reverse compatible. You should be able to call the existing tool and the new tool the same way. The new tool has the additional functionality I mentioned at the top

[JeffFaer]

Although I'm not sure if I touched the right files. Should I have updated the v5/ files instead?
#150 (comment)

[JeffFaer]

Updated the PR to touch both 🤷

[evanphx]

Hi @JeffreyFalgout, I think we should probably just delete the v5/cmd directory entirely now that cmd is it's own go module. I highly doubt anyone was using that, and they can easily just switch to the non-v5 prefix.

After that, it looks good!

[JeffFaer]

Done! That should also end up fixing #150 since I changed the cmd/ directory to use the v5/ version of json-patch now, as well.

[evanphx]

One last thing, in the past the presence of go.mod in the top-level dir made Go versions confused. I don't recall the exact reason, but since we're not using them anymore (since the cmd's go.mod pulls in v5) let's go ahead and just delete them.

[JeffFaer]

Sure. I removed those files. I'm curious what problems you ran into, though

[JeffFaer]

Friendly ping :)

[evanphx]

Hi @JeffreyFalgout,

I'm sorry about the extremely long delay here. I've decided your code is best as it's own package. I'm strongly considering deleting the existing cmd/ entirely, so consider it fully unmaintained (the rest of the package is fully maintained).