I'm using WebDriverIO to automate a web page, I'm able to run my feature files in Chrome but I need them to run in Safari. I'm using a Mojave 10.14.6 device. I've allowed remote automation on safari, and enabled safaridriver from terminal.
My wdio.conf.js capabilities are look like this:
capabilities: [{
maxInstances: 5,
browserName: 'safari'
}]
When I run using chrome it works as spected but in the case of safari I get the following message:
ERROR webdriver: RequestError: connect ECONNREFUSED 127.0.0.1:4444
My package.json looks like this:
"dependencies": {
"#wdio/cli": "^7.5.7"
},
"devDependencies": {
"#wdio/cucumber-framework": "^7.5.3",
"#wdio/local-runner": "^7.5.7",
"#wdio/spec-reporter": "^7.5.7",
"chromedriver": "^90.0.0",
"wdio-chromedriver-service": "^7.0.0"
}
Is there any other configuration I need to add in wdio.conf.js file?
Thanks in advance.
It turns out to be a problem with the port that was being used. After the port was changed from 4444 to the correct value, the issue was solved.
I have a ClojureScript project using shadow-cljs. In this project I am using the NPM package #material-ui, which works fine.
Now I would like to use react-swipeable-views. Therefor I have extended my package.json:
"dependencies": {
"#material-ui/core": "^4.5.2",
"#material-ui/icons": "^4.5.1",
"highlight.js": "9.15.10",
"react": "^16.11.0",
"react-dom": "^16.11.0",
"react-flip-move": "3.0.3",
"react-highlight.js": "1.0.7",
"react-swipeable-views": "0.13.3"
}
When I try to require ["react-swipeable-views" :as sv] I get this error from shadow-cljs:
The required JS dependency "dom-helpers/transition/properties" is not
available, it was required by
"node_modules/react-swipeable-views/lib/SwipeableViews.js".
And in fact, there is no transition directory in node_modules/dom-helpers/. But there is import transitionInfo from 'dom-helpers/transition/properties'; in node_modules/react-swipeable-views/src/SwipeableViews.js.
It looks like a dependency bug in react-swipeable-views, but I am a newbie to NPM.
Any suggestions what the problem is? Or how to debug?
UPDATE
It seams react-swipeable-views depends on the outdated dom-helpers#3.4.0 while shadow-cljs uses the current dom-helpers#5.1.3. See https://github.com/oliviertassinari/react-swipeable-views/issues/542
Is it possible to use both? Or will I have to wait until someone fixes react-swipeable-views?
You correctly identified this is caused by a version conflict.
It is not possible to use both versions, you must resolve this version conflict. You can try installing the older dom-helpers version as the default by adding it to your package.json and npm install it. Maybe the library that was using the newer one still works with the old one?
I have a Vue project generated by the Vue cli 3 and my hot reloading suddenly stopped working in my browsers. Changes made to the code are still picked up by the terminal, however, my browser is not picking up the changes. I have to manually refresh in order to pick up the new changes. As suggested by some others I manually set poll: true in my vue.config.js and I also tried to set the proxy, but both had no success.
Any suggestions to make this work again?
Update:
After some Vue updates, it suddenly started working again. I still don't know the reason for this. It might have been a bug in the vue-cli?
My problem was WDS
Console displayed:
[HMR] Waiting for update signal from WDS...
[WDS] Disconnected!
GET http://ip:port/sockjs-node/info?t=some-number
net::ERR_CONNECTION_TIMED_OUT sockjs.js?some-number
Solution for me was:
in
package.json
change
"serve": "vue-cli-service serve",
to
"serve": "vue-cli-service serve --host localhost",
or
add
module.exports = {
devServer: {
host: 'localhost'
}
}
to
vue.config.js
:)
HMR has problems in various environments, in those situations you can maybe help yourself with the poll option:
https://github.com/vuejs-templates/webpack/blob/develop/template/config/index.js#L21
var devMiddleware = require('webpack-dev-middleware')(compiler, {
publicPath: webpackConfig.output.publicPath,
stats: {
colors: true,
chunks: false
},
watchOptions: {
aggregateTimeout: 300,
poll: 1000
}
})
Seems I finally found it: my $cat /proc/sys/fs/inotify/max_user_watches was on 8192 and this helped me:
echo 100000 | sudo tee /proc/sys/fs/inotify/max_user_watches
Now Vue hot reload works without sudo and without poll ! ))))
One failure mode I've come across here is if you've managed to end up with multiple installations of webpack in your node_modules.
The reload relies on these two bits of code emitting events to each other:
webpack-dev-server/client/index.js
var hotEmitter = require('webpack/hot/emitter');
hotEmitter.emit('webpackHotUpdate', currentHash);
webpack/hot/dev-server.js
var hotEmitter = require("./emitter");
hotEmitter.on("webpackHotUpdate", function(currentHash) {
However, if you have multiple webpacks installed (e.g. a top-level one and one under #vue/cli-service) the require will resolve the first to ./node_modules/webpack/hot/emitter.js and the second to ./node_modules/#vue/cli-service/node_modules/webpack/hot/emitter.js which aren't the same object and so the listener never gets the event and reloads fail.
To resolve this I just uninstalled and reinstalled #vue/cli-service which seemed to clear the package-lock.json and resolve to the single top-level webpack.
I don't know if there's any way to ensure this doesn't happen -- however, it might be possible for vue-cli-3 to spot the situation and at least log a warning in dev mode?
[BTW adding devServer: { clientLogLevel: 'info' } } to vue.config.js was really helpful in debugging this.]
I faced the same issue (the console showed an error that said "[WDS] Disconnected") and here's what I did. Note that I was using the Vue UI tool for managing my project and I did not edit any config files.
Under Tasks/serve, I stopped the task.
I clicked the parameters button and in the input for "Specify host" label, I added the IP of my localhost i.e. 127.0.0.1 and in the input for "Specify port" label, I added 8080.
I saved the parameters and ran the server again from the tool.
Not sure why but this seemed to work for me. I'd love if someone can explain why it works.
I also have this WDS issue with each Vue project I make (kind of annoying, even with latest vue cli 4.5.0 and vue 2.6.11).
So the following solution is what I copy paste each and every time.
In vue.config.js file :
module.exports = {
devServer: {
// Fixing issue with WDS disconnected and sockjs network error
host: '0.0.0.0',
public: '0.0.0.0:8080',
disableHostCheck: true,
// End of fix
}
}
What was the cause in my case:
It seems that the value of: max_user_watches
in the /proc/sys/fs/inotify/max_user_watches
is affecting webpack => which is interfering with hot reloading.
To check your actual value
$cat /proc/sys/fs/inotify/max_user_watches
16384
16384 was in my case and it still wasnt enough.
I tried different type of solutions like:
$ echo fs.inotify.max_user_watches=100000 | sudo tee -a /etc/sysctl.conf
$ sudo sysctl -p
But it seems that even if I changed the value, when I restarted my PC it would go back to default one 16384.
SOLUTION if you have Linux OS(my case, I have Manjaro):
Create the file:
sudo nano /etc/sysctl.d/90-override.conf
And populate it with:
fs.inotify.max_user_watches=200000
It seems 200000 is enough for me.
After you create the file and add the value, just restart the PC and you should be ok.
Maybe this can help https://webpack.js.org/configuration/watch/#changes-seen-but-not-processed
"Verify that you have enough available watchers in your system. If this value is too low, the file watcher in Webpack won't recognize the changes:"
cat /proc/sys/fs/inotify/max_user_watches
"On macOS, folders can get corrupted in certain scenarios. See this article."
And in the link above you can check other known issues.
set NODE_ENV=development might solve your problem.
Adding NODE_ENV=development to your .env file will solve the problem.
I hope that this could be helping someone, I'd used of the terminal in my WebStorm and vue-cli-service didn't work, then I opened a normal terminal and that's it, maybe something in WebStorm didn't let the correct way in the vue-cli-service
I used proxy extension in my Firefox browser. Try turning that off if you have one
Please make sure you don't have any error in your code.
This happens usually because of error in any of our code files.
Just run
npm install -g #vue/cli-init
You can run vue-cli-service serve --public localhost
According the docs:
--public specify the public network URL for the HMR client
https://cli.vuejs.org/guide/cli-service.html#vue-cli-service-serve
This was my problem anyway, HMR was running on the network IP instead, for some reason. Causing CORS and connection refused issues.
For me More Tools >> Clear Browsing data in Chrome did the trick. Also try incognito before.
In Firefox everything was fine.
So before editing your vue.config.js take a look at the browsers.
I solved this problem by changing the versions of my dependencies and devDependencies:
"dependencies": {
"core-js": "^3.4.4",
"vue": "^2.6.10",
},
"devDependencies": {
"#vue/cli-plugin-babel": "~4.1.0",
"#vue/cli-plugin-eslint": "~4.1.0",
"#vue/cli-service": "~4.1.0",
"babel-eslint": "^10.0.3",
"eslint": "^5.16.0",
"eslint-plugin-vue": "^5.0.0",
"vue-template-compiler": "^2.6.10"
},
I'm getting this error with React Native, not ReactJS so all the solutions/workarounds with webpack or browserify wont help.
Full error:
You are currently using minified code outside of NODE_ENV=== "production". This means that you are running a slower development build of Redux. You can use ... bla bla bla ( workarounds for ReactJS )
I'm currently running this config :
"expo": "^23.0.0",
"react": "16.0.0",
"react-native": "https://github.com/expo/react-native/archive/sdk-23.0.0.tar.gz",
"react-redux": "^5.0.6",
"redux": "^3.7.2"
I tried starting the service with --no-minify and I always start it with --dev. I'm running the app on expo as well.
If anyone has a solution or a workaround for this it'd be really appreciated.
If you're running into this issue while using an android virtual device, open the debug menu (CMD+M on a Mac) > Dev Settings -> Uncheck JS Minify and reload your app. Pictures included below for reference.
I try to use Flow in my Nuclide installation but I can't see any diagnostics in my React-Native project. But running flow from cli results int 1000+ errors.
If I save a file the spinner in the bottom bar is spinning and then disappearing completely (no Idle).
.flowconfig
[ignore]
[include]
[libs]
[lints]
[options]
package.json
"devDependencies": {
"babel-cli": "^6.26.0",
"babel-core": "^6.25.0",
"babel-jest": "19.0.0",
"babel-preset-flow": "^6.23.0",
"babel-preset-react-native": "^1.9.1",
"flow-bin": "^0.56.0",
"jest": "19.0.2",
"react-test-renderer": "15.4.2"
},
My App.js
/* #flow */
Math.pow('X');
import boot from "./app/boot";
const app = boot();
export default app;
I too was experiencing frustrating issues with getting Nuclide Diagnostics to report Flow issues to show up in Atom.
Just as you mentioned, running Flow in the CLI would pick up errors, but nothing would show up in the IDE.
I came across your post a bit late, but here is what I did that (finally) did the trick.
1) Probably not necessary, though I did it anyway... I uninstalled Atom to the best of my ability following this post: https://discuss.atom.io/t/how-to-completely-uninstall-atom-for-mac/9084/42
2) I downloaded the latest version of Atom and installed it: https://atom.io/
3) I installed my linters first before installing Nuclide. This seemed to be what I was missing from all my other attempts. I ran apm install linter, apm install linter-eslint, and apm install linter-flow. I fired up Atom, allowed the IDE to install linter-ui-default, and then verified that Atom's own linter-flow was picking up Flow errors. Alas, it was! Good shape.
4) I then finally installed nuclide. When prompted with the choice of either disabling linter or atom-ide-diagnostics-ui to avoid duplicate linting issues, I chose to disable atom-ide-diagnostics-ui to verify that the IDE was still properly picking up Flow issues and fortunately, it was.
5) I then went and switched off linter and re-enabled atom-ide-diagnostics (Atom > Config > nuclide > use > "atom-ide-diagnostics-ui": true). To my huge surprise, everything was still linting and the Flow issues were now integrated into Atom using Nuclide's Diagnostic UI!
Here is a list of the packages I installed in pretty much chronological order:
├── busy-signal#1.4.3
├── intentions#1.1.5
├── linter#2.2.0 (disabled)
├── linter-eslint#8.4.0
├── linter-flow#5.6.1
├── linter-ui-default#1.6.10
└── nuclide#0.271.0
Edit: Added a screenshot of my Nuclide settings
Good luck and I hope this helps some!