VSCode Integration

[marcomorain]

Here is a tasks.json file to add basic clj-kondo support to vscode:

{
    "version": "2.0.0",
    "tasks": [
        {
            "label": "clj-kondo",
            "type": "shell",
            "command": "clj-kondo --lint ${file}"
            ,
            "group":{
                "kind": "build",
                "isDefault": true
            },
            "problemMatcher": {
                "fileLocation": ["absolute"],
                "pattern": {
                    "regexp": "^(.*):(\\d+):(\\d+):\\s+(warning|error):\\s+(.*)$",
                    "file": 1,
                    "line": 2,
                    "column": 3,
                    "severity": 4,
                    "message": 5
                }
            }
        }
    ]
}

[marcomorain]

##Problems pane:

Editor:

Hover:

[borkdude]

Maybe interesting to trigger the above task on save:

• https://marketplace.visualstudio.com/items?itemName=Gruntfuggly.triggertaskonsave

Also I suggest making the --cache option the default, since that will find arity errors of calls that go outside the current namespace.

[borkdude]

Note that there is also a joker plugin for VSCode. Since clj-kondo follows the same execution model and output as joker, maybe that can be adapted a little so it supports both linters:

https://github.com/martinklepsch/vscode-joker-clojure-linter

[PEZ]

There is also a Joker linting feature in Calva. I think it would be good if we could make it so that we had a maintained clojure linting extension, which supported using either Joker or clj-kondo (or both). And remove the linting feature in Calva. (Which I might do anyway, but I'd much rather know that there is something Calva users can install for linting before I do that.)

[borkdude]

Martin mentioned this on Slack:

It (https://github.com/martinklepsch/vscode-joker-clojure-linter) is not maintained and I would be happy to transfer it to anyone interested.

[PEZ]

From my experience, maintaining the linting feature in Calva, I think it would be something with pretty low maintenance. Just saying that here, in case someone stumbles across it and would like to take something like this on. The vast bulk of the work is with the actual linters, and the extension doesn't need to do all that much work. And VS Code has really nice API:s supporting the task.

[sogaiu]

I tried the tasks.json file from marcomorain and it is working so far 👍

To get it to work:

• Made a .vscode directory in a Clojure project directory
• Saved the content within the .vscode directory using the name "tasks.json"
• Opened a Clojure file in VSCode
• From the Terminal menu, chose "Run Build Task..."
• Observed the output of clj-kondo running in a VSCode terminal pane

On a side note, is it the case that one must include a copy of this in every project (workspace in VSCode?) one wants to use it in?

[borkdude]

As of v2019.06.07-alpha clj-kondo supports JSON output: https://github.com/borkdude/clj-kondo/blob/master/doc/config.md#output. That might make integrating with VSCode easier?

[sogaiu]

I have used the new Clojure API support in clj-kondo toward making an extension.

Hope to have more to report soon.

[sogaiu]

I tried @marcomorain's new clojure-lint extension -- it seems to be working well under at least Manjaro Linux 👍

I didn't have as much success on Windows 7 though. From what I can tell it activates (based on logs), but no errors or warnings show up in the status bar (though I see some when I run clj-kondo via the command line).

I happen to also be working on some extensions that use native-image and I have run in to what is a similar-looking situation. I gather that clojure-lint uses execFile, which IIUC, is implemented on top of spawn -- which is what the extensions I'm working on use.

It appears that clj-kondo and the native-images I'm building don't communicate well with vscode via pipes. The binaries launch, but don't seem to send or receive info via pipes -- although they work via cmd.exe. I tested my code in non-native-image mode via vscode (using the unofficial clj-windows) and there it works fine, so my current suspicion is that there's something about the native-imagification process that might be leading to problems.

[marcomorain]

I’ll add some more verbose logging perhaps to help track down the problems on Windows. What version of clj-kondo is on the PATH on Windows?

[sogaiu]

I was testing with something built from source originally.

I've gone back to test with the official releases of 2019.06.07-alpha and 2019.06.16-alpha. Oddly enough, those don't appear to function even from cmd.exe. No output from executing them with whatever command line arguments i've tried (including notihing, --version, --lint <file>).

I checked out 3e51857 (I think this corresponds to what 2019.06.16-alpha is built from) and built that locally. The result of that works from cmd.exe, but still doesn't work from vscode.

Some relevant sha256 checksums include:

779b6a0fa4e9a0535cb5e265783da0e908ae03e6298f04669f3c7020a63ff125 *clj-kondo.exe
4f580db59cfdce3cd8d8948f83913f0d51f9ef0069b6cdba10240044dbf85ab6 *clj-kondo-2019.06.07-alpha.exe
2d464ac1758c5f6fbcfa2edde446e0eb339406abb661a1ab0adf744d41a48077 *clj-kondo-2019.06.16-alpha.exe

where the first result corresponds to the one I built locally.

Ah, this is all using:

• Windows 7 SP1 Professional 64-bit.
• VSCode 1.35.1

[borkdude]

I have just tried clj-kondo.exe on a clean Windows 10 machine and had the same problem: exit with no output. Although it worked in the VM it was built in. Maybe it needs a very specific version of the C++ redistributable as described in the GraalVM docs.

[borkdude]

@sogaiu I posted an issue about this here: #276
Let's fix that first. In the meanwhile you may use the Docker or linux version (in bash) of clj-kondo to get fast startup time and put it behind a script shim?

[borkdude]

Implemented by @marcomorain at https://github.com/marcomorain/clojure-lint.

[sogaiu]

For the record, I think there may be at least two separate issues here.

One has to do with dlls. From local experiments with examining output from Dependency Walker and behavior observed after modifying PATH, my current impression is that the wrong version(s) of something(s) are being picked up. It doesn't look to me like necessary dlls (at least by name) are not being located.

Another issue has to do with piping. It appears that working with System/in (standard input) and System/out (standard output) directly does work, but when one tries to work through *in* and *out*, there are problems. In my testing I found slurp to work with ordinary files and System/in, but not *in*. I suspect something similar is problematic for *out*.

For reference, the official docs for *in* and *out* say that one wraps System/in and the other System/out by LineNumberingPushbackReader and OutputStreamWriter, respectively.

(Just a reminder for the future, but this is all under Windows only.)

[borkdude]

@sogaiu Thanks for all the time and energy you're putting into Windows support. I consider the VSCode integration issue to be closed for now. New problems can be discussed and solved in separate issues, for easier tracking.

• For the Windows dll problem we can continue here: windows: find out what is needed to run binary on clean system (visual studio c++ 2010 redist?) #276

• For slurp issues in Windows please make a different issue (and a corresponding PR if you want AppVeyor to build it)

• As we discussed on Slack, there might be an escaping issue with Windows paths in JSON output.

Feel free to create any additional issues specific to VSCode on Windows if needed.

[sogaiu]

See #304 for the 3rd point.