Cypress 14.0.0 on macOS incorrectly resolves entry path – “Cannot find module …/Contents/MacOS/Contents/Resources/app/index.js” #31016
Description
Summary:
When running Cypress 14.0.0 on macOS, Cypress attempts to spawn a process using an incorrect internal path. Instead of loading the entry point from
…/Cypress.app/Contents/Resources/app/index.js
it erroneously appends an extra Contents/MacOS segment (i.e.,
…/Cypress.app/Contents/MacOS/Contents/Resources/app/index.js
This causes Node to throw a “Cannot find module” error.
Steps to Reproduce:
- Installation: Install Cypress 14.0.0 (e.g., within a frontend package of a monorepo).
- Test Trigger: Run tests via a pre‑push hook or by invoking:
npx cypress run --project front
- Error Observation: Observe that Cypress spawns a process with the following arguments (from debug logs):
... spawn args [ '/Users/<username>/Library/Caches/Cypress/14.0.0/Cypress.app/Contents/MacOS/Contents/Resources/app/index.js', ... ]
and then fails with:
Error: Cannot find module `/Users/<username>/Library/Caches/Cypress/14.0.0/Cypress.app/Contents/MacOS/Contents/Resources/app/index.js`
Current Behavior:
- Cypress calculates the entry point with an extra Contents/MacOS directory segment.
- The real file exists at:
/Users/<username>/Library/Caches/Cypress/14.0.0/Cypress.app/Contents/Resources/app/index.js
- Attempts to work around this by creating a symlink in the expected location fail because macOS does not permit modifying parts of the Cypress app bundle (e.g., errors like “Operation not permitted” on Contents/PkgInfo).
Expected Behavior:
Cypress should either:
- Correctly resolve its internal file structure and load the module from
…/Cypress.app/Contents/Resources/app/index.js
- Or provide a configuration or environment variable to override the expected internal path so that users do not have to modify protected system directories.
Environment:
- OS: macOS (e.g., Big Sur/Monterey)
- Cypress Version: 14.0.0
- Node Versions:
- System Node (e.g., v22.9.0) when running commands
- Cypress’s bundled Node (e.g., v20.18.1) used for spawning
- Context:
- Using VSCode’s Git integration with a Husky pre‑push hook
- Cypress is installed locally within a monorepo’s frontend package
Reproducible Demo:
A minimal reproduction can be set up by:
- Creating a monorepo with a frontend package that installs Cypress 14.0.0.
- Adding a pre‑push hook that runs:
npx cypress run --project front
- Triggering a push and capturing the error output.
- Manually verifying that the file exists at:
.../Cypress.app/Contents/Resources/app/index.js
while Cypress is trying to load from:
.../Cypress.app/Contents/MacOS/Contents/Resources/app/index.js
Additional Context / Attempts:
- A workaround was attempted by manually creating a symlink to “fake” the expected path:
mkdir -p "$HOME/Library/Caches/Cypress/14.0.0/Cypress.app/Contents/MacOS/Contents/Resources/app"
ln -s "$HOME/Library/Caches/Cypress/14.0.0/Cypress.app/Contents/Resources/app/index.js" "$HOME/Library/Caches/Cypress/14.0.0/Cypress.app/Contents/MacOS/Contents/Resources/app/index.js"
This failed due to macOS’s SIP (System Integrity Protection) blocking modifications in the app bundle.
- Adjusting permissions (e.g., via sudo chown) also fails on protected files (e.g., /Contents/PkgInfo).
Request:
Please confirm whether this is a known packaging regression in Cypress 14.0.0 on macOS. Is there a configuration option or recommended workaround (other than downgrading) that allows Cypress to resolve its internal path correctly without modifying protected files? Any guidance or plans to address this in a future release would be greatly appreciated.
Thank you for your assistance!