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)

idk, why shadow-cljs even exists, if you can do this : https://github.com/davesann/cljs-hash/blob/master/src/cljs_hash/md5.cljs#L5-L10

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

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

who uses shadow-cljs with devcards?

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)

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

@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

Regarding https://shadow-cljs.github.io/docs/UsersGuide.html#_requiring_js

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

@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? 😄

@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 https://polyfill.io/v3/ if you want to inject the polyfills only for ie

ah, cool. I'll try that then

thanks!

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

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

https://twitter.com/JacekSchae/status/1235171128441819137

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.

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

?

https://shadow-cljs.github.io/docs/UsersGuide.html#dev-http

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

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

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?