Hello, I want to support shadow-cljs in Calva (a VS Code extension adding Clojure support). I fail in my attempts to figure out how it should be done. Currently with leiningen I use the ls-sessions op of nrepl and try to figure out which session is Clojure and which is Clojurescript. But with the shadow-cljs repl I get back an empty array of sessions.

Meaning I can’t even get Calva to connect to the shadow-cljs repl to find out what else might not be working. (Although possibly things should be working beyond that point since I use cider nrepl.)

What should I do in response to this message: "WARNING: can't find node_modules/shadow-cljs/cli/dist/shadow.cljs.npm.transform.js, please install npm install --save-dev shadow-cljs."?

@cjmurphy you should npm install --save-dev shadow-cljs. might need to do npm init -y first if you don't have a package.json yet.

The command worked fine. I just got confused by 'install install' - I suggested a different word, so it is like 'type install...'.

@pez cider-nrepl should just work yet. weird that ls-sessions doesn't return anything since that is handled by the default session middleware. I'll see if I'm supposed to set anything.

if you support the track-state middleware from cider however you should get a :repl-type message after each eval

which is either clj or cljs.

I see that you are looking for .nrepl-port. shadow-cljs writes this only when lein is not using it. might consider looking at .shadow-cljs/nrepl.port as well.

@cjmurphy fixed

@pez did a quick test. I think ls-sessions is empty because there are no default sessions. you'd first need to clone to create your own

Thanks @thheller. I thought thought the recursion should pick up shadow's nrepl port-file, but I was tired, I see now that it is named entirely differently.

But that wasn't the problem for me. What does clone imply? I will look at the track-state middleware, the way I do it today is really hackish.

@pez to be honest I don't know either about clone. Its just what cider or lein repl :connect do when connecting. that creates a session. in case of lein repl there sessions because lein repl consists of the part that starts the server and the one that connects. nrepl-middleware is mostly a mystery to me.

@thheller I'll have a look. I only need to unlock enough about the mystery to get this working. 😃 Still, with lein projects I don't have to do any cloning, the sessions vector is populated anyway.

well but you are hi-jacking another session to do your work which certainly is not the intended way to do things 🙂

I blame the original author for that. 😃 And will take your advice here to try be a better REPL citizen going forward.

I couldn't get it working trying to use :lein true yesterday btw, so don't know if it behaves differently then. Will give it another try tonight.

(By "it”, I mean shadow-cljs.)

ideally don't use lein, the point of shadow-cljs is to not rely on lein 🙂

Yes, I don't want to have to tell my users to use lein for this.

Another thing. Unrelated to Calva. My test project has a dependency that shadow-cljs says it can't inspect and thus it can't be used. Is there somewhere I can read up about such issues?

which file fails to inspect?

Let me check…

It's ysera:

[2018-04-12 09:08:24 - WARNING] failed to inspect resource "jar:file:/Users/pez/.m2/repository/ysera/ysera/1.1.0/ysera-1.1.0.jar!/ysera/state.cljc", it will not be available.

hmm that file doesn't seem to exist anymore? https://github.com/tomas81508/ysera

but anyways this is not an issue unless you are actually trying to use ysera.state from CLJS

I should probably just remove the warning as most of the time this is not a problem at all

@ekholm.tomas knows more about ysera. The test project I am using uses some ysera test methods (is= and such.

shadow-cljs just indexes the classpath on startup and sometimes people use .cljc files although they only work in clojure

in this case the ysera/state.cljc is empty. meaning it has no ns form, meaning "it will not be available" at runtime

Ah, thanks.

how do I specify what version of clojurescript?

in the :depenency?

@sonnyto currently not really possible due to an incompatibility with certain closure-compiler versions

looked at sammple projects and version of cljs are not used

oh

so what version is being used?

1.10.238

cool

shadow-cljs always ships a "default" CLJS version which will pretty much always be the latest one available at release time

that is not code which was produced by shadow-cljs doing that?

It seems like devcards is not independent of figwheel, so wants to talk to figwheel. So nothing that can be done then.

However all will be working, so message can be ignored.

no I think you just have old code loaded

shadow-cljs NEVER uses ?rel=1523416697167. so whatever code you have loaded is not the one produced by shadow-cljs

some people are using devcards just fine. nothing in there requires you to use figwheel.

Message is not coming from shadow, and can't be coming from figwheel as now gone. My theory is that it is coming from devcards. I must need to tell devcards not to keep communicating with figwheel. Just don't know how to do that yet.

my guess would be that you have some old generated code lying around somewhere that you are loading

you are not loading the correct code so whatever you are telling anything is not going to have any effect at all

Well I can manually remove everything (clean) under public/resources/js and that should tell.

@ekholm.tomas, I think you should bump the version of ysera. Version 1.2.0 seems to have an empty state.cljc file that shadow-cljs then complains about not being able to analyze. Checking the repo it seems like the file is removed in master. Not that ysera starts working in shadow-cljs just because of this, but at least one complaint less.

is anyone able to get reagent to work with shadow-cljs providing the react dep? for some reason I keep getting js/React not defined inside of reagent.impl

@lwhorton which version of reagent? Given that most examples use reagent I think its fair to assume that it works. https://github.com/thheller/shadow-cljs#examples

oh do you maybe have an empty cljsjs/react.cljs file in your project?

yea i was following that nice example. i’m just not sure if I need to provide the “missing” namespaces of cljsjs/react/dom/server etc.

are you suggesting that by providing those namespaces I’m breaking reagent?

you don't need those with shadow-cljs. in fact if you have them it might break things.

cause thats where the js/React is coming from

arg, i hate having this giant chunk missing from my domain knowledge about packages

so do you have cljsjs files in your project?

I do as a consequence of previously using lein (and it being required there)

phew that is good to know.

FWIW https://shadow-cljs.github.io/docs/UsersGuide.html#cljsjs

:thumbsup:

I lied above. shadow-cljs does actually need the cljsjs files but it provides a bunch of them already. https://github.com/thheller/shadow-cljsjs

is that shadow-cljsjs lib auto-included as part of shadow?

the problem is just that they are usually blank namespace declarations.

yes shadow-cljs depends on shadow-cljsjs

ok

for the most part you can just ignore it

so what I’m bumping into is something like React is not defined and if I pull apart the compiled source I see a bunch of cljs.core.apply.cljs$core$IFn$_invoke$arity$4(React.createElement, so some lib I’m using depends on window.React it seems

yes. this is what https://github.com/thheller/shadow-cljsjs/blob/master/src/main/cljsjs/react.cljs provides

and I’m not sure how best to solve it. if you’re already doing goog.set window React react

but if you had some yourself you probably had an empty (ns cljsjs.react) that just did nothing

yea I did have an empty cljsjs that did nothing (and then I tried manually requiring react and doing my own oset! ...)

which is what you’re already doing

yeah but if you have a cljsjs.react in your project that effectively overrides the one in shadow-cljsjs

and I just wonder if it’s some sort of dependency loading order, or if in my boot.core file I have to manually require ["react"] just to ensure it’s there before some other lib tries to invoke it*

what is the problem now? if you just remove the cljsjs files everything should work ok?

it should not require any work on your part at all. reagent just works without you doing anything.

yea, i think the reagent part is working now (no more issues with reagent.impl js/React is not defined)

except there’s another macro-based lib I’m using that also uses js/React

that doesn't require either "react" or cljsjs.react? then yes that may lead to load order issues

so it seems to just assume the window already has React somewhere… https://github.com/roman01la/cljss/blob/master/src/cljss/reagent.clj

and it looks like the project.clj doesn’t list cljsjs.react or any react, lol.

yep. you can probably fix that by requiring reagent before requiring cljss.reagent

ah because reagent pulls in a dep to cljsjs which shadow will see and export js/React

yep

why are you so helpful? how do you have this much time 😛

hehe

speaking about time. I'll be back later 😉

oh man — what is this? i’ve never seen this before

`[2018-04-12 13:19:47 - WARNING] provide conflict for #{authentication.views} provided by compiled/authentication/views.js and {"/authentication/views.cljs" #{authentication.views}}

@thheller the changes from https://github.com/thheller/shadow-cljs/commit/9b8f289cdc34f468a242e05494da08a6aea3bb36 don’t seem to work for me I’ve tested by redefing routes and using the same code you use to see if the var’s value changed

(do (require (symbol (namespace `router-component)))
     ((find-var `router-component) {:uri "/abc"})) <- this works after redefing

@lwhorton it appears that you :output-dir is on the classpath. that is not a good idea.

@denik I don't unterstand what that code does? it requires its own namespace?

@thheller yes using the code you use to load the var of the handler

After redefining the handler itself

It just happens to be in the same na but that shouldn’t matter if it’s properly required elsewhere