Recommendations for scaling Cypress across many repositories

[Fgerthoffert]

Hey everyone,

We started to use Cypress a few months and are pretty happy with the journey so far. The past few months were a good opportunity to begin addressing our first challenges and mature in the way we are approaching/using the framework.

Now that we covered many of our typical use cases, we're beginning to look at ways to improve scalability across a large number of repositories/codebases.

Our challenge
We have 100+ individual repositories, each offering specific functionalities (and independent from the next). Some of those repositories are providing mostly front-ends, others are API only and some are in-between. They are sharing a common structure but are ultimately independent services (i.e. OSGI bundles), each with its own lifecycle (and own concerns).

Where we're at today
As we are growing in our adoption of the Cypress, our current approach until now was to maintain a "baseline" repository, containing the "latest-and-greatest" of our Cypress setup, repository serving as a base for new modules. This repository is being regularly updated with our recent findings (utility functions, internal practices) as we cover more and more modules.

This has been working fairly well as a first step, but we are now starting to face some challenges with maintainability (which were expected) in particular when it comes to updating "older modules" with recent improvements done to our "baseline" repository. As you can guess it can become pretty tedious.

A solution for a similar setup

Interestingly, we followed a similar approach when we started to adopt CircleCI. We had the same baseline repository containing a "working" configuration, and we were duplicating its configuration for our modules, progressively evolving in our use of the platform and learning its capabilities.

Our solution to the challenge described here was to use CircleCI Orbs, which are shareable and versioned configuration packages. Repositories are configured to use a set version of the orb, and if we later come back to a module and want to update it, it should be as simple as changing the version of the orb (and addressing breaking changes we might have introduced in the orb)

What we're looking for

Ideally, with Cypress, we would be looking for something similar, maintaining a version of the baseline framework that would contain common Cypress commands, Cypress tasks, page objects (or app actions), and other utilities. This would be versioned and updating a module to use a newer version of the baseline should be as simple as updating its version via npm/yarn (plus addressing any of the breaking changes).

The tests and their fixtures would be unique to each repository and would not be part of the baseline, there should be a way for each module to also have its own set of commands, tasks, page objects available on top of the ones provided by the baseline setup.

I'd be happy to hear any thoughts, recommendations, concerns about such an approach, and pointers towards possible implementation.

PS: We thought about monorepo, but we don't feel it's really an option for us, each module is developed independently, has its own versioning and release frequency. Plus it would be pretty invasive with our current build process for the modules themselves (potentially with a significant refactor).

Thanks,

[jennifer-shehane]

@Fgerthoffert Have you thought about publishing your Cypress common commands/tasks as an npm module to install as a dependency across projects?

Here are some examples of plugins: https://docs.cypress.io/plugins/directory I think all of them are open source. They range across actual pluginsFile functionality to just publishing common Cypress commands to share. It may not solve all configuration questions, but could be a good starting point.

[bahmutov]

You can see how we advise to write and publish custom Cypress commands in these blog posts:

• https://glebbahmutov.com/blog/writing-custom-cypress-command/
• https://glebbahmutov.com/blog/publishing-cypress-command/

[Fgerthoffert]

Thanks, that super helpful as a first step.