Fork me on GitHub
#shadow-cljs
<
2018-06-18
>
bupkis10:06:11

how can I force shadow-cljs to use a local version of a library (installed via lein install for example) instead of fetching it from clojars, etc.? I know I can override individual files, but in this case I'm testing changes to the library's dependencies so it'd be easier to use the JAR that I've locally built.

thheller10:06:45

just lein install it

thheller10:06:00

no need to force anything, it will use that jar as long as the versions match

thheller10:06:25

you may also just add :source-paths ["../../path/to-lib/src" "src"]

bupkis10:06:20

awesome. i did try that, but haven't realised that the library in question has subprojects that also needed to be lein installd. thank you, it's very easy with shadow-cljs, as always.

thheller10:06:45

its a maven thing really so you can do this with lein or tools.deps as well

bupkis11:06:15

good to know, cheers

fatihict13:06:20

Hello, I just noticed that shadow-cljs doesn't pick up changes after a while watching a build. I'm on shadow-cljs 2.4.2.

thheller13:06:37

never heard a single report like that. gonna need more info 😛

fatihict14:06:08

Well, It's actually really vague 😛.. I'm running shadow like so npx shadow-cljs watch app and after a while shadow is not compiling new changes anymore. @timovanderkamp ran into the same issue today. If it occurs again and when I have more info I will keep you updated

Logan Powell14:06:51

How would I phrase require('dotenv').load() in a shadow :require statement?

thheller14:06:23

(:require ["dotenv" :as dotenv]) then outside ns (dotenv/load)

thheller14:06:38

@cjmurphy it is missing the most important thing

thheller14:06:47

how do you actually use devcards?

thheller14:06:53

how do you require it?

thheller14:06:00

and do you call (devcards.core/start-devcard-ui!)?

cjmurphy14:06:54

No I'm not calling (devcards.core/start-devcard-ui!).

thheller14:06:08

is that not usually require? sorry I don't use devcards myself so I'm just guessing

thheller14:06:18

docs seems to suggest that you have to call that

cjmurphy14:06:26

Just looking in the fulcro template right now, and can't see a call to start-devcard-ui! there, yet it uses cards.

wilkerlucio14:06:39

maybe you were looking at fulcro-template? that was the old one that we usually clone

cjmurphy15:06:29

Yes I was looking at fulcro-template. Never have looked at fulcro-lein-template as cloning has always been good enough for me. Didn't realise that fulcro-template had become old. That should give me enough to fix the issue. Thanks @wilkerlucio simple_smile

wilkerlucio15:06:04

no problem 🙂

justinlee16:06:27

question about file structure: i have a couple of files that have many functions in them (server calls and state manipulation). almost everything in my code base depends on them. the problem is that compilation is is taking 9-10 seconds. i’m a little surprised by that because it only causes 12 files to recompile and this is not a huge code base.

justinlee16:06:57

is this expected, and if so, should i just work on breaking up the files so that the dependencies are more targeted?

thheller16:06:06

@lee.justin.m what are you doing in that file? 9-10 sec seems excessive? how long does compiling cljs.core take on your machine?

justinlee16:06:17

@thheller any edit, even to a comment, will cause the recompile. how do i test cljs.core?

thheller16:06:32

I'd love to get my hands on that file just to use it as a basis to tweak the compiler 😉

thheller16:06:48

rm -rf .shadow-cljs/builds/<id>/dev

thheller16:06:57

shadow-cljs compile <id> --verbose

justinlee16:06:22

i use schema pretty heavily. i wonder if it is the macro expansion

thheller16:06:38

ah yep .. that definitely hurts performance

thheller16:06:17

probably just macro performance then

justinlee16:06:19

there’s nothing in .shadow-cljs

justinlee16:06:26

except for config.edn

thheller16:06:47

in the project not your home dir

justinlee16:06:49

ah got it. <- Compile CLJS: cljs/core.cljs (6549 ms)

justinlee16:06:40

(note that i am not running a server while doing this, in case it matters. i usually just run the watch command directly and i killed it before doing this test)

thheller16:06:09

watch will get faster over time due to better JIT but 6.5sec is good baseline

thheller16:06:25

then 9-10s with many macros is not so excessive

thheller16:06:54

still waaaaaaay too slow

thheller16:06:18

but no easy fix for now

justinlee16:06:13

um. okay, so now that i restarted the recompile time is down to 1.68s !

justinlee16:06:36

i’ve got my watch running in verbose mode, so i

justinlee16:06:47

i’ll see if i can figure out what changes over time

thheller16:06:31

ah I thought it took 9-10sec to compile that single file

thheller16:06:20

I have some ideas for making live-reload perf better but they all involve using the analyzer data more intelligently

thheller16:06:31

which is a ton of work and idea if it will actually help

thheller16:06:56

currently if you change one file all the files that depend on that file directly are also recompiled

thheller16:06:34

say you change (defn foo [a b]) to (defn foo [a b c]) the others need to be recompiled to get the warnings

thheller16:06:51

but we could detect if any function signature actually changed in a recompile

thheller16:06:16

and only trigger the dependent recompiles if necessary

justinlee16:06:19

before i asked my question, i didn’t have verbose on, so i was just reporting the total recompile time, which was 10s. now that i restarted, the total recompile time is 1.6 seconds.

thheller17:06:20

hmm if it gets slower again let me know

justinlee17:06:08

i think i’ve noticed this before but didn’t believe it, but now i’ll pay closer attention (and i should have data because verbose is on)

lilactown17:06:48

hey all - I started working on an idea I’ve been thinking about for awhile - a new lib for creating React components using hiccup: https://github.com/Lokeh/hx

lilactown17:06:21

interested in getting some feedback from people and thought users of shadow-cljs users might appreciate some of the goals 😅

justinlee17:06:28

that would be a hell of a lot easier for javascript programmers to understand

lilactown17:06:11

that’s the idea

thheller17:06:00

$ this is a really neat trick (unfortunately the code format in Cursive always breaks it apart 😞

lilactown17:06:54

😂 I’m glad you think so - I’ve been afraid it’s a bit too clever

lilactown17:06:13

I like the ease of use that reagent has in that it gets annoying having to type (compile-hiccup ... over and over when you break out for some actual Clojure code

thheller17:06:38

I do think its probably too clever but repeating hx/compile all the time sux too

lilactown17:06:49

^ yep exactly

thheller17:06:49

yeah 😉

lilactown17:06:00

bummer about Cursive formatting 😧 I wonder if there’s a way to fix it

thheller17:06:03

I personally don't use hiccup at all anymore (on the client)

thheller17:06:53

this https://github.com/thheller/shadow/wiki/shadow.markup takes care of having to type :div.page-title and just calling (page-title ..) looks better anyways 😉

thheller17:06:00

but it's not always great either ... still looking for better solutions

lilactown17:06:05

I think that the thing I appreciate the most about hiccup is it gives you the ability to run transformations over the code before actually computing the React tree

lilactown17:06:47

although when you start taking the all-macro approach like hx the value might be less 😛

dominicm17:06:07

https://code.thheller.com/blog/shadow-cljs/2018/06/15/why-not-webpack.html Am I reading this correctly that npm deps do go through google closure in a clever way?

thheller18:06:02

they go through closure :simple yes

bolasblack18:06:17

Hi thheller, I encountered an issue releated with cljs.spec.alpha/fspec : the code always throw error Error: Var clojure.test.check.generators/return does not exist, clojure.test.check.generators never required even though I have already required clojure.test.check.generators. I reproduced the issue in

thheller18:06:44

@bolasblack yes, 1.10.312 currently has a problem

bolasblack18:06:48

But if I use clj --main cljs.main --repl, the code works fine

thheller18:06:57

I identified the problem but not happy with the workaround yet

bolasblack18:06:58

You can have a try with my repo

thheller18:06:12

@bolasblack sorry 1.10.238 in combination with shadow-cljs

thheller18:06:47

its a shadow-cljs issue really. one of the compiler hacks I did for externs inference breaks due to a change in what code the exists? macro generates

thheller18:06:56

just stick with 1.10.238 for now

bolasblack18:06:36

I understand 🙂

bolasblack18:06:10

This issue is not so important to me, so I can wait until you are willing to fix it. 🙂

wilkerlucio18:06:44

@lilactown one feedback, I find cool the trick for $, but this also is a problem... it generates syntax, I might be a purist here, but I dislike it in same way I dislike => on midje, it seems cool until you want to apply paredit things, then the beatly of simplicity falls apart, I really got used to om.next style of having functions, they are easier to separated from vectors while reading, are faster (since there is pre-processing, they already return the elements). for $ I would hater you just have a function that does it: $ [:div "bla"] vs ($ :div "bla")

wilkerlucio18:06:10

and the later doesn't need macro expansion 😉

lilactown18:06:58

well, it’s meant to aid in writing your React data using hiccup

lilactown18:06:17

:thinking_face: maybe I could add the $ as a sort of progressive enhancement

lilactown18:06:40

I only tested it with my editor setup (spacemacs clojure layer) but if it doesn’t work under Cursive or paredit then that’s a problem

lilactown18:06:02

I’ve been thinking about adding an interceptor-style way of extending the hx.react/compile macro so it might be a good way to add it as an optional transform

lilactown18:06:43

@thheller that is pretty cool!

lilactown18:06:07

I’m trying to avoid putting too many things into the hx lib… I do want to explore how I can enable transforms like that to be added easily, though

lilactown18:06:12

I already have a reagent-like state management with atoms implemented in https://github.com/Lokeh/hx/blob/master/src/hx/state.cljc 😂 I need to split it out from hx though