This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-10-21
Channels
- # announcements (10)
- # aws (38)
- # beginners (220)
- # calva (2)
- # cider (26)
- # clj-kondo (194)
- # cljs-dev (4)
- # clojure (190)
- # clojure-dev (7)
- # clojure-europe (3)
- # clojure-italy (6)
- # clojure-nl (4)
- # clojure-uk (8)
- # clojured (1)
- # clojurescript (29)
- # code-reviews (31)
- # community-development (9)
- # core-async (24)
- # cursive (38)
- # data-science (51)
- # datomic (52)
- # dirac (2)
- # emacs (3)
- # events (1)
- # figwheel-main (4)
- # fulcro (49)
- # graphql (13)
- # heroku (1)
- # hoplon (19)
- # immutant (3)
- # leiningen (1)
- # nrepl (59)
- # off-topic (12)
- # onyx (2)
- # pathom (51)
- # reitit (15)
- # shadow-cljs (88)
- # spacemacs (6)
- # sql (3)
- # tools-deps (107)
- # xtdb (11)
@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: "
@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
@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
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.
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
Yep, that sounds almost exactly what I'm doing! Actually, Alda v1 (the current major release version) has a client written in Java. Alda v2 has a Go client, but I'm also doing something different there where I'm moving most of the logic into the client.
When you write the client in a JVM language, one benefit is that you can package it into the same uberjar as the server, and just have a single executable that can run in either client or server mode. That simplifies releases
I was thinking the Go client can start the JVM server process when it wasn't started yet
@marc-omorain yeap, using clj-kondo.cmd
in the extension on windows works!
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
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
no, it doesn't
that's just checking if a particular absolute path exists
but it might be anywhere in the path really
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
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.
But that’s probably going to be the case on Windows anyway?
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
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
I imagine @pez has a LSP server on Calva, since it offer completion
I want to experiment with starting a clj-kondo daemon on the repl server. And provide an API for the linter extension.
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
interesting. I'll let this sit on the hammock some more and see how your approach works out
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
Our next funding round is coming up very soon, we'd love to have you apply!
> We don't have an exact date for when this is going to be ready, but it is coming soon. For members interested in learning more, please reach out and we're happy to give you a preview. I'm interested 😉
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
@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)
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.
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)
Just hacked on it for half an hour 😉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
@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
@snoe seems to be on slack
(@snoe is the owner of clojure-lsp, we were talking about clj-kondo LSP support)
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?
Hmmm I use VSCode almost exclusively. How can I help?
although to be fair this sounds very complimentary to @pez’s vscode Calva extension
maybe it could be incorporate somehow? or maybe made optional
We have been experimenting a little with it and we love it. However, we haven’t had the time to ponder if we should incorporate it. Maybe we should, and maybe we should even take it over… But that is something I need to think quite a bit about before deciding. We might be spreading ourselves thin if we do that.
@filipematossilva I'm not sure, I would like it so vscode users can be sure they have the latest clojure-lsp release. If that can be done as a separate repo that downloads from github releases that would be nice.. If it's most usable inside the repo that's fine and I can take prs and work to getting the maintainer commit access.
@snoe I just did that for clj-kondo, by distributing the binaries via npm
it downloads binaries according to platform, clj-kondo distributes native binaries for linux and osx, and a jar for windows
would it help if I did something similar for clojure-lsp?
from the releases page it's not clear to me what platform the binary is for, I guess linux/osx?
it's wrapping a jre - there's some difficulties with windows but yeah, whatever works would be great
@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
I would love to do this. My difficulty is really how to avoid parsing files once for lsp and once for kondo. Maybe I shouldn't worry about it cause the kondo linting would be very nice for lsp users.
This is the Clojure API: https://cljdoc.org/d/clj-kondo/clj-kondo/2019.10.11-alpha/api/clj-kondo.core
I'm not sure what the workflow is with LSP. Is a server started per project, file or editor instance?
the benefit of linting your entire project/classpath is that it learns about the arities of functions in all namespaces, so you will have extra warnings, but it's completely optional
typically users put a .clj-kondo directory in the root of their project. then clj-kondo will save information to the .clj-kondo/.cache directory every time you lint a file (= typically when you edit a file)
scratch the idea of using the vendored clj-kondo parser btw, that's a bad idea and you won't be able to actually generate the original output again
Our next funding round is coming up very soon, we'd love to have you apply!