Debugging javascript can be tedious due to the lack of integration between the code editor and the browsers' debugging tools. JsDebuggr aims to make it a tad easier by allowing the user to easily manage breakpoints from the Sublime Text editor.
The way JsDebuggr works is by inserting the debugger
keyword at each breakpoint when the document is saved. Since this happens only when the document is saved, the user never sees the breakpoints. They just work :D
Of course, the js engine executing the code needs to support the debugger
keyword and debugging needs to be enabled (in Chrome, for instance, the developer console must be open).
Hey this thing is purty neat. Check it out:
- Add and remove individual breakpoints, or remove all breakpoints at once.
- Enable and disable individual breakpoints or all at once.
- Create conditional breakpoints.
- Breakpoints stay in your document, so you can save and close, and later open it and they will still be there.
- The underlying
debugger
stuff is hidden away where you don't have to look at it (and where it won't annoy your linter, who is already quite mad at me anyway). - Breakpoints work in injected or eval'd code. It is often difficult or not possible to add breakpoints in browser dev tools.
- Breakpoints stick to the line you want them to stick to and move when your code does. In browser dev tools, the breakpoints are absolutely assigned to a line number, so if you add or remove lines in your source, next time your refresh the page, the breakpoints from the browser dev tool will annoyingly be off by n number of lines.
As in any wonderful relationship, there are down sides :(
- You can't add or remove breakpoints during runtime. This can be frustrating when you want to turn off a breakpoint, but you don't want to reload the page (maybe you have a complex state you don't want to lose).
- You have to save the document everytime you add, remove, or update a breakpoint since (I don't think) Sublime Text's plugin API won't allow a plugin to save the document for you.
This plugin is not a developer console replacement. You will still need to open firebug or chrome dev tools or enable debugging in node.js, and use those tools to examine the stack, vars, etc. This plugin doesn't connect to those dev tools in any way. For that, you want a more advanced solution like Sublime Web Inspector.
Clone the repo to your Sublime Text Packages folder
. Something like this should work: C:\Users\User\AppData\Roaming\Sublime Text 3\Packages\JsDebuggr\
I will add JsDebuggr to Package Control once I am more confident that it works without any show stopping or code eating bugs.
Simply add a breakpoint and then save the document. This will add the debugger
keywords behind the scenes, so when your document is loaded in a js engine that supports it, it will break at that point. Note that you must save the document manually to make the breakpoints active.
The default key bindings are as follows:
ctrl + f10
- add or remove breakpointctrl + shift + f10
- disable or enable breakpointalt + f10
- add a conditional breakpoint
Additionally, the right click menu allows for:
- add/remove breakpoint
- add conditional breakpoint
- edit conditional breakpoint
- remove all
- enable/disable breakpoint
- enable all
- disable all
JsDebuggr has only a handful of settings, and they're not very useful. They can be found in the JsDebuggr.sublime-settings
file.
file_type_list
is an array of file extensions that should be enabled for scanning and tracking. The default value is["html", "htm", "js"]
.autoscan_on_load
is a bool that indicates if a newly loaded doc should be scanned for existing debugger keywords, and those keywords be transformed into breakpointsbreakpoint_color
,conditional_breakpoint_color
, anddisabled_breakpoint_color
determine the color of the gutter icon for breakpoints of various types.verbose
right now JsDebuggr dumps a lot into the console for troubleshooting. Setting this to false will prevent that behavior. Once it is in a better state, this will default to false.
- disable context menu options when they are not valid (for instance, "Edit Conditional Breakpoint" should only be visible when a conditional breakpoint is selected).
- save and load of multiple breakpoint sets
- persist disabled breakpoints through document close/open (regular and contional breakpoints persist, but disabled breakpoints do not)
- multiple selection support