Skip to content
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

Cypress 10 Migration deletes cypress.json after first project and doesn't migrate every project #11454

Closed
rickhopkins opened this issue Aug 4, 2022 · 4 comments · Fixed by #12036
Assignees
Labels
outdated scope: testing tools Issues related to Cypress / Jest / Playwright / Vitest support in Nx type: bug

Comments

@rickhopkins
Copy link

NOTE: This occurs when the cypress.json is moved to the root directory so as to share settings across applications and then it uses .env files to override specific settings.

Current Behavior

Cypress.json is deleted after first project is migrated. No other projects are migrated after this.

Expected Behavior

Cypress.json should be deleted after all projects are migrated.

Steps to Reproduce

Create nx angular monorepo with NX < 14.5
Create multiple angular projects with e2e projects.
Migrate nx monorepo to latest
Run nx g @nrwl/cypress:migrate-to-cypress-10

Minimal github repo:
https://github.com/rickhopkins/nx-cypress-10-migrate-bug

Just run the nx g @nrwl/cypress:migrate-to-cypress-10 on the repo above and you will see the effect.

@rickhopkins
Copy link
Author

My current workaround is to undo the delete of the cypress.json file and rerun the migration for each project

@AgentEnder AgentEnder added the scope: testing tools Issues related to Cypress / Jest / Playwright / Vitest support in Nx label Aug 6, 2022
@barbados-clemens barbados-clemens self-assigned this Aug 11, 2022
@barbados-clemens
Copy link
Contributor

barbados-clemens commented Aug 11, 2022

so just for context here, the migration works by reading the cypress.json file to see how it's configured.
i.e.
where are the tests located?
where is the support file?

the migration can assume some paths, but in most cases if you've moved to defining/overriding configs like this the migration can't assume the defaults are being used which could results in a bad migration.

also using a cypress.json at the root seems to be breaking cypress 10 currently because of ts-node so I wouldn't recommend that method anyways.

I'm on the fence on if there is a way the migration can reliable migrate a setup like this.

what you could do to get around is write a small generator to walk through all the e2e projects and generate a cypress.json file from the root json and .env file, update the project config for that local json.

then run the migration
and then pull out your shared config stuff back out and use it like a preset as described in this comment.
(this could also be automated in a custom generator)

i.e.

// some tmp workspace generator

// wrote this from memory so don't assume this params and options are right from @nrwl/devkit, but should be close enough to get started.

function default function(tree:Tree) {
  const rootCypressConfig = readJson(tree, 'cypress.json');

  forEachExecutorOptions(tree, '@nrwl/cypress:cypress',(options, projectName, targetName, configuration) => {
    // TODO:handle any extra configuration you might have for this target

    const projectConfig = readProjectConfiguration(tree, projectName);

    const projectCypressJson = updateConfigForProject(tree, rootCypressConfig, projectConfig);

    const projectCypressJsonPath = joinPathFragments(projectConfig.root, 'cypress.json');

    tree.write(projectCypressJsonPath, projectCypressJson)

    projectConfig.targets[targetName].cypressConfig = projectCypressJsonPath;

    updateProjectConfiguration(tree, projectName, projectConfig)
  })


  // @nrwl/cypress:migrate-to-cypress-10
  migrateToCypress10(tree)

  forEachExecutorOption(tree, '@nrwl/cypress:cypress', (options, projectName) => {
  dedupeCypressConfigs(tree, readProjectConfiguration(tree, projectName))
})
}

function updateConfigForProject(treem, rootConfig, projectConfig) {
// do whatever you need to do to return a merged config like reading the .env file and providing the overrides

  return mergedConfig
}

function dedupeCypressConfigs(tree, projectConfig) {
  // go read each cypress.config.ts and pull out the shared options and spread in the a 'preset' from the root of the workspace
}

not ideal for sure, but can't seem to find a way to apply this safely across all types of workspaces as it's kind of non standard for an nx workspace

@barbados-clemens
Copy link
Contributor

I reworked the migration so now it should at least rename files regardless of already migrating the same configuration file for the cases where configurations are share.
I'm not reading the .env files though as that can get hairy, so now the migration runs for every project, but you'll need to manually update the .env so basically doing the
support/index.ts => support/e2e.ts and src/integration => src/e2e in the .env file.
WkMacM1-cbGl5R2z_09151644

@github-actions
Copy link

This issue has been closed for more than 30 days. If this issue is still occuring, please open a new issue with more recent context.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Mar 21, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
outdated scope: testing tools Issues related to Cypress / Jest / Playwright / Vitest support in Nx type: bug
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants