-
Notifications
You must be signed in to change notification settings - Fork 3.2k
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
fix: discover CT community definitions in monorepos with hoisted dependencies #26066
Conversation
…-io/cypress into launchpad-dep-resolution-exports
…-io/cypress into launchpad-dep-resolution-exports
…-party-monorepo-resolution
I still need to add a test to automatically verify that we will find third party dependencies for monorepos, but I'm looking for some feedback in the mean time |
6 flaky tests on run #44729 ↗︎
Details:
commands/net_stubbing.cy.ts • 3 flaky tests • 5x-driver-webkitcypress/cypress.cy.js • 3 flaky tests • 5x-driver-webkit
This comment has been generated by cypress-bot as a result of this project's GitHub integration settings. |
@@ -25,6 +26,46 @@ const thirdPartyDefinitionPrefixes = { | |||
globalPrefix: 'cypress-ct-', | |||
} | |||
|
|||
const ROOT_PATHS = [ |
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... should this be ROOT_FILES
?
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 used the term paths because some of them are directories and some are files, for example .git
is a directory.
packages/scaffold-config/test/unit/ct-detect-third-party.spec.ts
Outdated
Show resolved
Hide resolved
|
||
packageJsonPaths = [...packageJsonPaths, ...newPackagePaths] | ||
|
||
const isCurrentRepositoryRoot = await isRepositoryRoot(directory) |
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 can give this PR a test later, but definitely will be good to see some tests around this full functionality (whether it's Cy-in-Cy, or just an elaborate unit/integration test in this package).
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 added a unit test in this package, let me know what you think
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.
Tested it out, seems to be working as expected for the minimal reproduction.
Also, might be a good chance to make a little OSS module like find-project-root
or something -- what do you think? Seems like something that'd be pretty useful.
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.
Testing this went fine @astone123, I see you have a few open comments from @lmiller1990 so feel free to tag me for re-review
…-party-monorepo-resolution
@@ -404,7 +404,15 @@ async function makeE2ETasks () { | |||
} | |||
}, | |||
async __internal_openProject ({ argv, projectName }: InternalOpenProjectArgs): Promise<ResetOptionsResult> { | |||
if (!scaffoldedProjects.has(projectName)) { | |||
let projectMatched = false |
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.
Had to re-work this in order to call cy.openProject
with a directory inside of a project like <projectName>/packages/foo
to test monorepos
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.
Shame we lose the auto completion :(
Let's do it for now, but I wonder if we can find a way to keep the completion 🤔
@@ -235,8 +235,10 @@ function openGlobalMode (options: OpenGlobalModeOptions = {}) { | |||
}) | |||
} | |||
|
|||
function openProject (projectName: ProjectFixtureDir, argv: string[] = []) { | |||
if (!fixtureDirs.includes(projectName)) { | |||
type WithPrefix<T extends string> = `${T}${string}`; |
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.
Same here, this allows us to open Cypress from within a project to support monorepo testing
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.
Looks good, quick commit since I think this will break windows CI without path.join
b172a09
@@ -404,7 +404,15 @@ async function makeE2ETasks () { | |||
} | |||
}, | |||
async __internal_openProject ({ argv, projectName }: InternalOpenProjectArgs): Promise<ResetOptionsResult> { | |||
if (!scaffoldedProjects.has(projectName)) { | |||
let projectMatched = false |
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.
Shame we lose the auto completion :(
Let's do it for now, but I wonder if we can find a way to keep the completion 🤔
|
||
it('Scaffolds component testing for monorepos with hoisted dependencies', () => { | ||
cy.scaffoldProject('ct-monorepo-unconfigured') | ||
cy.openProject('ct-monorepo-unconfigured/packages/foo') |
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.
Random idea to keep the autocompletion on the project name:
cy.openProject('ct-monorepo-unconfigured', { package: 'packages/foo' })
Additional details
Right now when we detect CT community framework modules during the Launchpad setup, we only check the
projectRoot
node_modules/
and then return. This doesn't work if you have a monorepo that hoists dependencies to the repository root.This PR adds logic to search from the project root to the repository root for community framework modules and return all of the ones that are found.
We use a variety of methods to determine whether or not we've found the repository root:
lerna.json
,nx.json
, etc).git/
directory (meaning that Git has been configured at this level, indicating a repository root)package.json
having aworkspace
entry in itThis isn't a fool-proof way of determining the repository root but it should work for most projects. I basically copied what Vite does https://github.com/vitejs/vite/blob/0f6de4dcff783ec21fada47651d564cd5e2631b2/packages/vite/src/node/server/searchRoot.ts#L59
Steps to test
Use a monorepo, eg https://github.com/lmiller1990/ct-monorepo-bug
yarn cypress:open
ct-monorepo-bug/packages/foo
in CypressHow has the user experience changed?
PR Tasks
cypress-documentation
?type definitions
?