ExtendScript Debugger 1.1.0 Released
We’re pleased to announce that version 1.1.0 of the ExtendScript Debugger for Visual Studio Code is now available for download.
We’ve come a long way since our initial release in January (for macOS) and February (for Windows). We also released 1.0.1 in April to address some common pain points and ensure compatibility with the new release of VSCode at the time. This is our third Windows and fourth macOS release of the plugin.
So what’s new in this release? Lots of things, all of which are driven by you, the community. If you want to participate, you can find out how to do so below.
Before a debug session is started, the plugin will now ensure that there are no syntax errors in your code which could derail your session. If an error is found, it’ll be displayed in the “Output” tab in Visual Studio Code, and the line where the error was found will be highlighted in your editor.
If you want to edit the color of the highlight, you can! Just add
syntaxErrorHighlightColor to your
launch.json configuration and pick a color you like.
Note that this is of the form
AA represents the opacity from
Speaking of colors
For some users, the default colors for the “Select Target Application” label and the labels used when connected to an app weren’t ideal. So now you can pick the colors!
For the “Select Target Application” text, add a
selectTargetColor key to your
launch.json configuration file and pick a color you like. It defaults to
yellow, but you can pick anything you like:
For the color of the text indicating a connection to a target app, you can add
connectedTargetColor to your
launch.json configuration. It defaults to
white, but again, you can choose what you like.
engineName is no longer required
You can omit the
engineName property in your
launch.json file. If not specified, the debugger will use the default engine of
This version also adds support for the following directives:
Saving the best for last
In the past, the plugin would always activate when you started Visual Studio Code. Now you have more control over when the plugin activates the debugging session.
- Opening a
.jsxfile will activate the plugin
- Starting a debug session directly will also activate the plugin
In these cases, once activated, it won’t deactivate until you restart Visual Studio Code.
You can also control the lifetime of the debugging session so that you can have multiple instances of Visual Studio Code open. You can set this using the
extensionMode setting in your project’s
launch.json file. The default value is
active, which means that the debugger will work as it always has. This allows the debugger to listen for debugging requests from the connected host application, but it also means that the plugin blocks the use of multiple editors.
The other mode is
passive mode — useful if you need to switch between projects frequently. There’s one catch: the host application can no longer initiate a debugging session — you’re the only one who can do so.
Note: Changing this value requires a restart of Visual Studio Code. You’ll probably want to go through your
launch.json files and add this key in to the lot before doing a lot of debugging.
This is not the end
We’re going to continue to iterate on the experience based on your feedback. If you want to participate, we invite you to participate in the user forums, or just ping us on Twitter.
We’re also working through the process of releasing the plugin as open-source so that you and others in the community can directly contribute to enhancing the debugging workflow. Keep an eye on this space for more news in the near future!