-
-
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
Only match relative paths when specifying paths #12519
Conversation
Oh, looks like a pretty large refactor! Ping me when you have something semi-working and I'll take a look! 🙂 |
@SimenB looks ready to go! |
This disconnects |
@SimenB how's that? |
This PR is stale because it has been open 90 days with no activity. Remove stale label or comment or this will be closed in 30 days. |
@SimenB ping |
This PR is stale because it has been open 90 days with no activity. Remove stale label or comment or this will be closed in 30 days. |
This PR is stale because it has been open 90 days with no activity. Remove stale label or comment or this will be closed in 30 days. |
Not stale |
@brandon-leapyear @SimenB needs rebase on |
✅ Deploy Preview for jestjs ready!Built without sensitive environment variables
To edit notification comments on pull requests, go to your Netlify site configuration. |
@legobeat done |
Hey @brandon-leapyear! Finally ready to land this - could I bother you with one last rebase? 🙏 |
Thanks! There's some CI errors - could you take a look? |
@SimenB Updated! |
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.
just some quick feedback (currently travelling) - overall it looks really good!
* for simplicity. | ||
*/ | ||
toPretty(): string { | ||
const regex = this.patterns.map(p => p.replace(/\//g, '\\/')).join('|'); |
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.
why do we want the escape characters? for copy paste?
I'm not sure I find it very "pretty" 😅
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.
ah I was trying to imitate what the original code was doing. Instead of doing this manually, I really should just return this.regex.toString()
.
And, sure, maybe it's not "pretty" anymore, so I'll rename the function to toString
(really it's just rendering the patterns back to a string to show to the user)
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.
Ah that's right, I can't do this.regex.toString()
because the regex now contains extra information about the root directory:
# Original message
Ran all test suites matching /a\/b|c\/d/i.
# TestPathPatterns.toPretty()
Ran all test suites matching /a\/b|c\/d/i.
# TestPathPatterns.regex.toString()
Ran all test suites matching /\/(.*)?a\/b|\/(.*)?c\/d/i.
It's "pretty" in the sense that it's not literally the regex that we're using to match tests. If your main concern is the name of the function, I'm happy to rename it to something else, I just can't think of a better name
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.
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.
Oh ok so currently, jest renders the "no tests found" and the "ran tests matching" messages differently:
$ jest foo/bar bar/baz --testPattern x/a
Pattern: foo/bar|bar/baz|x/a - 0 matches
Ran all test suites matching /foo\/bar|bar\/baz|x\/a/i.
- Should these messages render the pattern the same way? Or should it be the case that the no-matches message shows a "pretty" version, and the tests-found message shows the actual regex?
- If they should be rendered the same way, which way should they be rendered?
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'd personally prefer them to render without escape characters - it's just easier to read (same as we change backslashes to forward slashes for windows in reporters and such). And consistency is always good! 🙂
So 1. yes - 2. Pattern
.
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.
Updated: 3c22ef3
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.
wonderful, thank you so much for your patience!
I think my only comment at this moment in time would be that it'd be nice to avoid reparsing the regexes all the time in the new TestPathPatterns
class we instantiate all over the place. But that is by no means a blocker, so if it proves hard, I'm happy to merge this as-is 🙂
I would weakly prefer merging as-is, mostly because I'm not sure where to put the initialized TestPathPatterns in a place reachable by everything. The obvious thing is to store it in |
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
Fixes #10746.
Adds a new
TestPathPatterns
class which consolidates all the logic related to checking if a test path matches user-specified patterns. This class was necessary to add because previously,GlobalConfig
just stored the final regex intestPathPattern
, which would be shown in output like:But with this change, the regex could get rather complicated; e.g. if a user ran
jest foo bar
in/Users/myuser/github/my-project
, the output would be:So we need to separate the notion of "how to match paths against patterns" from "how to show the patterns to the user" in the config. So instead of the config storing the final regex, it now stores the original list of patterns specified and then builds the regex on demand; in fact, the reality that
TestPathPatterns
uses a regex is now an implementation detail (it pretty much only exposes theisMatch
function as the public entrypoint), so if the pattern-matching logic needs to be more complex than a regex can handle, and we want to just do a naivewe're now free to do so!
Commit explanation
Test plan
Running
yarn jest --listTests user
before this branch listed all tests on a Mac, where everything is under/Users/<username/
. After this branch, it only shows theusers.test.js
tests