I created a VS Cordova project, and need to download some data from a web service, but Ripple runs inside Chrome, and Chrome considers that request "cross-domain" and blocks it. Setting ripple proxy option to disabled/local/remote has no effect. I can start another instance of Chrome with --web-security-disabled command line option, point it to the same URL http://localhost:4409/... and application works fine in that second Chrome. Now all I need is to find a way to pass --web-security-disabled to Chrome when I start it by pressing F5 in Visual Studio. It's probably somewhere in some config file, just need to find it ...
It is difficult to know without looking at the exact code, but it is likely that one of a few of things is happening:
Your code is bypassing the CORS proxy in Ripple
Proxying through Ripple is resulting in the web server denying the request.
You have the Ripple extension installed in Chrome. In effect you can end up with two Ripples running which can cause a number of unexpected behaviors.
To know which is happening, be sure the CORS proxy is set to "local" and check the network tab. An XHR call to www.bing.com would look something like this:
http://localhost:4400/ripple/xhr_proxy?tinyhippos_apikey=ABC&tinyhippos_rurl=http%3A//www.bing.com
Try just doing this from your index.html page and see if it succesfully goes through the proxy.
var xmlhttp = new XMLHttpRequest();
xmlhttp.open("GET", "http://www.bing.com", true);
xmlhttp.send();
If you need to further debug or you want to use Ripple outside of Visual Studio, you can actually install the Ripple npm package and use it outside of Visual Studio. Build for Android in the debug config, then go to the bld/Debug folder and execute the following from the command prompt:
npm install -g ripple-emulator
ripple emulate android --port 12345
A browser Window will appear. Paste that into Chrome if its not your default and retry. You can then see what is going through the proxy in the command prompt.
You can also use this same method to debug your app using the Chrome Dev Tools with --web-security-disabled.
Related
I'm using DDEV with Visual Studio Code and I tried to configure Live Server Extension to automatically auto reload page that I'm working on in Chrome when I hit save in VSC, but it doesn't seem to work with PHP.
Is there a way to configure this to work with DDEV?
I can't seam to find any info on this issue.
Thanks
I've managed to do it another way, with guard and guard-liveguard on linux.
The workflow was:
guard installation
guard-livereload installation
Installation was not quite straightforward, but you can follow the instructions in Terminal and install what's missing if it tells you so.
Guard placed Guardfile inside of /home/user directory so I edited it to contain only this, regarding livereload pard:
guard 'livereload' do
watch(%r{.+\.(css|scss|html|php|js)$})
end
Then I installed Liveguard Google Chrome Browser Extension from here:
http://livereload.com/extensions/
Under settings I had to enable "Allow access to file URLs".
Also, you have to press liveguard extension icon in Chrome in order for it to track changes.
That's about it, now when I edit any of the file types entered in Guardfile (you can edit and add what you need, of course) it automatically reloads my Chrome window whit the edited page opened.
I want to debug my React.js project by adding breakpoints in WebStorm rather than in my web browser.
Is it possible? If yes, how?
Run npm start to get the app running in the development mode.
You can do this either in the terminal or by double-clicking the task in the npm tool window in WebStorm.
Wait till the app is compiled and the Webpack dev server is ready. Open http://localhost:3000/ to view it in the browser.
Create a new JavaScript debug configuration in WebStorm (menu Run – Edit configurations… – Add – JavaScript Debug). Paste http://localhost:3000/ into the URL field.
In WebStorm 2017.1+
No additional configuration is needed: go to step 5!
In WebStorm 2016 (.1, .2 and .3)
Configure the mapping between the files in the file system and the paths specified in the source maps on the dev server. This is required to help WebStorm correctly resolve the source maps.
The mapping should be between the src folder and webpack:///src
If you’re wondering how we got this mapping, check http://localhost:3000/static/js/bundle.js.map file. This is a source map file for the bundle that contains the compiled application source code. Search for index.js, the main app’s file; its path is webpack:///src/index.js
Save the configuration, place breakpoints in your code and start a new debug session by clicking the Debug button next to the list of configurations on the top right corner of the IDE.
Once a breakpoint is hit, go to the debugger tool window in the IDE. You can explore the call stack and variables, step through the code, set watcher, evaluate variables and other things you normally do when debugging.
This app is using Webpack Hot Module Replacement by default and that means that when the dev server is running, the app will automatically reload if you change any of the source files and hit Save. And that works also together with the WebStorm debugger!
Please take note of these known limitations:
The breakpoints put in the code executed on page load might not be hit when you open an app under debug session for the first time. The reason is that the IDE needs to get the source maps from the browsers to be able to stop on a breakpoint you’ve placed in an original source, and that only happens after the page has been fully loaded at least once. As a workaround, reload the page in the browser.
Webpack in Create React App generates source maps of the type cheap-module-source-map. This kind of source maps do not guarantee the most precise debugging experience. We recommend using devtool: 'source-map' To make changes to the app’s Webpack configuration, ‘eject’ the app (refer to the Create React App manual to learn more).
So I'm getting a blue screen of death whenever I have "npm start" running for a reactjs app. It's an intermittent crash, i.e. it doesn't happen every time I run it nor are there any exact steps to duplicate the crash, but I'll try to explain below under what circumstances it happens.
Create a reactjs app using create-react-app npm module.
Start the app using npm start. Chrome window opens, webpack is listening to changes I make to the source files.
Change any source file, and save it. NPM compiles it, Chrome page refreshes, and I can see my changes.
The above things work fine as expected "normally", but once in a while, right after I save a file, the system crashes with a BSOD saying DRIVER_IRQL_NOT_EQUAL_TO_OR_GREATER_THAN (NETIO.SYS) There is no definite "step" or action other than saving the file, or refreshing Chrome that would cause this to happen, and it also doesn't happen every single time.
Here are the steps I took to find out/eliminate the root cause of this issue:
Disabled by AV (Symantec Endpoint Protection).
Use a different browser (Mozilla, hell, even IE).
Changed the system (used a different laptop, although the same type - Microsoft Surface on Windows 10)
Updated all drivers, etc. (Verified by my organization admins)
Closing all other programs, etc. that might potentially be interfering (Atom IDE, Eclipse, etc.)
The necessary conditions for the crash to happen are:
npm start must be running (webpack server on localhost:3000)
A browser window must be open connected to localhost:3000 (if no browser is connected, it doesn't crash even if you change and save the file 200 times - I checked). Also, doesn't matter which browser (Checked with Mozilla/Edge/Chrome)
I believe the crash happens when NPM is recompiling the files and serving it to the browser (asking it to refresh using some websockets), but I'm not an expert on NodeJS/NPM so I'm not sure.
I've been stuck on this issue for more than 2 weeks now. Any help would be really appreciated. Kindly let me know if more information is needed.
The issue was with Symantec DLP (Data Loss Prevention) that was also installed on all our systems. The issue resolved itself after the admins added application exceptions for Nodejs, NPM, my reactjs project workspace paths.
Just posting this so that in case someone has a similar issue they can try this or remove Symantec DLP altogether.
I have my work computer which is a Windows 10 Pro and my laptop is a Windows 10 Home. Working on the same project on both: push and pull to Git. Learning React through Udemy. Both computers using Chrome. Both using Bash on Ubuntu on Windows with latest updates. Both using ConEmu for the console. Both npm -v = 3.10.10. Both node -v = 6.11.2. Hardware is different obviously, but not sure that is relevant and worth listing.
Anyway, this starter project I am playing around with, when I make changes to it and npm start is running, you can see activity in the console, hit refresh in the browser, and any changes made will be reflected.
On the laptop, this process does not work. Make change, save, no activity in console, refresh in browser does not reflect the changes. Have to restart npm start for changes to be reflected. A little irritating to say the least.
Anyway idea what might cause this? Really haven't come across anything in my Googling efforts.
If you are using npm in WSL2.0 for development, please refer the last point in this-
https://create-react-app.dev/docs/troubleshooting/#npm-start-doesnt-detect-changes
While WSL1.0 doesn't use a VM, WSL2.0 does use a lightweight VM, so adding
CHOKIDAR_USEPOLLING=true
in a .env file in the project directory fixed the problem.
On a sidenote, you might wanna take a look at this
Client side
To ensure client side changes aren't being cached, you can open devtools > Network, and check "Disable cache". After enabling this, you won't have anything in the cache as long as devtools is open.
Alternatively, you can use incognito / private browsing mode to prevent the cache from holding on to things.
Server side
I'm sure you've realized that it's a pain to restart your server every time you want to see your code update. There are several tools that will detect file changes and handle restarting the server automatically.
PM2
Nodemon
Forever
I just add file .env and inside FAST_REFRESH=false.
For me, working in Windows, WSL2 caused this not to work. Running npm start in Command Prompt, not WSL solved this issue for me.
Once a node.js program has run to completion in the context of an --inspect session (i.e. via the Chrome dev tools debugger) is it possible to re-start it without having to re-issue the --inspect command from the command-line?
The issue with re-issuing an --inspect command is that it generates a different chrome url every time and one has to then copy-paste this into Chrome each time. Ideally I want to be able to push F5 to re-start the chrome debug session.
So two issues:
I cannot restart the debug session without killing the current (i.e. no way to just refresh).
I have to copy paste the url into chrome each time I start a new session. (not as bad as issue 1.)
Here's a couple of options for you, though neither will provide you with a simple F5 refresh, both are significantly better than copy/pasting the new URL generated by the --inspect flag.
The most optimal solution is installing this extension for Chrome or Opera: https://chrome.google.com/webstore/detail/nim-node-inspector-manage/gnhhdgbaldcilmgcpfddgdbkhjohddkj
This will manage the node inspector for you. Just click the resulting toolbar icon and select "Auto" from the toggle switch. Your browser will then open the Chrome DevTools in inspection mode whenever your node server generates an inspection URL.
If you want to go the low-tech (and more manual) route, or don't want to install a Chrome extension, just open your Chrome to "chrome://inspect", wait a moment, and you'll get a list under Remote Target that will include your Node server. Just click the "inspect" link there, and the DevTools will open with the current URL. The downside of this method is you'll need to reclick that "inspect" link every time your server restarts. It avoids copy/pasting URLs, but still involves manual labor.
It's also significant to note that if you simply update the url of your inspector with the new ID, it will also work.
When you restart node, you'll get something like this:
Debugger listening on ws://127.0.0.1:9222/72c791b7-178f-47e8-93b1-d1be4d5ffe1e
The bit after the port/ is what you want. Replace that code in your inspector's url and it will connect to the latest session.