Worth noting that this does constitute a very minor breaking version change because I've changed 2 types in the status API to unify with values exposed by this new API (version and build). The good news is we're now using a proper version type, the one that cabal uses, so if the user needs to do semantic comparisons that is much easier. I was able to drop out some version sniffing code from the test suite to support this.
One small hitch is that I had to just export a plain Object for the node settings value. From what I can tell (and as the comment reads), this data is totally variable, keys will sometimes be there, sometimes not, and some are particular to the plugins installed.
We'll see how well my types hold up to the test suite, I tested on 1.7.
@bitemyapp quick prod on this. I plan on adding the so-similar-why-isn't-it-just-one-api node stats feature and itll probably share types with this PR.
Worth noting that this does constitute a very minor breaking version change because I've changed 2 types in the status API to unify with values exposed by this new API (version and build). The good news is we're now using a proper version type, the one that cabal uses, so if the user needs to do semantic comparisons that is much easier. I was able to drop out some version sniffing code from the test suite to support this.
One small hitch is that I had to just export a plain
Object
for the node settings value. From what I can tell (and as the comment reads), this data is totally variable, keys will sometimes be there, sometimes not, and some are particular to the plugins installed.We'll see how well my types hold up to the test suite, I tested on 1.7.