State of this project and the future

[razzeee]

Hey there,

nice project. As I pitched https://github.com/elm-tooling/gsoc-projects#improving-test-integration-in-the-elm-language-server I would be very interested in what your planing to do with this extension and if your planning to migrate to the new VSCode api (when its finished)
microsoft/vscode#107467

Cheers

[frawa]

Thanks for reaching out, @razzeee.

Following the evolution of VS Code APIs towards testing sounds like a great way to go.
Given they find inspiration from vscode-test-explorer, it should be easy to leverage this project, migrated or integrated with a followup project.

I am note quite sure to grasp your idea behind the Elm LSP proposal, can you elaborate?

My next best guess to improve this plugin is to support elm-test-rs, which allows for individual tests to be run. (I am not sure node-test-runner is going to evolve, do you have more information?)

[razzeee]

I was blissfully unaware of this project and kinda hoped for the vscode folks to go for a protocol implementation like lsp (https://microsoft.github.io/language-server-protocol/) so that the integration could be used by more clients then just vscode.

But as I was unaware of this, I thought it might still be worth it to implement this in vscode and add it into the vscode client we currently have for the language server.

I think I need to find out two things:

• Is there enough work for a student to work on - so are there features/feature sets that are missing
• Can I mentor it or would you even be able to mentor (no pressure please)

Otherwise it might be wiser to just let it be 🐝

[harrysarson]

(I am not sure node-test-runner is going to evolve, do you have more information?)

The node test runner is still evolving! Don't count us out just yet :)

[mpizenberg]

If you need a specific feature in elm-test-rs don't hesitate to pitch it in an issue. And I think the --filter option potentially usable to identify a unique test could easily be added to the node test runner too (maybe ^^). It just a List.filter of the tests inside a runner at its core, so it doesn't change how tests are gathered and compiled, just how they are run.

[razzeee]

@frawa what will it take to remove the draft from your readme?

Can you think of any ways we could combine efforts? elm-tooling/elm-language-client-vscode#147

Do you think keeping the test runner outside of the vscode language client is ideal?

[frawa]

@razzeee Actually, this project has reached what I wanted to explore. That said, I will remove draft at next occasion.

I agree to think that integrating the test running with a larger project makes sense.
(We did the same move for a similar plugin in IntelliJ a while back.)

Let's prototype a move into https://github.com/elm-tooling/elm-language-client-vscode/.

[razzeee]

Exciting. And it being licensed MIT should allow us to keep it simple. Are you willing to work on this, should we have a call or should I just have a go?

[razzeee]

Building an extension pack might also be a valid route to take https://code.visualstudio.com/blogs/2017/03/07/extension-pack-roundup

[frawa]

We are talking about little code here, I think the roundup might be overkill.
Let's just move those few files into your extension.
Talking might be a good idea to avoid duplicate work and gain speed.

[frawa]

That's for your issues and pull requests,
looks like we started the same project-cleanup work at the same time.
Give me a few more nights to finish what I had in mind and catch with your work.
(I will find you on Twitter for sync.)