Fork me on GitHub
#shadow-cljs
<
2019-02-03
>
thosmos04:02:14

I'm getting an error when Cursive tries to generate stubs:

No such namespace: react, could not locate react.cljs, react.cljc, or JavaScript source providing "react" in file file:/Users/thomas/.m2/repository/thheller/shadow-cljsjs/0.0.16/shadow-cljsjs-0.0.16.jar!/cljsjs/react.cljs
I'm guessing this is because I don't have a node_modules in my base directory? I DO have one in my subdirectory and am using :js-options {:node-modules-dir "client"} to tell shadow-cljs where it is. I'm wondering what the right way is to use shadow-cljsjs. Do I need to add exclusions for deps that use cljsjs, like this?
{:deps {thheller/shadow-cljsjs    {:mvn/version "0.0.16"}
        fulcrologic/fulcro        {:mvn/version "2.7.2"
                                   :exclusions  [cljsjs/react
                                                 cljsjs/react-dom
                                                 cljsjs/react-dom-server

lilactown04:02:29

@thosmos in general case, shadow-cljs just ignores cljsjs deps and looks in node_modules

lilactown04:02:44

not sure about the cursive error

lilactown04:02:19

is that an error showing in Cursive, or in your shadow-cljs compilation output?

thosmos04:02:25

cool, so maybe if I add those deps back in it won't affect shadow-cljs but will get rid of the error in Cursive. It's a cursive error.

lilactown05:02:17

yeah, I would try that

thheller08:02:53

@thosmos Cursive doesn't use shadow-cljs to generate the stubs so I suppose it uses :npm-deps with the default compiler options

thheller08:02:26

dunno why it is trying to generate stubs for the cljsjs shims though. seems odd

thheller09:02:35

ah I guess its just compiling normally and picks those namespaces over the normal foreign-libs

heyarne10:02:05

i just saw that doo supports coverage supports via istanbul and karma-coverage. did anybody manage to set this up with the :karma target?

thheller10:02:53

not sure what that is but I imagine you configure it in karma.conf.js?

lxsameer13:02:26

@thheller hi there

lxsameer13:02:48

I'm gonna give a talk in our locale clojure group about shadow-cljs

lxsameer13:02:45

what are the killer features of shadow in compare to cljsbuild and figwheel ?

thheller14:02:51

@lxsameer probably need to ask someone that has used those tools recently.

thheller14:02:29

I'd probably highlight the npm integration, overall speed, simplicity and reliability (ie. no constant lein clean or the like)

lxsameer14:02:00

@thheller I'm one of them. For me the dynamic code loading and ease of use are super useful

thheller14:02:04

more fine tuned build targets so no manual fiddling with build settings and such

thheller14:02:42

its also pretty much the only "full stack" tool currently

lxsameer14:02:45

@thheller also are you working on any new feature whether released or in development which you think it might be worthy to mention

thheller14:02:03

ie. figwheel only does development stuff but isn't concerned with release builds much

thheller14:02:19

nah better talk about what is there not what might be

thheller14:02:08

npm integration alone is enough for most people coming from that world

lxsameer14:02:08

cool, thanks friend

thheller14:02:47

thanks for giving a talk about shadow-cljs! if I can help with prep let me know

lxsameer14:02:45

no problem. To be honest I recently wanted to write a piece of software for my editor and i didn't want to use JVM, so I used shadow-cljs for the first time with node support,

lxsameer14:02:55

and I was totally impressed by it

lxsameer14:02:09

it's really cool. SPECIALLY the npm support

heyarne15:02:56

how much more does shadow-cljs do for npm support? https://clojurescript.org/news/2017-07-12-clojurescript-is-not-an-island-integrating-node-modules sounds like it should work fine by now, even though my last experience was that shadow-cljs really smoothed things out

thheller15:02:25

@arne-clojurians the npm support in shadow-cljs is implemented from scratch and has no relation to the article you linked or the :npm-deps feature in CLJS

thheller15:02:04

:npm-deps is IMHO a dead end and will never work reliably enough (given the current state of wild-west JS on npm)

thheller15:02:53

even the official statement is not to use :npm-deps and use webpack instead these days

thheller15:02:26

I wrote a couple posts on the subject a while ago if you are interested

thheller15:02:37

TL:DR: gave up :advanced optimizations for npm dependencies but instead gained almost full compatibility

thheller15:02:12

so shadow-cljs does a whole lot more and is somewhat modeled after what webpack does

heyarne15:02:10

cool, thanks!

mattly17:02:36

is there a way to trigger a rebuild on a resource change, because say I have a macro that inlines a .graphql file into my code?

thheller17:02:44

@mattly nothing built-in currently besides the usual touch src/main/some/file.cljs

mattly17:02:59

heh, thanks, that's what I've been doing

thheller17:02:00

ie. when you modify the .graphql file you have another tool trigger the touch

mattly17:02:25

at least with VSCode I can just save the file and it will touch it as opposed to emacs which requires some dirtiness

thheller17:02:53

you can trigger recompiles via the REPL too

thheller17:02:27

(assuming you marked the file that uses the .graphql as uncacheable that would be enough)

achikin19:02:18

@thheller I have a conceptual question. Maybe it sounds a bit naive, but why not turn things around and run the compiled clojurescript code through webpack alongside with npm modules and let webpack create the final bundle?

thheller20:02:34

@achikin you can do that with :target :npm-module. I explained my reasoning here https://code.thheller.com/blog/shadow-cljs/2018/06/15/why-not-webpack.html

😜 1
👍 1
thheller20:02:39

someone with more patience should certainly explore that avenue more though. I couldn't stand looking at the webpack code ... too much JS 😛

😱 1