I have a Rails and React app that I'm debugging in IntelliJIdea 2022.2.3. I'm using Vite and not webpack.
I've set breakpoints on both ends of the app, but only the Ruby breakpoints are hitting.
Both debug servers are running on the same ip and port. 0.0.0.0:3000.
I tried setting the debug server to the same port (3000) but I'm still encountering the same problem.
In my case, I needed to start the rails server as I normally would (bundle exec rails s) before trying to start the JavaScript debugger in Intellij. Now my JavaScript breakpoints are hitting.
31 October update
I'm encountering the same issue on my work machine my previous fix isn't working.
I noticed in Google's dev tools that, unlike on my personal machine, the javascript dirs are not being loaded.
Personal machine:
work computer
I wonder if I built the app on my personal computer at some point but I haven't on my work machine?
Solution
The discrepancy I noticed between the browsers was related to sourcemaps. I'd forgotten that I added a flag on my local vite.config.ts that I did not add on my work station:
build: {
outDir: 'build',
sourcemap: true,
}
Related
Description
I am following along with the instructions here: https://www.gatsbyjs.org/tutorial/part-one/
When I start the dev server and make a change to src/pages/index.js it is not hot reloaded in my browser.
Steps to Reproduce
Using gatsby-cli:
gatsby new hello-world https://github.com/gatsbyjs/gatsby-starter-hello-world
cd hello-world
gatsby develop
change the text inside of the div in src/pages/index.js
Expected Result
Page would automatically reload with new text.
Actual Result
Page would not change unless a manual refresh was applied in the browser.
Specs
OS: Ubuntu 18.04.3 LTS running in WSL on Windows 10 Pro
Node: 12.12.0
NPM: 6.11.3
Gatsby CLI: 2.8.8
Gatsby: 2.17.6
Browsers: Chrome 77.0.3865.120, IE 11.1006.17134.0, Firefox 70.0
I've tried multiple browsers with the same result so I ran devtools in firefox and examined the console output when I make a change and I see this error:
The connection to http://localhost:8000/__webpack_hmr was interrupted while the page was loading. client.js:88
[HMR] Update check failed: hotDownloadManifest/</request.onreadystatechange#http://localhost:8000/commons.js:42:16
process-update.js:147
Error: Manifest request to /d528b21bff3fd2caa92d.hot-update.json timed out. bootstrap:41
Firefox can’t establish a connection to the server at http://localhost:8000/__webpack_hmr. client.js:88
I've also looked around on github and here and haven't found a solution to my problem. Any ideas on a workaround, solution, or insight into why this might not be working for me would be greatly appreciated!
I was having same problems. Gatsby Develop hot reload was not working whenever I made changes to files, plus, Gatsby Develop was terribly slow to compile code and get the dev server up and running. I found out that if I create my Gatsby project in Linux directory structure instead of Windows, everything works out good and is blazing fast. So my solution was following.
Create your project in /home/<your_username> directory in WSL. Simply go to /home/<your_username> and make a folder there with mkdir; go to that folder and then run Gatsby create my_project command in that folder.
That way your project will reside in Linux directory structure, making everything run smoothly.
I faced the similar scenario today. Below steps made it work however warning message is persistent in the console.
Delete package.lock.json and node_modules folder
Delete the content present inside C:\Users\\AppData\Roaming\npm and npm-cache
Do a npm i.
Im running gatsby develop on windows. After trying many things, including wsl, npm clenaup etc, I realized that my antivirus sophos was blocking the webpack hot reload socket __webpack_hmr.
All I had to do is to disable the antivirus for a while. ( You are free to uninstall it or maybe change to another one ).
hope it works for you ;)
Using
Angular CLI: 1.5.2
Node: 6.10.1
in a Mac OS Sierra,
I have installed several web applications so far. Anytime I do ng serve. All of the applications that I have installed in the past are served.
I guess it's the normal behavior. But I don't need that...
How do I "uninstall" old applications that I don't want anymore to be run?
Edited to answer comments:
I run npm start from one of the applications that get served. Actually, I run it from the only application that I'd like to be started. However, as I said, all of the applications get started up.
Some other facts:
They run under the same port (4200).
The first application I installed runs without any context in the URI. (http://localhost:4200)
The rest of the applications are started under the same 4200 port, but I need to complete the URI with the actual context.
I am running into trouble between two angular-fullstack apps deployed on AWS via same setup and configuration.
It seems that socket.io-client/socket.io.js isn't served properly on one of them despite having same settings.
Seems like it's getting an error 400 (bad request) when trying to get socket.io.js and in turn, it's getting an "io not defined".
I've narrowed it down to this piece of code:
var socketio = require('socket.io')(server, {
serveClient: (config.env === 'production') ? false : true,
path: '/socket.io-client'
});
Seems like if I set serveClient to always be true, it will work because it's always serving to the client.
If this is the case, why do so many resources online set serveClient to false for production? It works for one app but not the other.
EDIT: just deployed on AWS with serveClient: true. Doesn't work. But apparently it works on my local.
EDIT 2: did an npm install for the working app, now it's broken so maybe something is broken with packages.
EDIT 3: did a test on NODE_ENV=production after a grunt build:dist and same issue so it should be issue with one of the packages.
Turns out angular-fullstack's built in grunt file will grab all dependencies in bower.json (via wiredep), which includes google-code-prettify/bin/prettify.min.js since I've installed it.
The minification process is somehow incompatible with the already minified prettify.min.js (never actually had this issue before with other minified files).
So I had to include a regex in the wiredep.target.exclude property to exclude google-code-prettyify/**/.js files and manually include the non-minified /src/prettify.js file.
I had a feeling the google-code-prettify package was causing problems because I remember JSHint complaining about it before.
Hopefully this brings awareness that npm packages can be broken in some intermittent way.
I have moved an existing node.js + express project to VS because I prefer the IDE over JetBrains for now (used VS for years, only peeked into Webstorm).
I used NTVS new project->from existing sources and all files were imported successfully.
Afterwards, I opened the project settings of my project and set the node.exe arguments to bin\www, startup file for express.
When I press F5 (debug) I get the console.log messages I have put into the www and app.js files in the opening command prompt, and it looks like the server is running (cannot confirm, I want to debug if everything is working), but the VS debugger directly exits again, it also does not open any page in the browser I selected for debugging.
My node app actually is a REST webservice, so I want to test different URLs with different parameters.
Also, I cannot access the app on the port I specified, though when I directly start it from node.exe I can, even though the command prompt is still open.
(I have NTVS and WebEssentials installed - some operations take a long long time, but I attribute this to NTVS being still an early version.)
Question: how does the Visual Studio debugger stay connected to the node.js application so I can use breakpoints and use any browser then to connect and test different URLs? (Even a breakpoint put on the console.log that gets printed during startup is not being triggered.)
For everyone who asks receives, and the one who searches finds....
(and yes, I did spend a long time searching and trying before posting here..)
Kind of nice to debug node.js server with VS..
hope this helps someone
Edit: The arguments to node.exe can be hard to read in the image. It must be
--debug=<portno>
that is with two dashes (and not just one) to specify the debug port.
Not so much knowledge on expressjs but with a recent release of NTVS 1.0 Alpha, I did find it supports remote debugging which can be also used to debug nodejs app running locally - anyway haven't tried if it works with nodejs app + expressjs but it should.
I followed the step in this video https://youtu.be/-ir9ZB8lUg4 which is
Run your nodejs with node.exe RemoteDebug.js <your_javascript_file>.
RemoteDebug.js has come when you install NTVS.
In Visual Studio, select Debug > Attach to Process
Select Node.js remote debugging for Transport
Enter localhost:5859 for Qualifier
Click Attach
This will put Visual Studio in debugging mode which you can set a breakpoint, do step-in/step-out, very same experience when you use VS to debug .NET app.
Its pretty straight forward with NTVS, you can download required version for your windows from github here
Once you install NTVS, NodeJS project templates will be added
Now, Goto File->New project -> Basic NodeJS Express 3 application (it will be available in javascript project templates)
Now just goto debug and select Start Debugging, add breakpoints where ever required and you can start debugging
My Node.js application runs correctly locally but it has errors once deployed to Heroku.
I cannot use node-inspector to debug as it requires three ports, and Heroku allows only one port.
https://discussion.heroku.com/t/how-to-debug-node-on-heroku-using-something-like-node-inspector/477/6
I cant use the debugger built into Node.js because I need a CLI to issue debugging commands.
http://nodejs.org/api/debugger.html#debugger_debugger
What is the best strategy for interactively debugging a Node.js application on Heroku?
Found One-Off Dynos, which allow:
Running a console (also known as a REPL shell) to run arbitrary code or inspect the app’s models against the live database. (e.g. rails console, irb, or node)
https://devcenter.heroku.com/articles/one-off-dynos#types-of-one-off-dynos
I didn't have time to test, but this should let me run the built in node debugger.