Comparing version 0.0.5 to 0.0.6
{ | ||
"name": "rfc6902", | ||
"version": "0.0.5", | ||
"version": "0.0.6", | ||
"description": "Complete implementation of RFC6902 (patch and diff)", | ||
@@ -5,0 +5,0 @@ "keywords": [ |
@@ -5,3 +5,3 @@ # rfc6902 | ||
(including [RFC6901](http://tools.ietf.org/html/rfc6901)), | ||
for creating and consuming "application/json-patch+json" documents. | ||
for creating and consuming `application/json-patch+json` documents. | ||
@@ -11,2 +11,26 @@ No fancy Object.observe, no TypeScript, no missing "diff" function. | ||
## Demo | ||
Simple [web app](http://chbrown.github.io/rfc6902) using the browser-compiled version of the code. | ||
* Currently only demos `diff(input, output)` functionality. | ||
## Determinism | ||
If you've ever implemented Levenshtein's algorithm, | ||
or played tricks with `git stash` to get a reasonable sequence of commits, | ||
you'll realize that computing diffs is rarely deterministic. | ||
(This explains why 2 out of the 94 tests are currently failing.) | ||
Applying `json-patch` documents is way easier than generating them, | ||
which might explain why there are more than five patch-applying RFC6902 implementations in NPM, | ||
but only one (_yours truly_) that attempts to generate patch documents from two distinct objects. | ||
So when comparing _your_ data objects, you'll want to ensure that the patches it generates meet your needs. | ||
Of course, this only applies to generating the patches. | ||
Applying them is deterministic and completely specified by [RFC6902](http://tools.ietf.org/html/rfc6902). | ||
## Installation | ||
@@ -13,0 +37,0 @@ |
License Policy Violation
LicenseThis package is not allowed per your license policy. Review the package's license to ensure compliance.
Found 1 instance in 1 package
License Policy Violation
LicenseThis package is not allowed per your license policy. Review the package's license to ensure compliance.
Found 1 instance in 1 package
78237
60