Outsource debug configuration to launch.json #287

stephtr · 2018-03-26T11:29:58Z

As often mentioned we need a possibility for debugging tasks if the script to be run is not the standard jest binary. The discussion #271 leaned towards using the DebugConfiguration instead of the pathToJest setting, since one then has more control over the settings used, which simplifies the core extension when including support for CreateReactApps and similar.
With this PR debugging tests should work for most jest and CreateReactApp projects out of the box, in general one has to add a launch configuration named vscode-jest-tests (of type node).

coveralls · 2018-03-26T11:32:58Z

Pull Request Test Coverage Report for Build 338

36 of 53 (67.92%) changed or added relevant lines in 4 files are covered.
63 unchanged lines in 3 files lost coverage.
Overall coverage increased (+3.6%) to 75.23%

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
src/DebugConfigurationProvider.ts	30	31	96.77%
src/JestExt.ts	1	2	50.0%
src/helpers.ts	4	19	21.05%

Files with Coverage Reduction	New Missed Lines	%
src/helpers.ts	3	47.14%
src/extension.ts	4	67.65%
src/JestExt.ts	56	54.23%

Totals
Change from base Build 316:	3.6%
Covered Lines:	570
Relevant Lines:	729

💛 - Coveralls

connectdotz

I like it, it's much cleaner than before!

With the ability to allow people customize the whole debug config, I think you strike a good balance between ease-of-use and flexibility. Now users will have a way to unblock themselves even if our default config is not right! I am glad you can do this without introducing any new variable. Good job!

In addition to address the comments, test, and coverage, we should probably also add some documentation on this new debug feature, including how to override the default config, examples etc.

connectdotz · 2018-03-27T12:30:34Z

src/DebugConfigurationProvider.ts

+    folder: vscode.WorkspaceFolder | undefined,
+    debugConfiguration: vscode.DebugConfiguration,
+    token?: vscode.CancellationToken
+  ) {


I got compile errors with yarn vscode:prepublish:

src/DebugConfigurationProvider.ts(32,74): error TS6133: 'token' is declared but never used.
src/DebugConfigurationProvider.ts(54,5): error TS6133: 'folder' is declared but never used.
src/DebugConfigurationProvider.ts(56,5): error TS6133: 'token' is declared but never used.

Ah thanks, I just saw the warnings and thought that I maybe would use those arguments later. Is fixed.

connectdotz · 2018-03-27T13:50:30Z

src/JestExt.ts

+      await vscode.debug.startDebugging(workspaceFolder, 'vscode-jest-tests')
+    } catch {
+      const debugConfiguration = this.debugConfigurationProvider.provideDebugConfigurations(workspaceFolder)[0]
+      vscode.debug.startDebugging(workspaceFolder, debugConfiguration)


maybe we can capture error here as well and provides some helpful notes to improve the user experience...

Unfortunately the exception throwing behavior of startDebugging isn't documented. The only case in which it throws (a null exception) seems to be if the requested debug configuration isn't present. If starting the debug session fails because of a wrong command in the configuration, vscode displays a more or less detailed error message by itself. The only modification I made was to show a warning message, if it falls back to the default configuration.

connectdotz

added a few more comments, please take a look, thx.

connectdotz · 2018-03-27T19:08:15Z

src/DebugConfigurationProvider.ts

+    }
+    const craCommand = tryGetCRACommand(folder.uri.fsPath).split(' ')
+    if (craCommand.length > 1 || craCommand[0]) {
+      debugConfiguration.runtimeExecutable = '${workspaceFolder}/node_modules/.bin/' + craCommand.shift()


will this work in windows?

On my Windows machine it works, since cmd partially supports using slashes instead of backslashes. By the way, even Microsoft's snippets use slashes.

connectdotz · 2018-03-27T19:09:02Z

src/DebugConfigurationProvider.ts

+      debugConfiguration.args = [...craCommand, ...debugConfiguration.args]
+      debugConfiguration.protocol = 'inspector'
+    } else {
+      debugConfiguration.program = '${workspaceFolder}/node_modules/jest/bin/jest'


same here, will it work in windows?

connectdotz · 2018-03-27T20:09:15Z

package.json

+      {
+        "type": "node",
+        "label": "Debug Jest Tests using vscode-jest"
+      }


if the launch.json already existed, I can't add the test config via the add configuration... button in launch.json right now. Maybe we should add a few configurationSnippets here, such as for default (plain jest) and CRA etc? this will make customization a lot easier... (if you don't see the snippets, might want to name the debugger with a "fake" type...)

Thanks, I added those two snippets. Additionally I separated the code into two different DebugConfigurationProvider, such that it shows up as separate environment when creating the launch.json file.

…into debug-support

stephtr · 2018-03-31T10:56:11Z

package.json

+      {
+        "type": "vscode-jest-tests",
+        "label": "Debug Jest tests using vscode-jest",
+        "languages": ["javascript", "javascriptreact", "typescript", "typescriptreact"],


I would prefer to target only *.test.(j|t)sx? files, but when creating a separate language definition, it seems like I can't base it on the javascript(react)/typescript(react) definitions (including syntax highlighting, IntelliSense, ...).

I think that should be fine for now, if it's a platform limitation...

stephtr · 2018-03-31T12:07:21Z

Should we use the pathToJest and pathToConfig configuration settings when creating a debug configuration or falling back to the default one?
EDIT: At least for pathToJest it wouldn't make sense, since we can't know if we should put it as runtimeExecutable or as (node) program.

In the long run my whish would be to completely remove those settings and instead in function pathToJest(...) (helpers.ts) parse the launch configuration.

connectdotz · 2018-04-01T14:31:51Z

package.json

+      {
+        "type": "node",
+        "label": "Debug Jest tests using vscode-jest"
+      },


don't think we need this dummy one anymore...

I initially thought that it would be necessary when registering a CustomDebugProvider, but it turned out it isn't, I therefore removed it.

connectdotz · 2018-04-01T14:56:24Z

src/JestExt.ts

+      // if that fails, there (probably) isn't any debug configuration (at least no correctly named one)
+      vscode.window.showWarningMessage(
+        'Debug Jest test: No correctly named debug configuration found in launch.json, starting debugging using the default configuration.'
+      )


no need to show warning here as it is the default behavior when the user doesn't have any custom debug config, which is not required.

I added it because of your "maybe we can capture error here as well and provides some helpful notes to improve the user experience…", but see the next comment.

connectdotz · 2018-04-01T15:00:12Z

src/JestExt.ts

+      )
+      // therefore run the test using the default configuration
+      const debugConfiguration = this.snippetDebugConfigurationProvider.provideDebugConfigurations(workspaceFolder)[0]
+      await vscode.debug.startDebugging(workspaceFolder, debugConfiguration)


this startDebugging could fail because the generated config is not correct, for example, the program or runtimeExecutable is wrong... therefore, a good place to catch and instruct users how to examine and customize their debug config.

You mean the "fallback" startDebugging? The issue is that even in such cases startDebugging resolves the Promise successfully (and returns true), after automatically displaying an error message (The attribute "runtimeExecutable" doesn't exist ("/path/to/jest").). One therefore has to initiate a change of the VS Code API or show the user a warning while falling back to the default configuration or just let VS Code show its error message.

connectdotz · 2018-04-01T15:06:27Z

package.json

+            }
+          }
+        ]
+      }


hmm... I like the snippets, but not sure about splitting DebugConfigurationProvider... I think the original single DebugConfigurationProvider is cleaner. These snippets should just work with your original DebugConfigurationProvider registered under "node" type, right? As we discussed earlier, the vscode-jest-tests is really a fake type, our DebugConfigurationProvider is really a node type debug provider, IMHO, better to keep that clarity in code.

Having a single DebugConfigurationProvider would be cleaner, for sure. However we need the vscode-jest-tests provider such that the Debugconfigurationprovider appears as a separate entry when initially creating a launch.json config and selecting the environment.

An alternative would be to merge the providers into one vscode-jest-tests provider, but then dynamically switching the debug adapter has to work (submitting an issue to VS Code should be enough). Additionally since startDebugging needs the name of the debug configuration, one then would have to enter vscode-jest-tests both as name and as type, which is kind of less clean. In that case an option would be to add a new function to vscode for getting all debug configurations of a specific type.

Having a single DebugConfigurationProvider would be cleaner, for sure. However we need the vscode-jest-tests provider such that the Debugconfigurationprovider appears as a separate entry when initially creating a launch.json config and selecting the environment.

you should be able to accomplish this via registering the same DebugConfigurationProvider under both "node" and "vscode-jest-tests" (see comments in extension.ts), without splitting the DebugConfigurationProvider...

But then it doesn't only add the config when creating the launch configuration and selecting Debug Jest tests using vscode-jest, but also when selecting Node.js instead.

true, but not sure why is that a problem...

I found it somehow unesthetic, but since this is only the case when the extension is activated (and therefore jest is in use), I just merged them.

connectdotz

please take a look at the comments and make sure all tests and checks pass, and yarn vscode:prepublish compiles. (note for self: we should add this to the ci script)

connectdotz · 2018-04-04T15:00:02Z

src/extension.ts

+    vscode.debug.registerDebugConfigurationProvider('node', extensionInstance.nodeDebugConfigurationProvider),
+    vscode.debug.registerDebugConfigurationProvider(
+      'vscode-jest-tests',
+      extensionInstance.snippetDebugConfigurationProvider


you could just register the extensionInstance.nodeDebugConfigurationProvider here instead

connectdotz · 2018-04-04T15:03:31Z

src/DebugConfigurationProvider.ts

+  }
+}
+
+export class SnippetDebugConfigurationProvider implements vscode.DebugConfigurationProvider {


by registering DebugConfigurationProvider under both "node" and "vscode-jest-tests" (see comments in extension.ts), we should be able to clean up and move back to the single provider implementation

connectdotz · 2018-04-04T15:05:24Z

src/DebugConfigurationProvider.ts

+      debugConfiguration.args = [...craCommand, ...debugConfiguration.args]
+      debugConfiguration.protocol = 'inspector'
+    } else {
+      debugConfiguration.program = '${workspaceFolder}/node_modules/jest/bin/jest'


…iling test

stephtr · 2018-04-04T17:38:32Z

I updated the PR such that it adds jest.pathToConfig to the generated debug configuration.
Converting jest.pathToJest on the other side isn't that straight forward, since we would have to somehow differentiate between it being a program or a runtimeExecutable and often running the widespread npm test -- isn't enough for debugging (best example is create-react-app).

connectdotz · 2018-04-04T19:33:13Z

I am not quite sure we should add any of these existing settings (pathToJest, pathToConfig...) at the initial implementation... I think people are using them mainly for non-debug mode, which might not be compatible or desirable during debugging, for example, it could be configured with extra params, so

you had to add extra complexity to parse and maybe more, such as the one you mentioned...
it might not even be desired for debugging purpose, so do you create yet another setting for debug or ...?
I am not sure if these can be added to the snippets, otherwise, they will be out of sync, which is not ideal

Giving we really don't know how users will be using this new debug mechanism, I think it is best to keep our initial implementation as simple and clean as possible. So we could release it sooner and start to get real feedbacks ASAP, before committing more time and effort into a direction that we are not quite sure yet...

I really like your initial implementation (from the first review), I thought that was a balanced approach: that we provide a simple minimal config, and users can customize it when the default one doesn't work for them -- simple and intuitive. I thought we were pretty close at review 1, just needed to add the snippets in the package.json, fix the compile error and tests, add a documentation then it should be ready to go...

Other than the doc, I think you already fixed most mentioned above. I suggest we hold off the extra logic outside of that scope, so we can get this out as soon as possible. We can always come back to it later when there are more concrete use cases and actual user feedbacks...

stephtr · 2018-04-04T20:27:44Z

I think people are using them mainly for non-debug mode

Ah ok, I wasn't sure about that and since including pathToConfig was the old behavior when debugging a test (and there even was a test about that) I previously added that functionality.

I think except documentation (beyond this PR) everything should be fixed by now.

connectdotz

I did a clean yarn install and got these errors from yarn vscode:prepublish:

$ yarn vscode:prepublish
yarn run v1.5.1
$ yarn clean-out && tsc -p ./tsconfig.publish.json
$ rimraf ./out
node_modules/jest-editor-support/index.d.ts(173,10): error TS2503: Cannot find namespace 'editor'.
node_modules/jest-editor-support/index.d.ts(178,14): error TS2300: Duplicate identifier 'Snapshot'.
src/SnapshotCodeLens/SnapshotCodeLensProvider.ts(23,23): error TS2554: Expected 1-2 arguments, but got 0.
typings/jest-editor-support.d.ts(28,5): error TS2403: Subsequent variable declarations must have the same type.  Variable 'node' must be of type '{ loc: any; }', but here hastype '{ loc: Node; }'.
typings/jest-editor-support.d.ts(32,5): error TS2687: All declarations of 'content' must have identical modifiers.
typings/jest-editor-support.d.ts(37,9): error TS2300: Duplicate identifier 'Snapshot'.

the jest-editor-support got pulled in is 22.4.3. Does vscode-jest now depends on a not-yet-published jest-editor-support? If that is the case, should we update the package.json to reflect the minimal version?

@seanpoulter or @orta, should we hold off merge until jest release the next version?

[update]
never mind, looks like we have been frozen-in-time at "22.4.0" in yarn.lock... not an issue for this PR then.

connectdotz · 2018-04-04T20:39:57Z

tests/extension.test.ts

+    it('should register a DebugConfigurationProvider', () => {
+      activate(context)
+
+      expect(vscode.debug.registerDebugConfigurationProvider).toBeCalled()


should we also check the registered types here?

I don't think that we would gain much. TypeScript already enforces that we actually register a DebugConfigurationProvider, so in my opinion further specifying the test would be more a sort of burden when changing the behavior than prevent inadvertent changes.

this is to protect others from making unintended changes, such as removed registration for "vscode-jest-tests". Since we don't have any other tests for launch-snippets function, I think these simple tests are the least we can do to safeguard its intended logic.

All tests are creating friction for future changes, and that is not necessary a bad thing...

stephtr · 2018-04-04T23:30:08Z

It should work with the unpublished state of jest-editor-support, however it also works fine with "jest-editor-support": "22.4.0".
Another issue is prettier, which fails on the package.json file after running a fresh restore and committing. Downgrading that package solved that problem, too.

connectdotz · 2018-04-05T01:26:15Z

package.json

+              "type": "node",
+              "name": "vscode-jest-tests",
+              "request": "launch",
+              "program": "${workspaceFolder}/node_modules/jest/bin/jest",


I tested adding these snippets in launch.json, all of them failed to start debugger... looks like the ${workspaceFolder} is not populated. Looking at the example from here, you will most likely need to escape them, for example: "program": "^\"\\${workspaceFolder}/node_modules/jest/bin/jest\""

were you able to run with these snippets?

Ah thank you, since they should have been the same, I actually never tested the snippets from package.json except with my eyes; is fixed.
I also extended the test and readme.

connectdotz · 2018-04-05T01:39:30Z

tests/extension.test.ts

+    it('should register a DebugConfigurationProvider', () => {
+      activate(context)
+
+      expect(vscode.debug.registerDebugConfigurationProvider).toBeCalled()


this is to protect others from making unintended changes, such as removed registration for "vscode-jest-tests". Since we don't have any other tests for launch-snippets function, I think these simple tests are the least we can do to safeguard its intended logic.

All tests are creating friction for future changes, and that is not necessary a bad thing...

connectdotz · 2018-04-05T11:39:29Z

package.json

+              "request": "launch",
+              "program": "^\"\\${workspaceFolder}/node_modules/jest/bin/jest\"",
+              "args": ["--runInBand"],
+              "cwd": "${workspaceFolder}",


hmm... it is still not quite right... here is the one generated by the DebugConfigurationProvider for CRA:

{ "type": "node", "name": "vscode-jest-tests", "request": "launch", "args": ["test", "--env=jsdom", "--runInBand"], "cwd": "${workspaceFolder}", "console": "integratedTerminal", "internalConsoleOptions": "neverOpen", "runtimeExecutable": "${workspaceFolder}/node_modules/.bin/react-scripts", "protocol": "inspector" }

and this is the snippet injected by the vscode Add Configuration:

{ "type": "node", "name": "vscode-jest-tests", "request": "launch", "runtimeExecutable": "${workspaceFolder}/node_modules/.bin/react-scripts", "args": [ "test", "--runInBand" ], "cwd": "", "console": "integratedTerminal", "protocol": "inspector", "internalConsoleOptions": "neverOpen" }

the args are not the same: snippet missing --env=jsdom.

the "cwd" is still empty in snippet

the break point didn't work with the snippet

Oh, I overlooked that since it also works without a cwd. However including the cwd has the advantage of better directing the user if he has to change paths.
Debugging of react-scripts-ts seems to be not working at the moment with newer versions of jest (wmonk/#276).

connectdotz · 2018-04-05T12:13:26Z

README.md

+This plugin provides blueprints for debugging plain Jest setups or projects bootstrapped by `create-react-app`. If those don't match your setup, you can modify the blueprints or create a completely new debug configuration, but keep in mind, that the `type` has to be `node` and that the configuration has to be named `"vscode-jest-tests"`.
+
+Starting with debugging is possible by clicking on the `debug` CodeLense above appendant `it` tests, but you can also debug all tests at once by starting debugging of `"vscode-jest-tests"` within the VS Code Debug Side Bar.
+


great start. thx.

but I thought you might want to call out the following in the doc, otherwise, they might just come back as issues after we launch it:

it won't work if the jest or react-script is not under their default location

it won't detect CRA if it has been ejected, thus a wrong default config will be used and debug will fail.

it won't incorporate any of the pathToJest or pathToConfig settings

document backward incompatibility if any(?) i.e. something used to work but will break under the new scheme. (figure you will know this best)

We do not need to make any code change (it is perfectly all right, sometimes preferable, to make best-effort guesses, provided there is an easy way for users to customize for their specific use), but it will be very helpful to call out the reason, scope, and boundary, then provide guidance for users to help themselves, such as how to generate debug config from launch.json (a link to vscode doc might be good enough), which attribute to update, arguments to add etc.

The review process has gone long enough (sorry), I won't hold off the merge for doc change once the code is ready, but please do consider addressing the above before the launch.

I tried to address that with a separate paragraph. By the way, ejected CRA's were something I didn't thought about, but adding a working snippet was quite simple.

You don't have to feel sorry for that, with each time the quality of this PR got improved.

connectdotz

Thanks @stephtr for putting a lot of effort into this. This is an improvement over the current debug capability and one step closer to where we want to go. 👍

I will merge it when I get home tonight.

connectdotz · 2018-04-06T13:09:15Z

src/DebugConfigurationProvider.ts

+      debugConfiguration.runtimeExecutable = '${workspaceFolder}/node_modules/.bin/' + craCommand.shift()
+      debugConfiguration.args = [...craCommand, ...debugConfiguration.args]
+      debugConfiguration.protocol = 'inspector'
+    } else if (testCommand === 'node scripts/test.js --env=jsdom') {


me: "uh-oh, this is fragile..."

me: "yeah, but that is ok because if it failed developers can just override it in their custom debug config"

me: "ok, then why do we even need this code here? when developers eject CRA, I think they would expect some adjustment to their environment, such as their debug config; on the other hand, it is not so intuitive that their trusted vscode-jest suddenly failed to debug after they changed the test script in package.json."

me: "maybe, but if vscode-jest can work out-of-box in their CRA environment, wouldn't it be "intuitive" to think it should work in ejected env as well? if the testCommand check is too fragile, there are many ways to improve it: we can parse all package.json scripts, parse the testCommand further, go down to the file system to find the binary, just to name a few; and if different CRA version has different test scripts, not a problem, if we can find CRA binary, we can find its version... there is no problem we can't resolve!"

me: "This is what we call the slippery slope... at the beginning, everything looked equally plausible, but as you travel down the path, the effect starts to compound...before you know it, there will be hundreds of lines of code serving CRA variations and yet still insufficient... now just imagine if we have chosen the other path..."

"Just because we can doesn't mean we should" 😏

Should I remove it?
At first my thought was that the DebugConfigurationProvider should be able to handle all snippets from package.json and simply running scripts/test.js --env=jsdom can't be wrong when it is stated as test script.
However as it anyhow fails if one creates the debug configuration and ejects after that and as precautionary measure to inhibit PRs adding support for automatic detection of configuration xyz it could be advantageous to remove the detection for ejected CRA apps.

Should I remove it?

sounds good to me.

Is removed.

reaktivo · 2018-04-09T11:47:55Z

Hi! I was looking for this exactly. But I just noticed this hasn't been published to the Marketplace. Is there any ETA? Would love to take advantage of it!

orta · 2018-04-09T15:06:29Z

Yeah, let's do it

stephtr added 4 commits March 26, 2018 01:37

add initial support for debugConfiguration

f247cdb

add default debugger

51fab82

change to extend node DebugConfigurationProvider, small fixes

59d1b12

update Changelog, small update

ab00e0b

stephtr added enhancement state: in progress labels Mar 26, 2018

stephtr requested review from connectdotz and seanpoulter March 26, 2018 11:37

stephtr mentioned this pull request Mar 26, 2018

Improve debugging of tests #271

Closed

connectdotz requested changes Mar 27, 2018

View reviewed changes

stephtr added 2 commits March 31, 2018 12:37

improve debugging support

099f63d

Merge branch 'master' of https://github.com/jest-community/vscode-jest …

e1fb843

…into debug-support

stephtr commented Mar 31, 2018

View reviewed changes

stephtr added 2 commits March 31, 2018 12:58

revert skipping test

2dea1d9

fix failing test (1)

8eca7f9

connectdotz reviewed Apr 1, 2018

View reviewed changes

clean up

6b578ef

connectdotz requested changes Apr 4, 2018

View reviewed changes

seanpoulter mentioned this pull request Apr 4, 2018

Confirm we can deploy in CI #296

Merged

respect pathToConfig during creation of debug configuration, fix fa…

08e7fa3

…iling test

stephtr added 2 commits April 4, 2018 20:08

cleanup

4761e46

merge DebugConfigurationProviders

8ea837b

stephtr added 2 commits April 4, 2018 21:47

remove transformation of pathToConfig

1c3695b

further cleanup, tests and comments

f7bcd18

connectdotz reviewed Apr 4, 2018

View reviewed changes

fix jest-editor-support version

13eb6c0

connectdotz reviewed Apr 5, 2018

View reviewed changes

stephtr added 2 commits April 5, 2018 10:56

fixed package.json, detailed extension test, extended readme

cc2c991

update readme

899d0fd

connectdotz reviewed Apr 5, 2018

View reviewed changes

stephtr added 5 commits April 5, 2018 15:11

fix snippet, extend documentation

fa92b81

documentation: small clarification

6ff4d78

add debug support for ejected CRA apps

448be53

update changelog

fde6a56

separate and extend tests for DebugConfigurationProvider

c2b8618

stephtr added stage: needs review and removed state: in progress labels Apr 5, 2018

connectdotz approved these changes Apr 6, 2018

View reviewed changes

remove automatic detection of ejected CRA

5496096

connectdotz merged commit 193193c into jest-community:master Apr 7, 2018

stephtr deleted the debug-support branch April 7, 2018 06:40

stephtr mentioned this pull request Apr 7, 2018

Debug CodeLens doesn't use jest.pathToJest #193

Closed

stephtr mentioned this pull request Aug 22, 2018

Make debug button respect custom jest config location #364

Closed

		This plugin provides blueprints for debugging plain Jest setups or projects bootstrapped by `create-react-app`. If those don't match your setup, you can modify the blueprints or create a completely new debug configuration, but keep in mind, that the `type` has to be `node` and that the configuration has to be named `"vscode-jest-tests"`.

		Starting with debugging is possible by clicking on the `debug` CodeLense above appendant `it` tests, but you can also debug all tests at once by starting debugging of `"vscode-jest-tests"` within the VS Code Debug Side Bar.

Outsource debug configuration to launch.json #287

Outsource debug configuration to launch.json #287

Conversation

stephtr commented Mar 26, 2018 • edited Loading

coveralls commented Mar 26, 2018 • edited Loading

Pull Request Test Coverage Report for Build 338

💛 - Coveralls

connectdotz left a comment • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

connectdotz left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

stephtr Mar 31, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

stephtr commented Mar 31, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

stephtr Apr 4, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

connectdotz Apr 4, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

connectdotz left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

connectdotz Apr 4, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

stephtr commented Apr 4, 2018

connectdotz commented Apr 4, 2018 • edited Loading

stephtr commented Apr 4, 2018

connectdotz left a comment • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

stephtr commented Apr 4, 2018 • edited Loading

Choose a reason for hiding this comment

stephtr Apr 5, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

connectdotz Apr 5, 2018 • edited Loading

Choose a reason for hiding this comment

stephtr Apr 5, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

connectdotz left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

reaktivo commented Apr 9, 2018

orta commented Apr 9, 2018

stephtr commented Mar 26, 2018 •

edited

Loading

coveralls commented Mar 26, 2018 •

edited

Loading

connectdotz left a comment •

edited

Loading

stephtr Mar 31, 2018 •

edited

Loading

stephtr commented Mar 31, 2018 •

edited

Loading

stephtr Apr 4, 2018 •

edited

Loading

connectdotz Apr 4, 2018 •

edited

Loading

connectdotz Apr 4, 2018 •

edited

Loading

connectdotz commented Apr 4, 2018 •

edited

Loading

connectdotz left a comment •

edited

Loading

stephtr commented Apr 4, 2018 •

edited

Loading

stephtr Apr 5, 2018 •

edited

Loading

connectdotz Apr 5, 2018 •

edited

Loading

stephtr Apr 5, 2018 •

edited

Loading