Show sets in output #44
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Before this change, `Set`s were not shown in the output.
For example, `t.alike(new Set([1, 2]), new Set([3, 4]))` would show:
not ok 1 - should deep equal
---
actual:
expected:
...
Now it shows this:
not ok 1 - should deep equal
---
actual:
- 1
- 2
expected:
- 3
- 4
...
EvanHahn
commented
Feb 20, 2024
| @@ -108,7 +108,7 @@ function toYAML (o, maxDepth = 5, indent = '', prev = null) { | |||
| return '|\n' + o.split('\n').map(s => indent + s).join('\n').trimRight() + '\n' | |||
| } | |||
|
|
|||
| if (o && Array.isArray(o)) { | |||
There was a problem hiding this comment.
Not strictly related, but the o && check was unnecessary here.
EvanHahn
added a commit
to digidem/mapeo-core-next
that referenced
this pull request
Feb 20, 2024
`waitForPeers()` has a `waitForDeviceInfo` option. When enabled, this
helper should resolve only after device info is populated.
It had a tricky bug that only manifested some of the time (see
[example CI failure 1][1], [2]). In some cases, the function could
_think_ device info was populated when it wasn't.[^CI]
To fix this, I reworked the helper. It now does redundant work but it's
now stateless-ish, which should avoid this problem.
[^CI]: Well, that's what I could reproduce locally. The errors on CI are
unhelpful ([which I hope to fix in Brittle][brittle PR]). It's
possible a different problem exists on CI that I couldn't repro
locally.
[1]: https://github.com/digidem/mapeo-core-next/actions/runs/7925562783/job/21731451900
[2]: https://github.com/digidem/mapeo-core-next/actions/runs/7965492933/job/21745121763
[brittle PR]: holepunchto/brittle#44
EvanHahn
added a commit
to digidem/mapeo-core-next
that referenced
this pull request
Feb 20, 2024
`waitForPeers()` has a `waitForDeviceInfo` option. When enabled, this
helper should resolve only after device info is populated.
It had a tricky bug that only manifested some of the time (see
[example CI failure 1][1], [2]). In some cases, the function could
_think_ device info was populated when it wasn't.[^CI]
To fix this, I reworked the helper. It now does redundant work but it's
now stateless-ish, which should avoid this problem.
[^CI]: Well, that's what I could reproduce locally. The errors on CI are
unhelpful ([which I hope to fix in Brittle][brittle PR]). It's
possible a different problem exists on CI that I couldn't repro
locally.
[1]: https://github.com/digidem/mapeo-core-next/actions/runs/7925562783/job/21731451900
[2]: https://github.com/digidem/mapeo-core-next/actions/runs/7965492933/job/21745121763
[brittle PR]: holepunchto/brittle#44
|
Awesome! 3.4.1 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Before this change,
Sets were not shown in the output.For example,
t.alike(new Set([1, 2]), new Set([3, 4]))would show:Now it shows this: