add playground command

[m90]

Enables the user to upload the current file or selection to the go playground using package goplay.

This would solve #1211

[msftclas]

All CLA requirements met.

[ramya-rao-a]

@m90 This is so cool :)

I have left a few comments, please take a look

[ramya-rao-a]

why not make the call to goplay directly from here instead of going through the GoplayUploader ?

[m90]

Seeing that it's a common pattern in this extension to make multiple tools available (although maybe not necessarily in that case) for the same task, I thought it'd be a good idea to separate the editor part of the command from the actual uploading. Also, it makes writing tests a lot easier. I think I'd like to keep it that way if possible.

[ramya-rao-a]

Show an error message if there is no active editor

[ramya-rao-a]

In the absence of the goplay tool, we end up in the else block here with the error message write EPIPE. This is because we are passing the code via stdin and the connection gets closed due to ENOENT error

There are 2 ways to fix this

1. Check BINARY_LOCATION is a valid absolute path. If not then dont run goplay, exit early. OR
2. Call goplay directly from the createCommandWith function.

[ramya-rao-a]

Even after installing goplay, user will have to reload VSCode for the change to take affect because the location of the binary gets calculated once in the beginning and isnt updated.

Feel free to use getBinPath for every call

[ramya-rao-a]

Clear the output channel before sending any output

[m90]

@ramya-rao-a Thanks for your review. I think I should have adressed all the open issues, so feel free to take another look when it fits.

[ramya-rao-a]

it's a common pattern in this extension to make multiple tools available (although maybe not necessarily in that case) for the same task

But the playground doesn't fall into this category. There is only 1 tool that can be used.

Features in the Go extension fall into 2 categories

1. Those that register providers and talk to VS Code apis exposed to extensions. Eg: Formatting, Completion, Definition, SignatureHelp, Hover Info, Rename etc. These follow the "implement class -> instantiate class -> use the instantiated class to register the provider" pattern
2. Almost all other features are registering a command and providing a callback to call when the command is executed. These follow the "define a function -> export it" pattern

In the interest of keeping similar pattern in the second category here, I'd very much appreciate it if we do not use the OOP like approach for the playground feature.

Of course, I am open to consider a refactoring on a bigger scale where we move all the other features (falling in the second category) to a OOP approach. But until then, I'd prefer to keep things similar.

[m90]

I see your point re: consistency, yet this would mean that this turns into one untestable monolithic function (correct me if my thinking that capturing channel output in a test is not possible is wrong). I personally would feel a lot more confident shipping such a feature with unit tests, yet this is not my extension. I just wanted to raise awareness for that fact. I'll ping you once I've done the changes.

[m90]

@ramya-rao-a As requested I merged all the code into one function for the sake of consistency.

[ramya-rao-a]

@m90 Thanks for your work on this.
I have refactored the code a bit to enable having the unit tests you earlier had.
In case you are interested: eb8bfdb