Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Invalid arch info in require('os').arch() #18837

Closed
0x009922 opened this issue Nov 9, 2021 · 2 comments
Closed

Invalid arch info in require('os').arch() #18837

0x009922 opened this issue Nov 9, 2021 · 2 comments
Labels
stage: awaiting response Potential fix was proposed; awaiting response

Comments

@0x009922
Copy link

0x009922 commented Nov 9, 2021

Current behavior

On macOS 11.4 20F71 arm64 I am getting x64 arch inside of Cypress' plugin environment (i.e. in cypress/plugins/index.js), but in any other script I am getting the correct arm64.

// cypress/plugins/index.js

const os = require('os')

module.exports = (on, config) => {
  throw new Error(os.arch()) // throws `x64` instead of `arm64`
}

Desired behavior

Cypress should provide correct system information.

Test code to reproduce

Here is a reproduction: https://github.com/0x009922/cypress-issue-invalid-os

Cypress Version

8.7.0

Other

It breaks usage of esbuild@^0.13.0 with "optionalDependencies" installation strategy (see evanw/esbuild#789). pnpm installs correct esbuild-darwin-arm64 and it works outside of Cypress, but when esbuild tries to build something in plugin (e.g. in cypress-esbuild-preprocessor) it tries to resolve esbuild-darwin-x64 package according to os.arch(), and it fails. Apparently, this is not a bug of esbuild, but of Cypress.

@jennifer-shehane
Copy link
Member

Are you using the default nodeVersion in Cypress? It defaults to the bundled Node version, does this behavior change if you set it to use system?

@jennifer-shehane jennifer-shehane added the stage: awaiting response Potential fix was proposed; awaiting response label Nov 9, 2021
@0x009922
Copy link
Author

0x009922 commented Nov 11, 2021

@jennifer-shehane, yes, setting nodeVersion to system changed the behavior to the desired.
I consider this issue is closed. Thank you!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
stage: awaiting response Potential fix was proposed; awaiting response
Projects
None yet
Development

No branches or pull requests

2 participants