Skip to content

feat: add stablePatchmarks option #72

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 6 commits into from
Mar 15, 2019
Merged

feat: add stablePatchmarks option #72

merged 6 commits into from
Mar 15, 2019

Conversation

ericbiewener
Copy link
Contributor

Solves #69.

I'm identifying patch marks with a simple regex that looks for a line starting with @. This seems safe since jest-diff appears to add whitespace at the start of all lines. Therefore, even a line of content that begins with @ will end up padded with whitespace in the diff itself.

And rather than simply stripping out the patchmarks, I'm replacing them with -------------. Since the point of this is to avoid broken diffs, this solves that issue while still giving some indication that there are hidden lines in between those parts of the diff. Perhaps there's a better replacement indicator than that. We could certainly preserve the patch mark @@ notation like @@ ------------- @@ if we think that helps communicate the meaning of the new mark.

Copy link
Member

@thymikee thymikee left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like it's heading i the right direction :). Left some online comments to address

src/index.js Outdated
@@ -43,6 +44,10 @@ const snapshotDiff = (valueA: any, valueB: any, options?: Options): string => {
difference = stripAnsi(difference);
}

if (mergedOptions.omitPatchMarks) {
difference = difference.replace(/^@.*/gm, '-------------')
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we can make this regex better and take into account that we have two @@ and numbers with commas between. Also I'm leaning towards replacing them with:
@@ --- --- @@

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also we only need to check it only if expand === false

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I considered a more rigorous regex, but since jest-diff seems to always pad the start of the line with whitespace, I went the lazy route. But I agree this should be improved. Here's an example of the new regex: https://regex101.com/r/KLDkC0/1

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ha, left out the 0s in the number range. Updated regex: https://regex101.com/r/KLDkC0/2

README.md Outdated
@@ -133,6 +133,8 @@ expect(valueA: any).toMatchDiffSnapshot(valueB: any, options?: Options, testName
- `expand: boolean` (default: `false`) – expand the diff, so the whole information is preserved
- `colors: boolean` (default: `false`) – preserve color information from Jest diff
- `contextLines: number` (default: 5) - number of context lines to be shown at the beginning and at the end of a snapshot
- `omitPatchMarks: boolean` (default: `false`) - prevent line number patch marks from appearing in
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How about stablePatchmarks? I'm still not sure how to best me it. @SimenB ideas?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

stable is better than omit. Other possible verbs:

normalize
scrub

normalize doesn't communicate a whole lot. scrub communicates what we are doing to the patch mark, while stable communicates the purpose behind it.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think I'd still go with stable

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

all set

README.md Outdated
@@ -133,6 +133,8 @@ expect(valueA: any).toMatchDiffSnapshot(valueB: any, options?: Options, testName
- `expand: boolean` (default: `false`) – expand the diff, so the whole information is preserved
- `colors: boolean` (default: `false`) – preserve color information from Jest diff
- `contextLines: number` (default: 5) - number of context lines to be shown at the beginning and at the end of a snapshot
- `omitPatchMarks: boolean` (default: `false`) - prevent line number patch marks from appearing in
diffs. This can be helpful when diffs are breaking only because of the patch marks.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would also be cool to show an example like: changes @@ -1,1 +1,2 @@ to @@ --- --- @

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done

Copy link
Member

@thymikee thymikee left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One last thing and I'm good :)

@thymikee thymikee changed the title Add omitPatchMarks option feat: add stablePatchmarks option Mar 15, 2019
@thymikee thymikee merged commit c297f1d into jest-community:master Mar 15, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants