Fork me on GitHub
#shadow-cljs
<
2018-04-12
>
pez00:04:19

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.

pez00:04:00

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.)

cjmurphy04:04:44

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."?

cjmurphy06:04:03

I had a great idea. I did exactly what the instruction said and it fixed the warning. I guess if it had said 'please type: npm install --save-dev shadow-cljs' the message would have been clearer, to me anyway!

thheller07:04:13

@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.

cjmurphy07:04:42

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

thheller07:04:50

@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.

thheller07:04:25

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

thheller07:04:34

which is either clj or cljs.

thheller07:04:51

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.

thheller08:04:41

@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

pez10:04:31

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.

pez10:04:44

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.

thheller11:04:23

@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.

pez11:04:35

@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.

thheller11:04:12

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

pez11:04:30

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

pez11:04:06

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.

pez11:04:33

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

thheller11:04:11

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

👍 4
pez11:04:45

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

pez11:04:15

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?

thheller11:04:14

which file fails to inspect?

pez11:04:25

Let me check…

pez11:04:49

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.

thheller11:04:45

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

thheller11:04:10

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

thheller11:04:29

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

pez11:04:45

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

thheller11:04:56

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

thheller12:04:56

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

pez12:04:10

Ah, thanks.

sonnyto12:04:35

how do I specify what version of clojurescript?

sonnyto12:04:55

in the :depenency?

thheller12:04:09

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

sonnyto12:04:10

looked at sammple projects and version of cljs are not used

sonnyto12:04:20

so what version is being used?

thheller12:04:48

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

thheller12:04:25

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

cjmurphy12:04:24

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

cjmurphy12:04:50

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

thheller12:04:54

no I think you just have old code loaded

thheller12:04:28

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

thheller12:04:50

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

cjmurphy12:04:29

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.

thheller12:04:33

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

thheller12:04:01

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

👍 4
cjmurphy12:04:54

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

pez14:04:51

@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.

lwhorton15:04:05

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

thheller15:04:39

@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

thheller15:04:57

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

lwhorton15:04:21

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.

lwhorton15:04:36

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

thheller15:04:23

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

thheller15:04:44

cause thats where the js/React is coming from

lwhorton15:04:02

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

thheller15:04:00

so do you have cljsjs files in your project?

lwhorton15:04:17

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

thheller15:04:04

phew that is good to know.

thheller16:04:18

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

lwhorton16:04:42

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

thheller16:04:47

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

thheller16:04:53

yes shadow-cljs depends on shadow-cljsjs

thheller16:04:13

for the most part you can just ignore it

lwhorton16:04:13

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

lwhorton16:04:38

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

thheller16:04:53

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

lwhorton16:04:18

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

lwhorton16:04:29

which is what you’re already doing

thheller16:04:57

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

lwhorton16:04:08

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*

thheller16:04:39

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

thheller16:04:09

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

lwhorton16:04:53

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

lwhorton16:04:03

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

thheller16:04:45

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

lwhorton16:04:56

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

lwhorton16:04:26

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

thheller16:04:58

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

lwhorton16:04:17

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

lwhorton16:04:45

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

4
❤️ 8
😎 4
thheller16:04:38

hehe

😏 4
🤫 4
4
wizard 12
thheller16:04:16

speaking about time. I'll be back later 😉

lwhorton17:04:06

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}}

denik18:04:27

@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
but shadow-cljs’ server remains stuck on the initial value until I restart the whole instance.

thheller20:04:25

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

thheller20:04:47

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

denik23:04:23

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

denik23:04:58

After redefining the handler itself

denik23:04:22

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