I'm having a very strange issue:
Working on a project, which is a monorepo managed with lerna, I am unable to run tests for some reason unless I use sudo. I know it is not a project configuration issue, because no one else on my team is experiencing this problem.
The error, which is thrown immediately, ends up being:
Jest encountered an unexpected token
...
/Users/jasmar/dev/project/src/__setup__/setupTest.js:1
({"Object.<anonymous>":function(module,exports,require,__dirname,__filename,global,jest){import { configure } from 'enzyme';
My environment is:
Mac OS X High Sierra
yarn (installed via brew)
Node 8.10.0 (via nvm; installed via curl)
I am an admin on the machine and have run sudo chmod -R ug+w . against the project directory to no avail.
I've also tried npm run test to no avail.
The test script that yarn runs is FORCE_COLOR=1 lerna --concurrency=4 run test and I have tried dropping concurrency to 1.
While running sudo yarn test does work, it is problematic as it generates new snapshots with incorrect permissions and makes managing version control extremely difficult.
Any ideas would be hugely appreciated.
Thanks!
remove the underscores for SetUp
Related
I've been using Cypress locally on my MacBook for some time and it's been going great. Lately my device has been having trouble, so I set up WSL on my PC so I could have a backup in case the worst were to happen.
We use yarn to handle dependencies, and I used NPM to install Cypress and Yarn.
Originally everything I was installing was going into a mounted virtual drive, where nothing was working. I eventually got it running off the linux directory, and Yarn and the dependencies installed fine. I also was able to install Cypress#9.5.4, which is the current version I'm using.
Every time I try to run Cypress headed or headless, I'm being met with the following:
No version of Cypress is installed in: /home/workterminal/.cache/Cypress/9.5.4/Cypress
Please reinstall Cypress by running: cypress install
----------
Cypress executable not found at: /home/workterminal/.cache/Cypress/9.5.4/Cypress/Cypress
----------
A couple coworkers took a stab at it, and this is as far as we could get before I decided to reach out for help here. We got me off the mounted virtual drive, we got NPM and Yarn installed properly after using the linux directory, and then reinstalled Cypress using yarn add cypress#9.5.4, which completed successfully.
We've tried expanding $PATH to include everywhere where Cypress exists, but it always looks in .cache. What can I do to toubleshoot further?
I'm developing a lib for common use in a couple react-native projets and for that I'm using a scaffolding lib recommended on react-native official docs page. This is what the company uses, so I have to use it too.
For some reason, running yarn from the command line on my windows machine does absolutely nothing, not even outputs an error message. The company had to lend me a Mac so I can work on the lib. I'm not saying just yarn commands like trying to install packages, even running yarn --version gives me no output, it just halts.
That's the strange part, it only happens if I'm running yarn from inside the project's folder. If I run yarn on my windows machine from some arbitrary folder or any project that does not uses react-native-builder-bob, yarn works normally. I can install packages, check the version, run commands, everything ok. That makes me think it's not something wrong with my yarn installation. Both the mac and my windows have installed version 1.22.10.
I dug through the issues on bob's github but could find nothing regarding windows and yarn. I also have a spare SSD which I tried running a fresh windows install, setting up my work environment again and still got the same issue.
I really want to use my windows machine to work on this project since it's way more powerful than the mac they lend me. Any help would be much appreciated
I had the same problem. Fixed it by changing options object scripts/bootstrap.js
const options = {
cwd: process.cwd(),
env: process.env,
stdio: 'inherit',
encoding: 'utf-8',
shell: true //add this property
};
I'm assuming you have already installed yarn and node.
I have tried other solutions provided, none of them helped this exact scenario.
We have recently updated Jenkins machine to Catalina, then Jenkins from 2.5 to 2.222.1, then ruby from 2.3 to 2.6, reinstalled Cocoapods.
/usr/local/bin/pod install command fails in Jenkins CI throwing error
env: ruby_executable_hooks: No such file or directory
Remotely logged in to machine and running same command from same job folder in Terminal - all runs good with no issues
Anyone know what might be an issue?
This question answer game an idea
Error env: ruby_executable_hooks: No such file or directory while running Slather on Jenkins
This works fine
$HOME/.rvm/gems/ruby-2.6.5/wrappers/pod install
Though same fix for xcpretty doesn't seem to work. But that is for another time
I'm trying to get an electron forge app running on my Windows 10 machine via Linux on windows (using the new built-in windows bash functionality).
When running electron-forge start I am getting back the error message:
[1484:1126/222326.466455:FATAL:setuid_sandbox_host.cc(157)] The SUID sandbox helper binary was found, but is not configured correctly. Rather than run without sandboxing I'm aborting now. You need to make sure that /mnt/c/.../node_modules/electron/dist/chrome-sandbox is owned by root and has mode 4755.
From some searching, this thread on the electron Github makes it pretty clear that this is somewhat by design and the way to get around it is to run chmod as a root user post-installing all of the dependencies.
I attempted to do this and the command looked like it had worked (no error on running the chmod to 4755), but that didn't fix running electron-forge start - I still got the same error message. I looked into that a bit and it seems that this has to do with what files the linux subsystem are allowed to control permissions for per this Microsoft thread.
Is there some other trick to getting electron forge to work with bash on Windows?
I found that running the electron-forge init from Windows powershell into a native Windows directory allowed me to subsequently use npm start in my-app (for example) in WSL. So ultimately what I ran was
powershell npx create-electron-app my-app
(I have alias powershell="/mnt/c/windows/system32/WindowsPowerShell/v1.0/powershell.exe" in my .bashrc file)
I'm new to Selenium webdriver but the issue that I am running into does not seem like a common problem (looked everywhere for solutions for 4+ hours).
macOS High Sierra 10.13.2 - Selenium 3.13.0 [via pip3] -
ChromeDriver 2.40 [via web source] - Chrome 68 - Python 3.7
Here's what happened:
Initially chromedriver is in my Applications directory with .bashrc and .bash_profile including:
export PATH="$PATH:/usr/local/Cellar/python/3.7.0/bin:/Applications"
I was building a scraper in Python 3.7 everything is working fine executing from command line:
python3.7 scraper.py
I want to start running scraper.py from inside SublimeText3.
I copy chromedriver into /usr/local/Cellar/python/3.7.0/bin to be available for my python3 Sublime build system.
Doesn't work: something to do with it not being the original.
Accidentally deleted original.... So I remove all traces of chromedriver and redownload to Applications directory (original working conditions).
Now, I try to run again from command line and I'm getting Only local connections are allowed.
I try to execute chromedriver on the command line and I get bash: command not found. Even when I am in the Applications directory! Whereas before I could execute chromedriver from any directory.
Every solution online suggests that it's either a compatibility issue or a PATH issue but neither is the case.
Tried rebooting my system, reinstalling python, reinstalling Selenium, reinstalling chromedriver again, moving chromedriver/redirecting PATH, rebooting my system again, everything...
Any input would be greatly appreciated. I'm thinking it has more to do with the OS then anything else. But can't make heads or tails of this. Also wondering if using a virtualenv would be able to circumvent this issue?
UPDATE: To anyone experiencing a similar issue, I would recommend just using a virtualenv. This allows you to work in an isolated python environment without having to clutter up your system with global packages and potentially risking a bug in your system's configuration.