Add workspace support for pnpm
- This is an enhancement suggestion in response to issues #1054 and #1138.
What would you like
When the cypress-io/github-action processes a project with a pnpm-lock.yaml lockfile from the pnmp package manager it should be able to interpret pnpm workspaces correctly and run Cypress from a pnpm workspace, including dependency installation and caching.
For example, the following should work:
- name: Cypress test
uses: cypress-io/github-action@v6
with:
working-directory: examples/start-and-pnpm-workspaces/packages/workspace-1
This fails because Cypress can't find pnpm-lock.yaml to install dependencies.
- For pnpm dependency caching see enhancement suggestion #1044.
Why is this needed?
The workspace of a pnpm project does not contain any pnpm-lock.yaml file and cypress-io/github-action does not read and interpret any pnpm-workspace.yaml file in the root of a pnpm project using workspaces. This means that the action needs to be applied twice, once in the root and then again in the workspace in order to run Cypress in a pnpm workspace. (See pnpm workspaces.) This is error prone.
The cypress-io/github-action already provides support for Yarn workspaces. Not providing this functionality for pnpm projects with workspaces is inconsistent.
The benefit for users of pnpm projects with workspaces is that the workflows using GitHub Actions can be written in a more simpler way. This reduces the risk of introducing errors especially with caching the Cypress binary.
Background
pnpm has built-in support for monorepositories (AKA multi-package repositories, multi-project repositories, or monolithic repositories).
pnpm repos using workspaces and Cypress are typically structured similar to the following E2E example:
# repo root
/node_modules
/packages
/package.json
/pnpm-lock.yaml
/pnpm-workspace.yaml
# workspace 1
/packages/ws1
/packages/ws1/cypress/e2e/spec.cy.js
/packages/ws1/node_modules
/packages/ws1/cypress.config.js
/packages/ws1/package.json
# workspace 2
etc.
Other
- PR https://github.com/cypress-io/github-action/pull/1140 added instructions in the README > pnpm workspaces to describe how to handle this configuration without out-of-the-box support. See next section for snapshot of this text:
pnpm workspaces
If you are using pnpm workspaces you need to install dependencies and run Cypress tests in a workspace in separate steps. The snippet below shows this principle.
...
- name: Install dependencies
uses: cypress-io/github-action@v6
with:
working-directory: examples/start-and-pnpm-workspaces
runTests: false
- name: Cypress test
uses: cypress-io/github-action@v6
with:
install: false
working-directory: examples/start-and-pnpm-workspaces/packages/workspace-1
...
See the example project start-and-pnpm-workspaces and the example-start-and-pnpm-workspaces.yml workflow for a full working example including pnpm caching.
Hey, we are trying to update Cypress and have gotten in a broken state again (like #1138 I think).
If I try to run a 'install only' in the repo root folder it seems to fail with this:
/opt/hostedtoolcache/node/20.12.2/x64/bin/npx cypress cache list
sh: 1: cypress: not found
Error: The process '/opt/hostedtoolcache/node/20.12.2/x64/bin/npx' failed with exit code 127
(https://github.com/tidal-music/tidal-sdk-web/actions/runs/8703877596/job/23871336933?pr=107#step:6:311)
If ran from the package with Cypress in it, it fails with this (expected I guess):
Action failed. Missing package manager lockfile. Expecting one of package-lock.json (npm), pnpm-lock.yaml (pnpm) or yarn.lock (yarn) in working-directory /home/runner/work/tidal-sdk-web/tidal-sdk-web/packages/player
(https://github.com/tidal-music/tidal-sdk-web/actions/runs/8702900798/job/23867967977#step:6:13)
Any clue what might cause this? I tried to delete the relevant cache and rerun but got the same results.
@osmestad
- You've tagged your problem here on to the feature request which is not so good for tracking and resolution of your individual issue.
- Please open a new issue to follow on from the issue #1138. I see this is the same repository https://github.com/tidal-music/tidal-sdk-web that was previously causing issues with pnpm and the Cypress GitHub action.
Sorry for that, feel free to delete my comments here if you like! As for the issue, I think I found the problem, we did the caching in a previous step, and the name of the cache was too generic so the post-install trigger did not run. Sorry for the noise!
@osmestad
Good you found your problem!
I don't have privileges to delete other people's posts. You can however delete your own posts or select Hide from the three-dot menu and hide your post(s) from being displayed.
hello, I've just noticed one more problem with pnpm workspace. After latest release of action it shows that there is cypress '13.9.0' cached but later it fails to find binaries for '13.8.1' as our tests use it. I followed start-and-pnpm-workspaces and it worked like a charm until today )
Seems a bit similar to #971
Thank you 🙇🏻
@misha-erm
Please open a new issue if you are asking for help. This issue is for the pnpm workspace support enhancement request, not any bug reports about the existing implementation or documentation.
I added a comment there as I thought that might be in scope of "workspace support" If you think that's not related, I can move it to separate issue, sure
if you are asking for help
For now I just upgraded local cypress version to match the version installed by the github action. Just was a bit surprised that action can't read correct version from pnpm-lock
@misha-erm
I tested start-and-pnpm-workspaces with Cypress 13.8.0 in workspace-1 and 13.9.0 in workspace-2 using the workflow example-start-and-pnpm-workspaces.yml and it worked correctly, installing and caching both versions.
If you need to have mixed Cypress versions in your pnpm workspaces and it is not working for you, then we can look at it in a separate issue. We would need to see your workflow and your lock file for that.
got it. I will keep an eye on it and if it reproduces again will create new issue with reproduction
@misha-erm
- I found that the caching for pnpm (without workspaces) can be unreliable and I logged issue #1179 for that problem. I plan to investigate it further.
- Edit: see now PR #1180