Generic testing framework and Error messages refactor - #32
Conversation
| [Buffer.alloc(3), /^TypeError: Expected Array, got Buffer/], | ||
| [['foo', 'bar', 'baz'], /^TypeError: Expected Array(Length: 2), got Array(Length: 3)/], | ||
| [['foo'], /^TypeError: Expected Array(Length: 2), got Array(Length: 1)/], | ||
| [undefined, /^TypeError: Expected Array, got undefined/] |
There was a problem hiding this comment.
@fanatid this PR is still WIP, so any real attention to be paid is that you are OK with these error messages... they use the typeforce format, and I was most likely just going to use it verbatim.
The typeforce module has been extensively tested to be consistent with these error types, and maintains high performance while balancing highly descriptive error messages for debugging.
|
I'm ok with major bump if we will not have any problems with error messages in feature, but in this case we need major version bump and add extra dependency: typeforce. In the same time I think that this is ok, because typeforce is used in bitcoinjs-lib long time. @jprichardson @dominictarr are you ok with typeforce in varstruct and major version bump? |
8543c7a to
004b596
Compare
|
I assume this is OK then? |
I think so, but you need fix tests before merge :) |
2 participants
Related #31 and #22
Rebased on top of #30
If you consider the changing error messages a breaking change, then yes, this is a breaking change.
From my own experience with this module... the error messages are completely inconsistent, and some entirely dependent on the version of
Bufferbeing used anyway.Therefore, I think, after this PR, we could declare them part of the API proper.