-
-
Notifications
You must be signed in to change notification settings - Fork 6.5k
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
jest-diff CLI #7781
jest-diff CLI #7781
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is great! :) Left some nits to address. Also adding documentation to jest-diff
's README would be a plus
Yes, I have also written script like your example :) By the way, see What do you think about comment on chat by @SimenB to do it as |
There is no |
Sindre Sorhus would be proud :D I'm not sure about moving it to community. I think there's some merit in keeping it tied to Jest releases. Pretty much every feature of |
Yes, what you say about releasing consistent versions from Jest monorepo makes sense. I remember that core versus cli came up for ESLint but forget the details. @SimenB, for the public record (as Nicholas would admonish us) can you summarize precedents from other projects? Regardless of decision about packaging, I am happy for another known use case for
|
I'm happy for the CLI to live in the monorepo, fwiw. It's keeping it as a single package I'm against.
😅 My thinking is that, unless a tool's primary use is to be run through a CLI, it shouldn't bundle a CLI by default.
100% agree |
|
||
// eslint-disable-next-line import/default | ||
import jestDiff from '../'; | ||
import {NO_DIFF_MESSAGE} from '../constants'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is IMO an example of where a separate CLI would force a better API.
It's imported to allow the CLI to remove a message that shouldn't really be in a diffing algorithm. Instead it should probably be an option (or structured return values, or something else entirely), but since we have access to private stuff, it's more natural to just import it
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah it really bugged me writing this that the return values of jest-diff are so weird 👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, those constants :(
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we fix this without a breaking change?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, adding an option which changes the returned thing (from a string to something structured) should be fine in a minor (as long as it's opt-in). Might be a bit painful WRT flow types but probably fine
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll fool around with some non-breaking API designs.
Probably on the weekend. So much work, so little time for my Jest todo list :/
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you, mee too :/
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Regarding the null
return values for asymmetric matchers: Would it be fine to just treat them like "no difference"? The reason they were originally introduced was #8146 - in that case, you would get the "No visual difference" message as well. Sooner or later we'll have to rethink jest-diff
(and expect
and pretty-format
) in light of #6184 , but for now it would be good to have just "differs, here's the string" and "does not differ (visually)" as returns values so that we can come up with a clean and simple API
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(Actually, what's now SIMILAR_MESSAGE
will need to have a special case in the return value too :/ )
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Perhaps we should return something like {differs: true, message: string, toJsonIgnored: boolean} | {differs: false}
I'll close this for now since I don't think I'll have time to make the required changes to finish this anytime soon and it's not high priority. If anyone wants to pick this up, feel free. Otherwise it'll be somewhere on my todo list 😅 |
This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
Summary
jest-diff
is a nice utility for comparing large JSON structures. I've written node scripts likequite a few times to compare e.g. HTTP response bodies.
This PR adds a CLI to
jest-diff
that can be used after installingjest-diff
globally (or, if installed locally, e.g. in a project's shell scripts).It is sort of a minimum viable implementation, it would be conceivable to add e.g. support for command-line flags that control
DiffOptions
in the future.It would also be conceivable to give other packages this treatment if they could be useful as a CLI tool, e.g.
pretty-format
.cc @pedrottimark had this lying around semi-finished for some time now - this is the thing that lead me to #7605 😄
Test plan
CLI e2e tests included.
jest-diff
script added for convenient manual testing.