nx
nx copied to clipboard
Cypress 10 Migration deletes cypress.json after first project and doesn't migrate every project
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.
My current workaround is to undo the delete of the cypress.json file and rerun the migration for each project
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
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.

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.