-
Notifications
You must be signed in to change notification settings - Fork 67
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
Selective test on workspace name with the --package option #2145
Conversation
🦋 Changeset detectedLatest commit: 0111c22 The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
Default: `undefined` | ||
|
||
Run all the test for the workspace with the specified package name. Can be | ||
repeated to select more than one workspace. Can be combined with the |
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.
Also a typo?
repeated to select more than one workspace. Can be combined with the | |
repeated to select more than one package. Can be combined with the |
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.
Maybe not. I'm confused - are they workspaces or packages? In my mind, a workspace can consist of many packages (the workspace usually means the packages
dir, if talking in yarn languge)
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.
It's incredibly confusing, but it seems that any package that falls in the workspaces
glob / array in the manifest is called a "workspace": https://classic.yarnpkg.com/lang/en/docs/workspaces/
randomOutputFolder, | ||
['test', '--ancestors', '--package', 'b', '--package', 'c'], | ||
); | ||
expect(resultPackagesWithAncestors.stderr).toContain( |
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.
nit: could maybe use a single expect
statement here
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.
Mmmh, not sure what you mean - it's not possible to pass an array to toContain
and it's not possible to chain expectations, how would you use a single expect
?
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.
Unless you're saying that we can conflate packages/c/src/__tests__/utils/c-nested.test.ts
and packages/c/src/__tests__/utils/c-nested.test.ts
into their common root: packages/c/src/__tests__/
; in that case I explicitly wanted to show that we're executing all the tests of a workspace, including those in subdirectories.
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.
What's the shape of resultPackagesWithAncestors.stderr
? I can imagine we can find a way to dedupe this a bit, but it's really not a big deal
Co-authored-by: Sam Brown <sam.brown@jpmorgan.com>
Enhance
modular test
with the following behaviour: