Fix testPathPatterns when config is in subdirectory #14934
Conversation
✅ Deploy Preview for jestjs ready!Built without sensitive environment variables
To edit notification comments on pull requests, go to your Netlify site configuration. |
|
@SimenB Okay CI should be good now! |
| import {escapePathForRegex, replacePathSepForRegex} from 'jest-regex-util'; | ||
|
|
||
| type PatternsConfig = { | ||
| export class TestPathPatterns { |
There was a problem hiding this comment.
didn't notice this was here before 😅
I don't wanna export non-types from this package. I'm fine with not having it in jest-util, but could you pull it out into its own new package?
There was a problem hiding this comment.
So it can't be in jest-util because jest-util imports from @jest/types and TestPathPatterns is used in GlobalConfig, so there'd be a circular dependency.
But I broke it out into a new jest-pattern library and pushed a commit. Hopefully it builds fine
I'm not too sure about this change. Currently the config is JSON serializable - that changes if we stick a class instance on it 🤔 |
|
It should still be JSON serializable, because it implements toJSON Pretty sure theres a test somewhere checking this |
|
CI fails now with type errors in the tests. Not sure if that's something we wanna fix, or add the module to the ignore list: Lines 32 to 33 in 343d450 |
|
hm I'll take a look |
|
@SimenB seems like its passing now! |
| '--testPathPatterns=project-1', | ||
| '--testPathPatterns=setup1', |
There was a problem hiding this comment.
right, since this is relative to the project config now, and not the global config. I'm afraid this will be quite breaking as well (when using jets projects just to have a single jest command to run from root rather than as a way to isolate test suites), but let's try! 🙂
|
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
Resolves #14726. No CHANGELOG entry, as it fixes an issue with a new feature that's already in the CHANGELOG.
Follow up to #12519 (which fixes both #10746 and #8226). In this PR, we separate the
TestPathPatternsclass into two classes: one that just represents the list of patterns and one that can match the patterns against a test file. The separation is necessary because there are some uses where we aren't in a project, and can't match against a regex, but we do want to do static analysis of the patterns. For example, when outputting the test summary, we want to show the patterns the user specified, but the summary is global, not per-project.I also made a change I had wanted to do in the initial PR, which is store
TestPathPatternsdirectly inGlobalConfig. Now, the fact that patterns are represented asArray<string>is an implementation detail, and everything using the patterns can only use the provided API.This will make even more sense when
rootDiris removed fromGlobalConfig, as discussed. It would be even nicer ifProjectConfigstoredTestPathPatternsExecutor, but it was getting weird withInitialProjectConfig, so I didn't want to touch that.Test plan
I wrote a new test that is executed with
yarn jest testPathPatterns. It fails on main with "no tests found", and passes on this branch.