@filipematossilva updated his npm package to fall back on the jar if the native version isn't supported.

👋

This means that when you install the NPM package on Windows and install the clojure-lint plugin in VSCode, linting should work on save now

you should be able to do it globally even, via npx clj-kondo --lint src/

using a JVM, so feedback might not be as fast with the native version, but it should work I guess!

(if you don't want a local package)

was just testing if the extension just worked if I installed the package globally

I'm on windows and did npm i -g clj-kondo

the binary works

$ clj-kondo
clj-kondo v2019.10.11-alpha

Usage: [ --help ] [ --version ] [ --lint <files> ] [ --lang (clj|cljs) ] [ --cache [ true | false ] ] [ --cache-dir <dir> ] [ --config <config> ]

Options:

  --lint: a file can either be a normal file, directory or classpath. In the
    case of a directory or classpath, only .clj, .cljs and .cljc will be
    processed. Use - as filename for reading from stdin.

  --lang: if lang cannot be derived from the file extension this option will be
    used.

  --cache-dir: when this option is provided, the cache will be resolved to this
    directory. If --cache is false, this option will be ignored.

  --cache: if false, won't use cache. Otherwise, will try to resolve cache
  using `--cache-dir`. If `--cache-dir` is not set, cache is resolved using the
  nearest `.clj-kondo` directory in the current and parent directories.

  --config: config may be a file or an EDN expression. See
    .

but the extension says

Clojure Lint extension loaded.
Please report any issues to 
clj-kondo was not found on the path. Please install it following the instructions
located here: "

^ @marc-omorain

@filipematossilva did you re-open VSCode after putting clj-kondo on the %PATH%?

what do you see when you run clj-kondo from a CMD.EXE terminal?

yes, I restarted vscode, just tried restarting again

on cmd I see this

Microsoft Windows [Version 10.0.18362.418]
(c) 2019 Microsoft Corporation. All rights reserved.

C:\Users\kamik>clj-kondo
clj-kondo v2019.10.11-alpha

Usage: [ --help ] [ --version ] [ --lint <files> ] [ --lang (clj|cljs) ] [ --cache [ true | false ] ] [ --cache-dir <dir> ] [ --config <config> ]

Options:

  --lint: a file can either be a normal file, directory or classpath. In the
    case of a directory or classpath, only .clj, .cljs and .cljc will be
    processed. Use - as filename for reading from stdin.

  --lang: if lang cannot be derived from the file extension this option will be
    used.

  --cache-dir: when this option is provided, the cache will be resolved to this
    directory. If --cache is false, this option will be ignored.

  --cache: if false, won't use cache. Otherwise, will try to resolve cache
  using `--cache-dir`. If `--cache-dir` is not set, cache is resolved using the
  nearest `.clj-kondo` directory in the current and parent directories.

  --config: config may be a file or an EDN expression. See
    .


C:\Users\kamik>

I suspect this is due to npm creating both clj-kondo and clj-kondo.cmd

cmd.exe will actually use the latter (I think?)

C:\Users\kamik>where clj-kondo
C:\Program Files\nodejs\clj-kondo
C:\Program Files\nodejs\clj-kondo.cmd

The error must be here: https://github.com/marcomorain/clojure-lint/blob/cdd49c92365f4e28fd4e9baed7c6f0c65e93dd16/src/extension.ts#L47-L73

https://nodejs.org/api/child_process.html#child_process_child_process_execfile_file_args_options_callback

@filipematossilva can you rename clj-kondo to clj-kondo.exe please and see if that affects the issue?

That might be the issue.

Windows process launching is “interesting”

I can't do that, because just renaming it doesn't make it a real exe

C:\Users\kamik>clj-kondo
This version of C:\Program Files\nodejs\clj-kondo.exe is not compatible with the version of Windows you're running. Check your computer's system information and then contact the software publisher.

oh, what file type is it?

it's a .cmd script

maybe making the script command configurable works?

That’s going to be the issue. I’m calling execFile which is not using a shell, it’s trying to execute a binary directly I think.

oh

that part is out of my hands though, it's how npm/yarn do things

it'll create those binaries automatically

This should be straightforward to fix in clojure-lint. But I don’t know how 😄

I’m on a mac right now, I might boot Windows later today or tomorrow and have a look at it.

PRs are always welcome thought!

Different issue: to make linting on Windows speedier this could also work: https://github.com/borkdude/clj-kondo/issues/541

@borkdude I imagine that'd require some extra process communication that doesn't yet exist, right?

@marc-omorain I think it's enough to also try running clj-kondo.cmd instead of clj-kondo on windows... is there an easy way for me to test that? e.g. whats the global extension dir, I can try changing it there

the way I imagine it is you run java -jar clj-kondo.jar --server 1337 once in your project dir (so one server per project). This startup could be automated by checking if it already runs and if not start it. and then there will be a clj-kondo-client which will support exactly the same command line args as clj-kondo, but acts as a proxy between the editor and the jvm process

maybe the client can just be named clj-kondo which will start the server in the background if it's not already running, to make things more align with the binary

preferably that client will be very very fast and supported on all platforms, so maybe Go is a good choice there

hey, this looks a lot like what @dave is doing with Alda 🙂

@marc-omorain yeap, using clj-kondo.cmd in the extension on windows works!

😄

@marc-omorain here's a PR https://github.com/marcomorain/clojure-lint/pull/10

as part of that PR you could maybe also check if clj-kondo was installed via npm or have a fallback, if clj-kondo does not exist, then try clj-kondo.cmd? @filipematossilva

to do that in a cross platform way would require a somewhat more involved approach

just trying to run the commands isn't a great approach, because that can take a while

so it would be an overhead that might not be reasonable depending on how even these are ran

something like shelljs could be used to provide a cross platform which command, and then we could do which clj-kondo

which on windows will return the .cmd (in the npm case)

and whatever else is actually ran by the system in the non-npm case

I wasn't suggesting running them, just checking if they exist on the path?

not sure what you can and cannot do in visual studio code out of the box without installing extra stuff

hmmm I'm not that familiar with the vscode builtins myself...

maybe @marc-omorain knows...

which in shelljs would check the path as you describe, but checking it without shelljs would need some finicky cross platform coding

https://stackoverflow.com/questions/58451856/vscode-api-check-if-path-exists

but that might not work for the PATH path

not sure

no, it doesn't

that's just checking if a particular absolute path exists

but it might be anywhere in the path really

yeah ok

I don't know how shelljs performs under Windows. The check has to be fast

can't see anything here why it would be slow: https://github.com/shelljs/shelljs/blob/master/src/which.js (just skimmed it)

if we're going to do something more sophisticated, maybe it's good to populate the command variable outside the lint function, only at startup?

I'll leave that to you @marc-omorain and @filipematossilva to decide 🙂

I’m working on a patch for shelljs now

Shouldn't the extension just bundle the npm package?

https://github.com/marcomorain/clojure-lint/pull/11 @filipematossilva could you take a look please? 👀

@marc-omorain this which command is now executes every time you lint a file. I don't know if this is milliseconds, then it probably doesn't matter, but maybe it makes sense to lift it outside the lint function.

Yeah, I’ve been thinking about that. Users would have to restart VSCode after installing clj-kondo in that case.

hmm

But that’s probably going to be the case on Windows anyway?

not sure, yeah, tradeoff

I could cache the positive result though.

Right. I think optimizing for speed for most common usage is maybe a sane thing to do

sorry for the delay, was AFK for a while

yeah I don't know how long which takes, but it might take a while depending on your path

and it's really just something that needs to happen once

so it makes sense to lift it out

I think it makes sense to bundle clj-kondo as a npm dep as well, but that makes it a bit heavier and since there's no override, locks the user to a certain version

other npm based extensions like tslint and the like usually do a priority list with override > local > bundle

yeah, I would prefer letting users decide how to install it

and if it's not installed then use the included package

if that's possible (so what Filipe said)

agreed

Maybe implementing some diagnostics in the LSP works for most editors as well. https://github.com/Microsoft/vscode-extension-samples/tree/master/lsp-sample

So you can start kondo as an LSP server and then lint using existing LSP tools?

I imagine @pez has a LSP server on Calva, since it offer completion

No LSP yet. Calva's completion is nrepl based.

I want to experiment with starting a clj-kondo daemon on the repl server. And provide an API for the linter extension.

https://elm-lang.org/news/the-syntax-cliff

Some error messages examples ^

elm really went the extra mile with error messages

@pez That's kinda the same as https://github.com/borkdude/clj-kondo/issues/541 so maybe we can collaborate. But maybe if this server mode supports LSP it makes it easier for existing tooling to use as well

well maybe it's not the same. if you have nREPL you have a running JVM so that's the mechanism to avoid startup

so there isn't anything extra needed for that

Yes, that's the idea.

interesting. I'll let this sit on the hammock some more and see how your approach works out

Read that issue now. As for a node version. Could clj-kondo be made a cljc project?

I think it could, but this would mean me taking a sabbatical of one - three months, maybe a Clojurists Together sponsorship. Not sure when I'll be able to do that amount of work

Most work is porting the rewrite-clj parser bits to CLJS (which is already done in @lee's port of rewrite-clj, but we can't use that off the shelf since there are changes from the original for good reasons).

Long term it's something I'm open to, but not something that will be there soon, unless someone else is willing to do this.

It would be cool to be able to invoke clj-kondo in a browser playground all client side

Before I send this out to the tweetosphere, can you confirm if this works now @filipematossilva and @marc-omorain? 🙂

Clj-kondo @ NPM (by @filipematossilv) now falls back to .jar file if native isn't there. If you use Windows:

- npm install -g clj-kondo
- in VSCode: install clojure-lint (by @atmarc) 
- edit Clojure file, hit save and enjoy feedback!

Report findings at:

(Still not sure if running a JVM on save feels that great, maybe it should be configured as a command, or that's already possible?)

Is there a reason why the Clojure lint extension does not include the clj-kondo npm module?

I think it should work after Marc does a release

but earlier today there was no release I could test

to be fair the npm distro of clj-kondo exists as of a couple of days, this is all very new

my suggestion to bundling is https://clojurians.slack.com/archives/CHY97NXE2/p1571661783095100

@borkdude: I’ve started to think there is not all that much to gain from starting clj-kondo through nREPL, if you implement that server mode. Then an extension like Clojure lint can bundle the npm package, run clj-kondo in server mode and hand it linting tasks. The only difference would be a JVM process less, but that is not too much of a bother, is it?

version control is a concern, if you always use the bundled version you can't control it (hence the local bit)

(this is unrelated to server concerns/benefits)

I agree with Filipe: there should always be a way for users to override the bundled one with their own package manager

@filipematossilva, not sure what is meant with no overrides, but if I understand it… nothing stops Clojure lint from offering the user to specify if the bundled version should be used or something else.

yes there's nothing stopping it, it's just functionality that would need to be developed

yeah, but we are develpers, after all. 😃

@pez I'm investigating LSP mode. That could work for all kinds of editor plugins. But it might take a while before I have this, while including it in nREPL might be more or less trivial (don't know)

LSP mode would be cool.

A good example is typescript: you don't always want the latest version, and you don't want to manually config each project you open. VSCode automatically picks up your local version if you have it, but also lets you specify a version on disk to use (e.g. a global you want). But it also bundles its own version that it uses for many things, like auto-fixes and code-intel for JS.

Yeah, that’s nice. Clojure lint could do the same.

I have an lsp branch and it does this right now:

$ lein clj-kondo --server
Exception in thread "main" java.lang.ClassCastException: org.eclipse.lsp4j.jsonrpc.json.ConcurrentMessageProcessor$1 cannot be cast to java.lang.Number, compiling:(/private/var/folders/2m/h3cvrr1x4296p315vbk7m32c0000gp/T/form-init8209597301223963447.clj:1:125)

btw @pez @borkdude, have you looked into suggested fixes?

that's something really nice in VSCode

it's mostly code transforms

some of them come from the tslint I believe, and some come from VSCode TS support

it's stuff like import organizing, correction for common mistakes, and auto-imports

the latter is ostensibly the most useful imho

you start writing a var name that doesn't exist in the current module, you get a red squiggly that tells you the ref is bad

but it also tells you something like "Did you mean to import X?"

then it does it for you

I think it's LSP powered but am not sure

It’s probably LSP powered.

@filipematossilva Implementing fixes is not in scope for clj-kondo, there are just too many things to do already 🙂

Hmm, there is https://github.com/snoe/clojure-lsp which does a lot of refactorings. Maybe it could adopt clj-kondo as a library, since it also mentions joker

That might work well, since clojure-lsp already does transformations and it can just pick up on the information the clj-kondo provides

That would also be a solution in Windows

and it would save clj-kondo figuring out all the lsp stuff

@dave I see you're a committer there. ^

@snoe seems to be on slack

(@snoe is the owner of clojure-lsp, we were talking about clj-kondo LSP support)

Hi @snoe!

btw I see there's a VSCode POC on https://github.com/snoe/clojure-lsp/tree/master/client-vscode, was it ever released as an extension?

hiya! it wasn't released, I would like someone who uses vscode to take it over.

@snoe I notice both our projects (clojure-lsp and clj-kondo) are maintaining their own fork of rewrite-clj now 🙂

I'm considering LSP support for clj-kondo for people who can't run the binary (most specifically Windows users)

But since you're basically already doing LSP for Clojure, maybe it could be interesting to see if including clj-kondo as a linting library in clojure-lsp works well

Just an idea, since you already mentioned joker in your README