ExtendScript Debugger 1.1.0 Released

ExtendScript Debugger 1.1.0 in action

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.

Syntax checking

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.

Line with syntax error highlighted

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.

For example:

"syntaxErrorHighlightColor": "#F97E723A"

Note that this is of the form #RRGGBBAA where AA represents the opacity from 00(transparent) to FF(opaque).

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:

"selectTargetColor": "yellow"

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.

I’m using “black” as for “selectTargetColor” in this example.

For example:

"connectedTargetColor": "black"

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 main instead.

Directive support

This version also adds support for the following directives:

  • #target
  • #targetengine

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 .js or .jsx file 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!