Extract cypress integration into separate @bigtest/cypress package in separate workspace

[cowboyd]

Our goal with cypress integration was to make using interactors as easy as possible. That's why our original design involved required nothing more than just importing interactors from the bigtest package:

import { TextField } from 'bigtest';

describe('login', () => {
  cy.do(TextField("username").fillIn("cowboyd"));
})

While this was easy, it turns out not to be that simple, as it introduces a number of complexities.

1. There is no way to specify which version of cypress this works on. We don't want to introduce a "hard" dependency from bigtest -> cypress and so we just detect at runtime if cypress is there and then extend it. While that is kinda cool, what happens if the cypress API changes? We have no way of knowing until runtime. What if we want to support more than one version? This puts us in the unenviable position of having to dynamically link every possible version of cypress in every possible version of bigtest.
2. In order to develop and test we need to have cypress in our devDependencies. This adds a huge overhead to the install weight of node_modules and makes CI cycles significantly longer.

A solution to both of these problems is to move our integration into a separate @bigtest/cypress package. This package can depend on a specific version range of bigtest interactors and a specific version range of cypress. That way, if we need to change the cypress integration, we can just release a new version of @bigtest/cypress but anybody who needs to use the old integration is still good to go.

If we put the package in a separate integrations workspace, then it can be built and cached separately.

• create and publish @bigtest/cypress
• update README and interactor guides

[dagda1]

@cowboyd thanks for the write-up. Let me feed this back to you to double-check I have understood the requirement:

• We create a new package which IS in our monorepo called @bigtest/cypress.
• @bigtest/cypress's package.json has the reference to "cyrpress": ".x.x.x".
• Move all things cypress from @bigtest/interactor to @bigtest/cypress.
• Create a new github actions workspace called integrations that will build, test etc. which at this stage is solely for @bigtest/cypress.

[cowboyd]

@dagda1 Yes. I'm thinking that this should be in our monorepo, but it should exist in a separate workspace. That way, we don't have to pull in all of cypress's dependencies. Our current dev dependency on react-scripts currently plays hell with our install.

What if we create a separate workspace for integrations? E.g.

{
  "workspaces": {
    "packages": [
      "packages/*",
    ],
    "integrations": [
      "integrations/cypress",
      "integrations/jest",
      "integrations/whatever",
    ]
  }
}

We might even want to put the sample app in there, since that's where it will share its true dependencies.

The only real drawback I see is that if we're working on an integration, and it requires an upstream fix to @bigtest/interactor it maybe difficult to do a proper {npm|yarn} link. I'm not sure if that would work as expected

[minkimcello]

We might even want to put the sample app in there, since that's where it will share its true dependencies.

What should we do about the bigtest packages that uses the sample app for its tests?

[cowboyd]

What should we do about the bigtest packages that uses the sample app for its tests?

They would do an install of the sample app as part of their test setup, but since the sample app would not have cypress or jest in its dependencies (only its dev dependencies), those would not come through.

[dagda1]

@cowboyd if @bigtest/cypress is part of our monorepo and it is in the packages array in the root package.json

  "workspaces": {
    "packages": [
      "packages/eslint-plugin",
      "packages/cypress",
     ....

Then cypress will get installed and hoisted when you do a yarn install at the root.

I think we can include in the monorepo but not as part of the packages arrary.

@minkimcello does the sample app use react-scripts?

[minkimcello]

does the sample app use react-scripts?

The sample app uses parcel and does not have react-scripts.

[dagda1]

@minkimcello oh sorry, I remember you saying. Great, that is good news.

[jbolda]

I presume since we are pursuing this route, that we can close the cheeky halfway there version in #726?

[cowboyd]

@dagda1 why not put it in a separate "integrations" workspace and not the main "packages" workspace? Would that not be a clean solution?

[dagda1]

@dagda1 why not put it in a separate "integrations" workspace and not the main "packages" workspace? Would that not be a clean solution?

yes sorry, that makes total sense. I thought you meant something else other than a yarn workspace earlier.

workspace is a very overloaded word :).

[minkimcello]

So would this mean a user wanting to use interactors in cypress will need to install both bigtest and @bigtest/cypress are we still going to export the cypress package from interactors?

[cowboyd]

So would this mean a user wanting to use interactors in cypress will need to install both bigtest and @bigtest/cypress are we still going to export the cypress package from interactors?

We could do it that way, but I was thinking that we just re-export the interactor functions directly from the @bigtest/interactors package. For example:

import { TextField } from '@bigtest/cypress'

One we have this, we could propose that we move the integration over to @cypress itself with @cypress/interactors for example.

[minkimcello]

So would this mean a user wanting to use interactors in cypress will need to install both bigtest and @bigtest/cypress are we still going to export the cypress package from interactors?

Oh oops, there was a typo in my question. I was asking whether the user will need to install bigtest & @bigtest/cypress or just bigtest but I just realized someone that wants to use @bigtest/cypress most likely won't need the entire bigtest package anyway. 👍