microsoft / vscode-debugadapter-node

Debug adapter protocol and implementation for VS Code.

VS Code Debug Protocol and Debug Adapter

Debug adapter protocol and default implementation for VS Code.

This repository contains the code for the following npm modules:

• vscode-debugprotocol: Npm module with declarations for the json-based VS Code debug protocol.
  
• vscode-debugadapter: Npm module to implement a VS Code debug adapter using Node.js as a runtime.
  
• vscode-debugadapter-testsupport: Npm module with support classes for testing VS Code debug adapters.
  

License

MIT

===

This project has adopted the Microsoft Open Source Code of Conduct. For more information see the Code of Conduct FAQ or contact [email protected] with any additional questions or comments.

vscode-debugadapter-node's Issues

Debug protocol: standardise the value set for the 'kind' attribute of Variable

follow-up work from #30
(some details can be found there).

Change testsupport to not use child processes

I have tests for my debugadapter for quite some time now, but spawning the debuadapter for every test has only proven to cause problems:

• It is extremely slow, especially on Windows
• Constantly there are issues with timeouts or hanging that only happen in CI. I have to test against 3 PHP versions x 3 XDebug versions and these random failures mean that at least one job always fails, breaking the build. I never had a stable green build ever since I added tests.
• It is impossible to generate code coverage with istanbul/nyc. Even though nyc claims to work with child processes, my debug adapter file is getting 0% coverage in the report.

This could be made much easier. In the mock debug extension, the main file declares a class and then directly calls run() to run the adapter. This could be changed to

export class MyDebugSession extends DebugSession {
  // ...
}
if (require.main === module) {
  DebugSession.run(MyDebugSession);
}

making it only run when the file was the entry point of the application. Then in the tests, we could just import the session, instantiate it and call the methods directly on it, providing object literals as parameters that conform to the debug protocol interfaces. sendResponse() and sendErrorResponse() can easily be stubbed by sinon, asserting that they have been called with specific parameters.

That way, we only test the actual unit under test, our own debug adapter, and trust vscode-debugadapter-node to function correctly. Currently we basically test the whole stack including vscode-debugadapter-node's protocol parsing, method dispatching and response handling, which is not a good practice.

add an "origin" attribute to the debug protocol's "Source" type

VSCode shows the description "internal module" in the editor's title for contents that doesn't come from a file but is returned from a debug adapter. For content that is inlined into a source map the description "internal module" is misleading.

I propose that we add an attribute "origin" to the debug protocol's "Source" type.

@isidorn what do you think? Is "origin" a good name or do you have a better suggestion?

Create a (json) schema for the VS Code Debug Protocol

Instead of keeping the specification of the VS Code Debug Protocol as a TypeScript d.ts file we should introduce a language neutral json schema for it.

An example for this is the Chrome Debugger Protocol schema:
https://cs.chromium.org/chromium/src/third_party/WebKit/Source/platform/v8_inspector/js_protocol.json (they are not using a json schema but their own invention).

Ideally we could generate client and server libraries for different implementation languages for this.
So the debugProtocol.d.ts could be the result of this.

For a similar discussion about the Language Protocol see: microsoft/language-server-protocol#25

Some exported values are not making it accross module boundaries

Hi,
I've notice when debugging my Typescript with vscode some complex/compounds objects that are being exported from one module are either: not the same object that "arrives" in the importer, or its fields are being reset back to their defualt values.

I'm exporting the value, like so:

export const target = (() => getMergedConfig().target)();

and importing it like this:

import {target} from './../lib/ts-config-loader';

However, in the module that is receiving target, the debugger can't see target. I can't create a watch value and I can't query it in the console. When I access fields from target, they are usually at their defualt values.

If I use node-debug and chrome debugger, everything works as expect and the code also runs correctly.

Debug protocol extension: set next statement

To be able to use the debug protocol in other IDEs (Visual Studio, Xamarin Studio) or VS Code in the future we should think about how the debug protocol should support set next statement.

To make this work well with VS without an impedance mismatch, we need this to be two different requests - one to find the code locations associated with a source line and another to set next statement to one of those. Something like:

"findCodeLocations"
    Request:
        source: Source;
        line: number;
        column?: number;
    Response:
       Array of code locations (ex: addresses)

"setNextStatement"
    Request:         
      threadId: number;
      codeLocation: CodeLocation;

We also likely want a new capability.

Setting Variable in UI that fails will attempt to set bad value again if user clicks elsewhere

I'm in the middle of implementing this cool feature for the PowerShell extension. I could be doing something wrong but what I notice is if I try to set a value to a variable that is readonly, I get the error message in the UI as expected. But when I try to click somewhere else to dismiss the error UI, VSCode sends the setVariableRequest again, so we wind up in a bit of a vicious loop.

I can understand why you'd want to apply the value when use clicks away but perhaps you shouldn't do that if A) the last attempt was an error and B) the current value has not changed from the value used during the previous failed attempt.

However, in the case of a readonly/constant variable, no amount of futzing with the value will. I see that pressing Esc helps in this case but things get out of sync a bit until I step again in the debugger:

You can see the extensions says no - you can't set an int to 42a and you get an error message to that effect. So I press Esc and things look good. The value goes back to 42 until I close and re-open the Autos container.

Debug Protocol: support for intellisense

similar to the 'completion' suite of the language server protocol: https://github.com/Microsoft/language-server-protocol/blob/master/protocol.md#completion-request

List debugprotocol in the 'typings' registry?

Since vscode-debugprotocol is really a .d.ts, it might make sense to list it in 'typings' (used to be tsd). Just a suggestion. https://github.com/typings/typings

Debug protocol extension: support paging for 'variables' request

To be able to use the debug protocol in other IDEs (Visual Studio, Xamarin Studio) or VS Code in the future we should think about how the debug protocol should support for paging children in 'variables' requests.

I would suggest we follow the same approach as in microsoft/vscode@563c020

Add a mime type attribute to the response of the source request

see microsoft/vscode#8182 for details

Support debugger URI path style

XDebug wants all file paths as file:// URI. I looked at the source code and saw that there is code implemented for this, but the property debuggerPathsAreUris is private, by default set to false and has no constructor property - in opposite to debuggerLinesAndColumnsStartAt1.

Debug protocol extension: editing variables

To be able to use the debug protocol in other IDEs (Visual Studio, Xamarin Studio) or VS Code in the future we should think about how the debug protocol should support editing variables. Something like:

export interface SetValueRequest extends Request {
    variablesReference: number;
    newValue: string;
}

Note that I would expect this to be able to fail with a message (ex: the new value has a syntax error), but I think a normal error response could be used there.

Seems like we might also want some sort of 'isEditable' attribute on evaluate results to let the IDE know if editing should be allowed.

Debug type case sensitive

While implementing a debug adapter, we need to declare what debug type it is like

"contributes": {
        "debuggers": [
            {
                "type": "Ruby",
                "label": "Ruby Debugger",
                                ...

It works perfectly when user set type as Ruby in their launch config while it breaks when users type ruby with the lowercase r. It somewhat confuses users of my tiny plugin.

Meanwhile if I attempt to change the type value from Ruby to ruby, my extension will never be backwards-compatible. Is there any solid reason that we make it Case-Sensitive or is there any workaround? You know that we are likely to name our debugger as the language name, Python for any python related code, PowerShell for ps code, but users might get blocked if they type python or Powershell.

Debugger fails when I hover over a variable (and at times even before hitting the first breakpoint)

Environment: MacOSX 10.10.5 (Yosemite, not El Capitan). Latest VS Code 0.10.11
Debugging Golang via Delv. However the error message does not seem to be from delv.
Go plugin is the current most popular plugin lukehoban.Go

I am able to use Delve directly for debugging.

Wrong typing for Capabilities

In https://github.com/Microsoft/vscode-debugadapter-node/blob/master/protocol/src/debugProtocol.ts#L503:

exceptionBreakpointFilters?: [
    {
        /** The internal ID of the filter. This value is passed to the setExceptionBreakpoints request. */
        filter: string,
        /** The name of the filter. This will be shown in the UI. */
        label: string,
        /** Initial value of the filter. If not specified a value 'false' is assumed. */
        default?: boolean
    }
]

should be

exceptionBreakpointFilters?: {
    /** The internal ID of the filter. This value is passed to the setExceptionBreakpoints request. */
    filter: string,
    /** The name of the filter. This will be shown in the UI. */
    label: string,
    /** Initial value of the filter. If not specified a value 'false' is
assumed. */
    default?: boolean
}[]

or

exceptionBreakpointFilters?: Array<{
    /** The internal ID of the filter. This value is passed to the setExceptionBreakpoints request. */
    filter: string,
    /** The name of the filter. This will be shown in the UI. */
    label: string,
    /** Initial value of the filter. If not specified a value 'false' is
assumed. */
    default?: boolean
}>

otherwise you are only applying the type constraint to the first element in the array. You can see the problem when trying to set it to an empty array:

Type 'undefined[]' is not assignable to type '[{ filter: string; label: string; }]'. Property '0' is missing in type 'undefined[]'.

I would actually recommend to define another interface ExceptionFilter

Debug protocol extension: support obtaining the full value for a string variable

To be able to use the debug protocol in other IDEs (Visual Studio, Xamarin Studio) or possibly VS Code in the future we should think about how the debug protocol should support large strings. Currently the debug adapter can clip strings, but if the UI has a facility for showing the full string (in VS this is done through a 'string visualizer' see image) the debug protocol doesn't support a way of obtaining this 'raw' string.

Suggestion:

• Add new 'rawString' request which takes a variableReference as input and returns the string.
• Add a flag to the Variable interface to indicate that the rawString is available.

Debug Protocol: Support step-into-specifc

In order to use the vscode protocol in vs and xamerin, we'd need to support Step-into-specific. This is a feature that allows the user to select which call a step in should occur on when there are multiple calls on a line. Users primarily use this when there are a lot of calls on a single line (either implicit or otherwise).

This is a trivial example:

The apis around this would require the debug adapter to provide a list of calls at a specific line. The user would then select one. The target call would then be placed as an optional field in the step-in request.

If a request method returns a promise that gets rejected, send error response

Currently in dispatchRequest you catch synchronous exceptions and automatically send an error response. As I converted all my methods to async functions (and used promises before anyway) this doesn't work in 99% of the cases, as the methods return a promise. I have to wrap every single method in a try/catch block with sendErrorResponse. It would be nice if dispatchRequest could check if the return value is a promise, and if yes, attach a catch listener to it that also sends an error response. (I would just override dispatchRequest to do it on my own, but the return value is swallowed).

Displaying an error message immediately at startup?

Hey guys,

Is there a way to return a message to the user at debug adapter startup so that they don't just see "Debug adapter has terminated unexpectedly"? There's a case where my debug adapter can't be started yet because my service hasn't finished initializing and I want to show a helpful message that makes it clear why debugging couldn't start.

I tried returning an ErrorResponse to message id 0 but it didn't show up in the UI. Is there another message I can use for that?

Thanks!

Add a way to detect what version of the adapter protocol is supported

Currently, there's no way for a debug adapter to determine whether or not a user is using a sufficiently up-to-date version of VS Code to support features that depend on protocol changes or additions. Adding a way to check the protocol's version (e.g. passing the version during the initialize step) allows debuggers to light up new features gracefully as soon as the adapter supports them, without providing a broken experience for users that are not fully up to date.

Remote debugging of node.js in a docker container

First, I want to thank Microsoft for VSCode. It's truly wonderful to use both this powerful editor and TypeScript together, with everything else the open-source community has to offer.

I have issues with debugging when node.js MUST run in a docker container, in order to connect to other containers and so forth. I know that remote debugging isn't supported yet, but it may actually be easy to fix a couple of obstacles that I encountered, since I was able to find work arounds myself. The major issues with debugging node.js in a locally hosted docker container that I saw were as follows:

1. VSCode obtains and then monitors the node process PID, then shuts down the debugger after several seconds if it notices that the PID isn't actually running. This is not idea, when the process is running in a separate container, so it would be nice if that requirement were optional.

2. VSCode uses absolute paths to the source code. This is not ideal if the source code's location on the host is different than that of the docker container. Containers use different mappings all the time, so relative path would be a much better approach.

I was able to work around the first issue by creating a small proxy that is run on the host, along side VSCode. All the proxy does if forward packets back and fort between two ports, for the most part. But when it sees the PID packet being returned from node.js, it substitutes its own PID. This is in order to prevent VSCode from exiting prematurely. The source for the proxy is here, by the way:

https://gist.github.com/djabraham/19af4ea435dd94418af0

I was able to work around the second issue by bind-mounting the source code into the same path on the host as within the docker container. This could be a major pain for users on OSX, because it required downloading and compiling bind, along with other utilities, and performing the mount. And while it works on a MAC; however, I am not sure how to do something similar on Windows.

Thanks again for all the great tooling!

Debug protocol extension: 'icon' attributes on expression evalution results

To be able to use the debug protocol in other IDEs (Visual Studio, Xamarin Studio) or VS Code in the future we should think about how the debug protocol should support attributes on an expression to indicate what kind of item a child item is for example:

We have attributes for:

• Is Static
• Is error
• Is property
• Is method
• Is event
• Is class
• Is constant
• Accessibility (private, protected, sealed)

'origin' in SourceResponse vs Source

It might make sense for the 'origin' property to be returned as part of the SourceResponse vs the Source object on a StackFrame, since the only place it's currently surfaced is when vscode requests the source from the debug adapter. Also, since the Source is used other places where the origin won't be applicable.

But if we want to show the origin in the callstack before a source request happens, it should stay on the Source.

Debug Protocol: Support sending custom properties to a debug adapter while debugging

We propose adding a mechanism for passing simple untyped properties to a debug adapter, which can take action or not depending on its understanding of those properties. Unlike values specified in launch.json, these properties can be changed during a debugging session based on UI actions.

Examples of properties:

• "EnableJMC" - indicate whether Just My Code should be turned on, which might (e.g.) prevent the debugger from showing framework code on the call stack
• "Radix" - indicate the number base for evaluated values returned by the debugger (e.g.) "10" or "16"

Proposed protocol changes:

export interface Capabilities {
    // ...
    /** The debug adapter supports the setDebuggerProperty request */
    supportsSetDebuggerPropertyRequest?: boolean;
    // ...
}

/** SetDebuggerProperty request; value of command field is 'setDebuggerProperty'.  The request sets a debugger-specific property. */
export interface SetDebuggerPropertyRequest extends Request {
    arguments: SetDebuggerPropertyArguments;
}

/** Arguments for 'setDebuggerProperty' request. */
export interface SetDebuggerPropertyArguments {
    /** Name of the property to set */
    name: string;
    /** Value to which the property should be set */
    value?: string;
}

/** Response to 'setDebuggerProperty' request.  This is just an acknowledgement, so no body field is required. */
export interface SetDebuggerPropertyResponse extends Response {
}

@jacdavis @gregg-miskelly @richardstanton @tzwlai

Debug Protocol: add a `ContinuedEvent`

for details see microsoft/vscode#9149

Make _isServer protected

In server mode, I want to log stuff to the debug console with console.log. I recently found out that in non-server mode, this breaks the VS Code protocol - because in server mode, the adapter is talking over a socket, while in non-server mode, it is talking over stdin/out. So I need to check at runtime if the session is in server mode or not (there is a setter for it anyway).

Create a (json) schema for the VS Code Debug Protocol

Instead of keeping the specification of the VS Code Debug Protocol as a TypeScript d.ts file we should introduce a language neutral json schema for it.

An example for this is the Chrome Debugger Protocol schema:
https://cs.chromium.org/chromium/src/third_party/WebKit/Source/platform/v8_inspector/js_protocol.json
(they are not using a json schema but their own invention).

Ideally we could generate client and server libraries for different implementation languages for this.
So the https://github.com/Microsoft/vscode-debugadapter-node/blob/master/protocol/src/debugProtocol.ts could be a result of this.

For a similar discussion about the Language Protocol see: microsoft/language-server-protocol#25

Debug Protocol: support for launching debuggee in VS Code terminal

Release 1.8.0

Now that VS Code 1.0 is out I would like to publish my release that I have ready for almost a month now. It currently depends on the 1.8 pre-versions (noDebug attribute, defaultTimeout attribute, ...) though, and I would like to publish with a dependency on the stable versions. Any ETA for 1.8?

Debug Protocol: support 'restart frame'

Add protocol support for a restartFrame request.
A single argument frameId specifies the frame to restart.

Debug Protocol: Support for missing fields in thread event

In order to use the vscode protocol in vs, we'd need to have a second runtime specific identifier (matches the managed thread id in vs) as well as thread category (optional string) and optional name (Main Thread, GC Thread, none etc...)
I think these could easily all be optional string arguments on the thread event. However, a thread name may change dynamically (for instance in native, a thread's name is changed by throwing a specific exception code).

add ThreadEvent class to debugSession.ts

From @weinand on December 16, 2015 13:1

@lukehoban I've created this bug for you.

Copied from original issue: microsoft/vscode-mock-debug#3

support conditional breakpoints

extend the debug protocol to support conditional breakpoints (and other additional breakpoint attributes).

Debug Protocol: Allow passing back a `path` AND a `sourceReference`

When using inlined sources from the sourceMap, the Node adapter passes a sourceReference, and keeps the mapped path in adapterData. I'd really like to surface this to the user, but if 'path' is set, then vscode tries to read the file off disk, fails, and shows an error message in the editor pane. When users have a weird source config, it would make it easier to find out what the SourceMap claims the path is, ie by hovering over the callstack frame or editor title, which makes it easier to find the fix. Putting it in the 'name' field doesn't look right as-is.

I think it would make sense for vscode to test whether the path exists, and if not, do a sourceRequest with the sourceReference.

But, maybe it's confusing to show a 'path' when that path doesn't exist. And in some cases it will be a URL or something which isn't a valid path.

Thoughts?

Question regarding packaging

Hi - I am trying to figure out how to package my debug adapter implementation. My debug adapter is an executable and hence there are separate binaries for each major platform. What's the recommended way of packaging in this case?

Apologies if this isn't the right place for asking this question - please redirect me.

Thanks and Regards

LaunchRequestArguments should include noDebug attribute

debugProtocol.ts:197
As this is shared for all debug adapters and comes from VS Code, debug adapters should not need to add this to their interface if they extend the protocol interface

Debug protocol documentation

Hi, I am looking for the protocol documentation so that I can implement a debug adapter in C.

Debugger crashes in server mode without error messages / stack on Node 5.x

When I try to get at this by launching via "Debug adapter" (in server mode), first everything seems fine: status bar turns orange, I launch from cmd with extensionDevelopmentPath specified. When I hit F5 inside the extension development host, the debugger just _crashes_, which means the status bar is blue again, while the debug adapter in the "extension development host" is still running. I have "break on uncaught exceptions" activated, so this should not happen under any circumstances. This is the debugger console output:

Debugger listening on port 16630
 waiting for debug protocol on port 4711
>> accepted connection from client


-> initializeRequest
{ type: 'request',
  seq: 1,
  command: 'initialize',
  arguments: { adapterID: 'php', linesStartAt1: true, pathFormat: 'path' } }


<- initializeResponse
Response {
  seq: 0,
  type: 'response',
  request_seq: 1,
  command: 'initialize',
  success: true }


-> launchRequest
{ type: 'request',
  seq: 2,
  command: 'launch',
  arguments:
   { name: 'Listen for XDebug',
     type: 'php',
     request: 'launch',
     port: 9000,
     debugServer: 4711,
     outDir: null,
     address: 'localhost',
     program: null,
     stopOnEntry: false,
     args: null,
     cwd: 'c:\\Users\\felix\\git\\github\\vscode-php-debug\\testproject',
     runtimeExecutable: null,
     runtimeArgs: null } }


<- launchResponse
Response {
  seq: 0,
  type: 'response',
  request_seq: 2,
  command: 'launch',
  success: true }
New XDebug Connection #1

And then it just crashes (VS Code status bar blue again).
No error, no stack trace, nothing.
I am completely unable to investigate the issue because I cannot step through my code, and I don't know where I can see what is causing this. Is there any logfile that I can look at?

Support 'id' property in Breakpoint constructor

The DebugProtocol.Breakpoint interface has an id property, it would be nice if I could set it using the constructor of the Breakpoint class. Right now if I want to set the id, I have to write something like this:

    let breakpoint = new Breakpoint(verified, line);
    (<DebugProtocol.Breakpoint>breakpoint).id = breakpointId;

Feature negotiation between debug adapters and Code

From @felixfbecker on December 29, 2015 23:17

Some debug adapters may not support all features (that you add in the future). For example, php-debug does not support breaking on caught exceptions. There needs to be a way to notify VS Code that this feature should be disabled (greyed out) for the user. (low priority)

Copied from original issue: microsoft/vscode#1699

Why is JSON RPC not used?

Just wondering why the language server protocol uses JSON RPC, but the debug protocol uses structures like these

/** Base class of requests, responses, and events. */
    interface ProtocolMessage {
        /** Sequence number */
        seq: number;
        /** One of "request", "response", or "event" */
        type: string;
    }
    /** Client-initiated request */
    interface Request extends ProtocolMessage {
        /** The command to execute */
        command: string;
        /** Object containing arguments for the command */
        arguments?: any;
    }

that is basically JSON RPC, just with different property names (seq -> id, arguments -> params, command -> method). It would make implementations of debug adapters in other languages much easier because many languages have some kind of JSON RPC implementation.

How can a debug adapter know if VS Code has finished sending all breakpoints?

setBreakpointsRequest gets called for every source file that has break points. I have to register them to the debugger engine and then issue a run command to the debugger engine. But if setBreakpointsRequest is called multiple times, how can I ever know if that was it or if there are still more break points in more source files coming? How can I know when to tell the debugger engine to actually run the program?

Debug protocol extension: support full text ranges

To be able to use the debug protocol in other IDEs (Visual Studio, Xamarin Studio) or VS Code in the future we should think about how the debug protocol should support compilers/runtimes that include full text ranges (start line, start column, end line, end column) in their debug info.

Suggestions: StackFrame, SourceBreakpoint and Breakpoint interfaces should add 'endLine?: number' and 'endColumn?: number'.

Debug protocol extension: modules window

To be able to use the debug protocol in other IDEs (Visual Studio, Xamarin Studio) or VS Code in the future we should think about how the debug protocol should support a modules window.

VS requires module load/unload events to keep its modules window updated, so I would likely suggest we do the same.

VS bakes in knowledge of all the module properties, so while I might suggest having some sort of 'additional properties' that windows displays, we probably want to have defined names for allow of the following properties so that we can cleanly map them onto VS interfaces. Here are the properties:

id: string
name : string
path: string
isOptimized?: bool
isUseCode?: bool
version? : string
symbol status?: string
symbolFilePath?: string
dateTimeStamp?: string (or maybe this should be a date time?)
addressRange?: not sure what type this should be. In VS this needs to be a UINT64 for the start, and a UINT32 for the size.

In addition, we also provide:

1. Symbol search details (this feels like it shouldn't be part of the event, but should rather be a request)
2. A command to load symbols for a specific module

Debug Protocol: Data Breakpoints

In order to the vscode protocol in VS, we would need support for data breakpoints in the protocol. These are currently a native only feature, but one of the most commonly requested features in managed (requiring clr changes).

The minimum fields would be

1. threadid the databp applies to (optional)
2. a data expression to be evaluated to an address
3. The size of number of elements (limited by hardware, but other runtimes may not have this limitation.

The VS ui only supports data breakpoints when a value changes, but we do get asked for read data breakpoints sometimes.

Debug Protocol: breakpoint hit counts

In order to use the vscode protocol in vs and xamerin, we would need the ability to support breakpoint hit counts. This is similar to a breakpoint condition, but allows the debug engine to control the number of times a bp would be hit. We currently support four types of hit counts:
public enum enum_BP_PASSCOUNT_STYLE {
BP_PASSCOUNT_NONE = 0x0000,
BP_PASSCOUNT_EQUAL = 0x0001,
BP_PASSCOUNT_EQUAL_OR_GREATER = 0x0002,
BP_PASSCOUNT_MOD = 0x0003
};

These are:

1. No hit count (default)
2. hit count equal to a value
3. hit count greater than or equal to a value
4. hit count is a multiple of a hit count.

The VS interface for this provides the user's value (number of interest) and a type:
https://msdn.microsoft.com/en-us/library/bb146656.aspx

Debug protocol extension: support for 'type' in expression evaluation result

To be able to use the debug protocol in other IDEs (Visual Studio, Xamarin Studio) we should think about how the debug protocol should support expression evaluation windows that have a 'Type' column.

Suggestion:

• 'Variable' interface gets a new 'type?: string' member
• InitializeRequestArguments adds a new 'showsVariableTypes?: boolean'

Follow semver

<nitpicking>

You recently added conditional breakpoints, which is a new, backwards compatible feature, and therefor should see a minor version bump, not a patch. Deprecating API in a patch release is very weird.

Given a version number MAJOR.MINOR.PATCH, increment the:

MAJOR version when you make incompatible API changes,
MINOR version when you add functionality in a backwards-compatible manner, and
PATCH version when you make backwards-compatible bug fixes.

</nitpicking>

Add option to assertStoppedLocation() and hitBreakpoint() to compare paths case-insensitive

XDebug does not "persist" the capitalization of the drive letter on Windows, which makes all my tests fail:

  2) PHP Debug Adapter breakpoints line breakpoints should stop on a breakpoint:
      AssertionError: stopped location: path mismatch
      + expected - actual
      -C:\Users\felix\git\opensource\vscode-php-debug\testproject\hello_world.php
      +c:\Users\felix\git\opensource\vscode-php-debug\testproject\hello_world.php

Technically it is the exact same path though. Please make ignore case on Windows by default and/or add an option to ignore the case.