Fork me on GitHub
Pavel Klavík00:03:20

So I studied little bit how leiningen profiles work and moved this plugin into my user profile, so my local development works but the plugin is not used during deployment. It works as a temporary solution and we will solve a better dev setup in the future.


hello, is there a way to keep a watch running for a release build? wanting to debug something that only happens on release


no, that would be impractical


just have a shadow-cljs server instance running and trigger shadow-cljs release app --pseudo-names manually when needed (or via a REPL keybind)

👍 4

haha ... I don't know why that library exists when the closure library has a perfectly fine md5 impl 😛


but yeah don't do that 😛


it's 7 years old, but yeah. discoverability is still somewhat a problem


thank you for shadow-cljs again, it alleviates a lot of pain

👍 4

how would one use polyfill with shadow-cljs? 🙂 I need to target internet explorer... :'D


did you try just importing your polyfill file? you can even import in a js file and then require the cljs output yourself, i.e.



thanks for the info. I'm gonna try what thheller suggested first


who uses shadow-cljs with devcards?

☝️ 8

When working on react-native screens, the code is recompiled but nothing is re-rendered unless the home screen or a top bar code is changed. Is it a limitation or just poor setup? (note that rn fast refresh is disabled)

Pavel Klavík14:03:01

Hi, I am using shadow/release function to build my release. How can I detect that the build fail the rest of the build process as well?


@yenda upgrade to the latest version and try :devtools {:reload-strategy :full} in your build config

👍 4

dammit you are amazing


thanks it works perfectly


@pavel.klavik I guess if it doesn't return :done? Its really meant as an api method for the REPL so it caches and pretty-prints exceptions


I guess I could add a release! fn that just throws and doesn't catch the error


What happens if my js file requires e.g. semantic-ui-react itself?


Will shadow-cljs resolve it?


it will but there are a couple known issues so it might not work


What kind of issues?


well it either works or it doesnt 😛


the biggest issue is mixing commonjs with ESM code


since the closure-compiler thinks all npm code is commonjs it may effect how it treats the classpath js

Pavel Klavík14:03:28

@thheller thx, will take a look


Re: babel jsx processing - is there any way to hook that into shadow-cljs server so I don’t need to run babel as a separate process?


no, it is recommded to run it separately


I tried adding :js-options {:babel-present-config {:targets {:ie 8}}} to my shadow-cljs.edn, but I still get "Promise not defined" in iexplorer... any suggestions? 😄




Could be a typo


oh, haha, nice catch!


@saikyun that only affects npm code, it has no effect if your CLJS code uses js/Promise


oh I see. is there a way to babel the cljs code as well?


you can use third party polyfills like if you want to inject the polyfills only for ie


ah, cool. I'll try that then


What is :babel-preset-config? Is there any doc for it?


no docs no since you basically should never ever use it


the hotreload of shadow is so much faster than react-native fast-refresh lambdalove


I just want to note that if even shadow-cljs hotreload feels slow (e.g. when iterating on an animation), putting the function call you want to play around with at the top-level then using a repl + load-file gives you amazing response times 🙂


e.g. like so:

(defn start-animation [] ,,,)

then load-file at the repl, preferably using a hotkey 😄

👍 4

if you want to go even faster (especially in a big file) you can use eval-defun, i.e. only eval the function you're modifying


and that's something that's hopeless with "regular" react native

👍 4

I’ve noticed the hot reloading stops working a lot on my build, do you guys ever run into that? Any ideas for how to debug?


have you tried the config

:dev {:devtools {:autoload true
                            :reload-strategy :full
                            :after-load app.core/reload}}


I had an issue with some routes never hot-reloading or only when some specific parts were changed, and :reload-strategy :full did the trick


Haven’t tried that, but sounds promising. Thanks!


good to know. never seen fast-refresh in action yet 😛

Chris Little16:03:43

I'm curious about a note from a couple days ago, about :devtools {:reload-strategy :full} Before enabling :deps true , live reloading would include updates to files under node_modules. Now after enabling, I have to use reload-strategy to get that functionality. I'm just curious why the deps modes are different in this way?


is it possible to serve resources from classpath from jar files via the shadow-cljs devtools web server ?


Hello everyone 👋! Users of shadow-cljs: What would you tell a hesitant CLJS user like me who has been refraining from using shadow-cljs because it is not “the official tool”, to convince them of making the switch? Thanks in advance for your comments.


If you rely heavily on npm, don't think twice! It's not that much different, theller knows more about CLJS internals than I ever will and he's incredibly responsive here, even when we fail to read the extensive documentation :)


I tell you this, if you are using the official tool then you're doing it the hard way and anything including shadow-cljs will be better. Of course this assumes you're using the actual "official" way which is compiling the source by using the cljs.jar file and running it manually. If however you are under the assumption some other way is the "official" way (like figwheel) then you've been misled and you're already off the beaten path!


out of curiosity, what is "the official tool"?


I had a misconception about shadow-cljs, I thought it was some sort of fork of the CLJS compiler


thanks for the clarification


@jplaza what makes a tool official? shadow-cljs is just as official as figwheel is?


@hoertlehner sure, set :dev-http {8080 "classpath:foo"}


@chrislittle1986 :reload-strategy is not affected by using :deps true or not.


@thheller: thanks! Does :dev-http replace :devtools {:http-root "public" :http-port 8020}


yes, it replaced that quite some time ago


Thanks @thheller for the reply and for creating this cool tool! I probably used an incorrect term. I’m really looking for better NPM support, having to rely on CLJS is a drag. What I’m kind of worried is: how would our source code be affected if npm support becomes official by the CLJS compiler?


I’m probably not understanding how things actually work and asking non-sense but was worth the try 🙂


the method of including npm dependencies is an abtraction controlled via :js-provider. so should CLJS ever get "different" support its just another method you can select


Thanks again it seems I was making a big deal of it. It might be related to the fact the some years ago when I first saw shadow-cljs I thought it was some sort of cljs compiler fork


yeah the name seems to confuse a lot of people


but even if it became a compiler fork ... does that really matter as long as everything you write is still standard CLJS code that you can at any time compile with other tools?


you can emulate the npm support shadow-cljs has today in regular CLJS by using the webpack method


the non-standard things are cleary marked in the docs and you don't have to use them


I will definitely give it a try these days. Not having up-to-date npm deps is sometimes frustrating.


besides that as long as you don't use shadow-cljs specific features (there aren't that many) then you can just compile with the "default" cljs tools


@thheller I'm here for the same problem as @chrislittle1986 though I'd like to clarify a bit. We are using shadow-cljs inside of a monorepo. We have other pure Javascript libraries in that monorepo. For development purposes we have been using npm link to symlink the dependencies inside our node_modules and that has been working great! If we make a change to the Javascript library shadow-cljs would pick-up the changes via the symlink and recompile and everything was awesome! However, we recently switched to using tools.deps for our maven dependencies so we could the use :local provider and get the same setup for our Clojurescript libraries. It seems like enabling :deps true has in some way prevented shadow-cljs from picking up changes to our Javascript files and recompiling now. These seems strange to me and probably is something else but I'm not sure where else to look.


in general node_modules code is not hot-reloadable or only in a very limited way but I don't see how deps.edn affects it in any way


Is there any difference between watching changes to required .cljs file and watching changes to required .js files?


node_modules is watched differently yes but thats always the case. again not related to :deps true


Yep, you are right it appears to be a version thing. I bisected the change down to version 2.8.67 will pick up changes to .js files where as 2.8.68 no longers picks up changes to .js files


right yes I changed node_modules watching


since it was commonly watching way too many files that weren't hot-reloadable anyways


but yeah npm link behavior would likely change


Would it be difficult to restore but behind a configuration flag? We rely pretty heavily on this feature.


I can open an issue on GitHub and give it a go if you're open to an MR.


you rely on it how? the new logic only watches the package.json for modification (timestamp is enough) so "touch package.json" should be enough to trigger a shadow-cljs compile?


For example we have a Javascript library that we write all of our GraphQL queries in .graphql files. This library uses graphql-tag webpack-loader to compile those files into queries for ApolloClient (the GraphQL client we use) webpack watches for any changes to the .graphql files and will output new .js files which shadow-cljs read in from the node_modules directory (due to npm link) and would then reload any namespaces that use those compiled queries.


We can just constantly touch the package.json file but that's pretty much the equivalent of just re-running compile every time we make a change


what kind of code does this generate? why do you have to do this as a npm module?


if you open an issue I can take a look. I didn't consider that people would be actively working on npm packages while using them in shadow-cljs


so I might reconsider supporting that again but I need to think about it first


Okay, would an example setup in a repository help?


it was definitely causing issues for other people since checking thousands of files every second is quite a lot of work that is pointless 99% of the time 😛


examples always help yes


Cool, I will get that set up and then create an issue

Chris Little19:03:54

Are there options in shadow-cljs to tell it to watch a specific folder under node_modules? That wouldn't be ideal in our case, since we'd have to start maintaining a list of npm link'd packages, but it seems like we have to do that for the "local" overrides in deps.edn anyway


the only "difference" that deps.edn might have is that more code can come from local files vs .jar files


so if anything it might start reloading more?


Thanks again it seems I was making a big deal of it. It might be related to the fact the some years ago when I first saw shadow-cljs I thought it was some sort of cljs compiler fork


I just want to note that if even shadow-cljs hotreload feels slow (e.g. when iterating on an animation), putting the function call you want to play around with at the top-level then using a repl + load-file gives you amazing response times 🙂