Newbie question here, it seems... I'm losing my mind. Why is this so hard? I've been programming other languages for years, but I'm relatively new to node and JS. I've read and watched as much as I can find official and unofficial on the web about this and it's either years old or significantly different from my situation, so not very helpful.
I'd really, really appreciate anyone who can understand my (pretty simple, I would have thought!?) specific case and help me get this set up to just work. Possible?
macOS 10.15.6 Catalina.
As I understand it, node comes with the OS. It's Node.js 12.8.1
VS Code 1.48.2
I create a new file, name it abcd.js. VS Code figures out it's javascript. I add some code - read a file of JSON from the disk, make some changes, console.log some stuff (appears under the Output tab). I run it.* All good and works.
Now... Run menu > "Start Debugging". Or, There's a Run/Debug icon in the sidebar that shows a "Run and Debug" button which I click on. Both of those ask me for an environment - I choose Node.js, and the Debug console outputs this:
/usr/local/bin/node path/to/my/file.js
Debugger listening on ws://127.0.0.1:56430/30b0c2aa-278b-4540-94c4-825d30b94f57
For help see https://nodejs.org/en/docs/inspector
And that's it. I have breakpoints, but it doesn't stop on them. Something happens (too quick to see what it is). I don't think it's actually running my code because nothing new shows up under the Output tab.
There's also a note in that sidebar saying "To customize Run and Debug create a launch.json file." I've experimented with that as much as I can, but nothing I do seems to help.
I've been programming for years. I'm used to other languages and IDEs (eg. C, Java, AppleScript, Swift, others), where you open the IDE, write some code, hit run (or debug), it may or may not build a target (depending on the language and environment), but then it runs the code (opens the target app, or runs in the IDE, and allows you to step through the code, breakpoints, etc. in the IDE if debugging). Is JS/node programming radically different from this somehow?
*One theory:
I'm not doing this through any terminal or any browser. Maybe that's the problem...? At some point I installed a "Code Runner" plugin that I believe is what is running my code. It was a while ago, but if I recall correctly maybe I turned to that because I was looking for the experience I've described above, and this plugin gave me that where the "normal" node setup process didn't? Perhaps my problem is that that plugin simplifies RUNNING js scripts so much that my issues with DEBUGGING exist because that plugin allows me to bypass other usual complications with running JS/Node scripts (but doesn't have any debugging functionality of its own)?
My thanks to #ippi for his/her comment with a gif video. Not sure if the following really answers my question, but I'm posting it in case it helps anyone else.
I took some time to clean up my Mac a little, and I completely uninstall VSCode, all its extensions and supporting files and started again.
I re-installed Code from scratch, didn't add any extensions, and then tried what #ippi's video showed.
It still didn't work - I got more or less the same output as in my post, and I'm not sure if it was running the code or not.
I had an urgent deadline to meet so didn't come back to it till now - two days later - and now, it's working.
A couple of things changed in that time though I really don't know what fixed this, if it was either of those or anything else. The two changes I can remember that I've done the last two days are:
Despite my post saying my node was 12.8.1, sometime in the last couple of days it turned into 8.something. I updated it to the latest v12.8.3, and
to meet that deadline I used node inspect myfile.js in Terminal for a bit.
The inspect (mostly) worked to meet my deadline, but still a hassle compared to what's shown in #ippi's video. I definitely wanted to get it working that way.
So… updating node fixed it? Running it in the terminal for a bit fixed it? Something else? I'm at a loss to know what did it. But it's working now.
Thanks again to #ippi for that. It pointed me in a good direction at least - to clean up my install a bit, if nothing else.
Maybe this will help someone else sometime in the future.
It seems the ultimate answer is:
It should just work out of the box (possibly subject to updating node to its latest). If it doesn't then:
The issue most likely isn't that you have to do any fancy configuring or whatnot to make it work.
Instead, most likely something is wrong with your installation and/or OS and you should explore that.
#ippi's video attached in case his/her link ever breaks:
Related
So I've been coding for a while now in school, and I'm having my first introduction into a real working code base at my new job. When it comes to debugging, like if I want to find out what a certain variable is equal to, I'll often just console.log() things out and hope that something useful comes out of it.
It seems really inefficient considering how many moving parts there are in the code. Most of the time, it works eventually, but it feels so barbaric just editing the code over and over and looking at the browser's console until something useful comes out, and it feels like there has to be a better way to debug in a production environment. I am specifically using Ember.JS, but this question would apply to any framework like React or Angular or Node.
There are many tools out there to debug JS, the most "basic" being the debugger in your browser. Some tools go further also, for example VSCode has a slew of extensions that open and control the browsers debugger.
Chrome: https://developers.google.com/web/tools/chrome-devtools/javascript/
Firefox: https://developer.mozilla.org/en-US/docs/Tools/Debugger
Edge: https://learn.microsoft.com/en-us/microsoft-edge/devtools-guide/debugger
Safari also has one in the develop menu but there is no site describing it in detail - it is located in the sources pane
If you use VS Code, you can run Node apps in debug mode then select Node.js.
I'm a student at a University Institute of Technology in France and I'm very new to Firefox add-on development since I discovered it at the beginning of my work placement, a few days ago.
What I have to do is an add-on that allows employees of the company to organize SCRUM-meetings (it deals with agile software development).
For the moment, what I've done looks like this :
http://img11.hostingpics.net/pics/716589MeetingConfigurationPanel.png
The panel allows users to configure the settings of the meeting. I have also added a toolbar with action buttons and a frame in it, so that the meeting can start/be interrupted on the action buttons Onclick event. I have implemented countdown timers for each participants. There is also a "Next Speaker Button" that resets one of the timers when clicked...
And all seems to work fine when I use cfx run, but when I package the extension using cfx xpi... there are errors.
See : http://img11.hostingpics.net/thumbs/mini_585083outputExpected.png
EDIT : Problem with the link. I will update it as soon as possible.
Here is what I have in cfx run mode. All the buttons I declared in the code, along with the frame, are correctly displayed in the toolbar.
But in cfx xpi mode, some of the buttons are apparently "stuck" in what Browser Console refers to as "inner-toolbar" or something like that as I can read when I remove the extension.
That made me wonder if the buttons really were in the toolbar. And they were, according to the Debugger. So I've started thinking that my problem was compatibility with Firefox but I've checked both Firefox version and the em:maxVersion attribute in the install.rdf file that can be found when unpacking the xpi/zip file, and I've change the values so that they match, but it didn't resolve my problem.
I've read as many things as possible on topics related to the problem I'm now facing (including StackOverflow questions) but I have not been able to find a proper way to fix it up to now. Is my problem really different ? I have no idea. I might have done something bad trying to change things as they were intended to, I suppose. But it's unlikely.
And the thing is that I really need to make this add-on works, because it is the only thing I will work on during my work placement.
The solution to my problem may be very simple. Maybe I did something really stupid. I don't know. The only thing I know for sure is that I want to find what's going on, so that I will be able to deliver the first version as soon as possible.
Feel free to ask for more informations if necessary.
Thanks for reading.
Julien B.
(Not technically an answer but SO won't let me comment.) You could try cfx run, then uninstalling the addon from the FF session it opened, then installing the xpi in that same session by doing a file open of the xpi (which will install it). Have a feeling it will run in that case, which means there is a difference between your standard Firefox and the one cfx run opens. There is a difference of course, because cfx run doesn't install all your other add-ons. But it may be running a different Firefox version as well. I mention this because when I run cfx run it always opens the beta version of FF which I downloaded at some point, and I don't know where its picking it up from.
I have a single process node.js application, which I wish to debug with Intellij IDEA 11 32 bits (node.js is 32 bits too).
So, I place an initial breakpoint and run. The debugger stops at the breakpoint, but then it refuses to do any of the following:
step into
go to another breakpoint
pause execution
When I step into, it seems just to run, without stepping through the code. Once running, it ignores any subsequent breakpoints and does not break when I press the pause button.
This issue drives me crazy.
Any ideas on how should I troubleshoot it?
EDIT
More info. After IDEA breaks on the first breakpoint (the only successful time) I try to inspect the variables and am unable to see any. IDEA is stuck on "Collecting data..." The watch window does not work too.
EDIT2
Justed posted an issue to their bug tracking system - http://youtrack.jetbrains.com/issue/IDEA-112925
I've been noticing that IntelliJ's node.js debugger kinda sucks. It's death by 1000 cuts. I love IntelliJ to death, its such a nice IDE. But for node, the debugger has a million different scenarios where breakpoints don't work properly, and another million where it doesn't properly give you access to the in-scope variable values, and another million where it doesn't step properly...
I'm gonna hafta try looking for another tool..
UPDATE 2014-01-13: I've been using IntelliJ's debugger for a while now (having found no other good tool). It seems some of the problems with it are problems with node or v8 itself. Most of the problems I was having have either actually been solved by newer versions of IntelliJ, or by using this workaround:
1. create a file called proxyDebug.js
2. put the following content in it:
require('path/to/the/script/you/want/to/debug.js')
3. point your debugger to that file
Apparently the node.js debugging hooks go buggy at the entrypoint script, so by creating this proxy entrypoint that we don't care at all about, there won't be any weird bugs caused by that in the scripts you do care about. The bugs this workaround fixed were missed breakpoints, predefined variables (exports, module, process, etc) being inaccessible by the debugger, and one or two other things I can't remember.
Last WebStorm version I tried (7.0.3) actually takes ages in collecting data but eventually works. If it seems stuck to you, try to leave it for a minute
I'm very experienced in C/C++/Objective-C and over the last few days have been trying my hand at html/css/JS and am finding it very frustrating.
Time and time and time again I've been caught out as I've a syntax error or undeclared variable due to copying / pasting etc. with the consequence being that the code suddenly stops working then I have to scratch my head and figure out why.
The most painful thing is resorting to sprinkling alerts in the code everything something fails in order to track down the reason. I know there is the new console object for logging but it doesn't seem to work with Komodoedit or jsFiddle? Which is what I've been using.
Is there a way of using these tool, or alternative tools where I can step through the code line by line in a debugger like I can with other languages? Or any tricks for easy detection of problems with the code before executing it in addition to jslint?
[I don't want to use any libraries that might have built-in support for logging etc. as I'm finding they (well JQuery/JQuery mobile is) are drastically slowing down loading times on an iPhone so want to concentrate on pure JS.]
[My target browser is just iOS, but am using Komodoedit with Chrome most of the time and every few hours try it on an iPhone]
Thanks
You need several tools.
First, get yourself a real debugger. I use the one built into Chrome. There's a similar one built into Safari and Firebug available as an add-on for Firefox. This will allow you to set breakpoints and step through your code and see exactly what is happening.
Second, get very used to running your code through jsLint. This will show you many obvious typos and encourage you to write robust code from day one.
Third, start writing in strict mode. This will again prevent some obvious typos and force you to start some good habits.
Fourth, use console.log() when needed. Once you have a debugger, it's output will show in the debug console of the debugger for any page in your browser, including jsFiddle pages. You will have to invoke the debugger on the right frame in jsFiddle and then it will work fine. I use both a regular debugger and console.log() all the time with jsFiddle. It takes a little figuring in jsFiddle and the debugger to find where your own code is to set breakpoints, but once you find it, it's easy to use.
Fifth, javascript is simply not C++. While the syntax will seem quite familiar, the way you do things with anonymous functions and closures and objects and prototypes is very different. As one who programmed in C++ for many, many years before learning javascript, I very much appreciate what I can do now in javascript that was a lot more work in C++, but it took awhile to get my brain into a new mode of thinking. I spent too much time in my first years of javascript development trying to emulate C++ techniques rather than just learning the better way to accomplish the goal in javascript.
Sixth, you will have to change how you write and test code because of the lack of a compiler that finds errors for you. I remember in the days of C++, when I needed to refactor something, I could make a bunch of changes and then let the compiler find all the other places I need to fix the syntax. You can't do that with javascript. When you make mass changes, you can run through jsLint to find some issues and then you literally need to execute every path to make sure everything works. It is a bit of a pain.
Seventh, find a strategy/tools for unit testing. Once a project gets more than a few functions long, you will benefit greatly from building unit tests that you can run anytime you make significant changes. They will both find issues for you in a lot less time than without the unit tests and they will give you the courage to refactor and clean up your code when you see the need for that because you know the unit tests will tell you if everything is working again. It's extra work up front that pays dividends many times over down the road.
Firefox has an add-on called FireBug that is very helpful for debugging CSS/javascript, and yes, it does have the ability to step through a script as well as a command line where you can try out various javascript expressions. I'm pretty sure Chrome has a similar feature.
Here is the article in which you get a list of tools to debug the javascript
advance-javascript-debugging-techniques
Since you're using Chrome, you just need to open the developer console (spanner -> tools -> javascript console, or Ctrl+Alt+J (at a guess)). Instead of sprinkling your code with alerts, use console.log, console.error, and console.info to print to it. All of those are variadic, so you can pass as much to one call as you need.
In addition to this, you can use the console to test and modify parts of your code on the fly, or to just try out a few snippets to see if they work. It's a fully functional REPL that also works with the current document.
In the sources tab of the developer console, you are able to set breakpoints and step through your code, analysing state at each point. This page goes into some detail about it: http://chromedevtools.googlecode.com/svn-history/r421/trunk/tutorials/breapoints/index.html
In the elements tab, you are able to set breakpoints on changes to elements in the DOM, including changes to attributes and child nodes. Right click a node and select the option you want. This will come in handy when debugging code that is asynchronous and plays with the document (eg. AJAX calls inserting new content).
In addition to this, you can scroll to the bottom of the styles pane to the right, and open the event listeners section. Here, you can inspect all the events bound to the selected DOM node.
You can enter debugger (without a semicolon) into your code, and it will open the sources tab at that point so you can inspect the code further. I think this may be Chrome specific.
Finally, tools like JSlint will help you spot undeclared variables as you code, as well as cases where the formatting of your code creates unexpected errors, and some might even go as far as using syntax highlighting to make you notice variables that are undefined.
This is also just scraping the surface. Your editor and JSlint can make your code look right and parse without error, but the browser and its console is where you will spend most of your time.
I have a page that has a byzantine amount of JavaScript code running. In Internet Explorer only, and only version 8, I get a long-script warning that I can reliably reproduce. I suspect it is event handlers triggering themselves in an infinite loop.
The developer tools are limping horribly under the weight of the script running, but I do seem to be able to get the log to tell me what line of script it was executing when I aborted, but it is inevitably some of the deep plumbing of the ExtJS code we use, and I can't tell where it is in my stack of code.
A way of seeing the call stack would work, but preferably I'd like to be able to just break into the debugger when I get the long script warning so I can just step through the stack.
There is a similar question posted, but the answers given were for a not-the-right-tool, or the not terribly helpful advice to eliminate half my code at a time on a binary hunt for the infinite loop. If my code were simple enough that I could do that, it probably wouldn't have gotten the infinite loop in the first place. If I could reproduce the problem in Firebug, I'd probably be a lot happier too.
Here is what I would do:
Go to http://www.microsoft.com/whdc/devtools/debugging/default.mspx and install the Debugging Tools for Windows. You want to run WinDBG when this is installed.
Follow the steps outlined at http://www.microsoft.com/whdc/devtools/debugging/debugstart.mspx#a to setup the symbol server connection and have the symbols automatically downloaded to your local drive (c:\websymbols -- or whatever).
Run IEXPLORE.EXE under WinDBG. The help file should give you assistance in doing this if necessary. You need a couple of commands once you get Internet Explorer running and such. First, go ahead and get that large script going.
Break into the debugger (CTRL-SCROLLLOCK to break).
a. Do a LN to "list nearest" to get the DLL files that are loaded. Hopefully, you'll have JSCRIPT.DLL loaded in memory.
b. Type .reload /f to force the reloading of all of the symbols. This will take a while. Now, after this is done, type LN again and you should see that the proper JSCRIPT.PDB has been downloaded to your system in the symbols directory you setup earlier.
Depending on what you want to do, you may need to restart the debugger, but you can do this: After the initial break on WINDBG load, you can type "sxe ld jscript.dll" and it will break when jscript.dll loads.
This is the tricky part, because once this loads, you don't have the code for jscript.dll, but you have the proper symbols (if they are not loaded, then reload them with .reload /f). You can view the functions available by typing "x!jscript" and you'll get a full list of all of the functions and variables.
Pick one, set a break point, and then you should be able to track what is happening to your script.
If nothing else is accomplished, by using the .reload /f process, you can get the appropriate jscript.pdb files loaded on your system. It's possible you could use these in conjunction with Visual Studio to do additional debugging in that manner, but I'm not so sure how well that will work.
I've run in to this before and have had some luck with enabling the developer tools along with Visual Studio. When an error is encountered the page loading is halted, and I could then load up Visual Studio to see the specific line causing the trouble.
This site has some information on using Visual Studio along with the Internet Explorer debugger: Using Visual Studio to Debug JavaScript in IE