That would be something nice indeed for cljs projects, but it's not trivial, the first step to achei e that would be have analysis of the node modules in clojure-lsp, for all clj things we have clj-kondo that return these analysis, we would need to check if we could improve kondo for that or use another tool

@U04V15CAJ is there any issue or plans to add support for node modules analysis in clj-kondo?

This can be accomplished by using a Node.js REPL like nbb, or shadow-cljs Node.js repl ;)

You mean use the reply to workaround this or you mean use that in clj-kondo or something like that?

I mean, clj-kondo already have all the analysis API

Would be nice to keep using that

I think a REPL is more powerful for JS auto-complete

Yeah, I was thinking if we could do something like we did for clj-easy/stub, that starts a process collect all that and we use it

That'd be a start of improving static analysis with repl data which is something interesting

JS is far more dynamic and therefore more complicated to get auto-complete right I think, even harder because of clj-kondo/lsp being implemened in JVM instead of Node.js. From Node.js you can probe and evaluate things. The REPL can tackle such dynamic queries. Stuff like what is on the global object (js/...) can't be answered by scannning node_modules, but depends on your runtime

Also there is the whole CJS/ESM horror story: just looking at the source won't tell you exactly what is exported where, it also depends on package.json etc

So if you really want to try something, maybe write an experimental dump tool like you suggested, maybe a Node.js program that is ran over node_modules and js/.. once. Or maybe stuff that uses jsdoc or so, I don't know

Yeah, makes sense

Perhaps VSCode already has some indexing stuff, perhaps for their lsp server

It would be interesting if users have an lsp js server installed, if we can just talk to that

would be helpful for clr too.