Fork me on GitHub

We’re requiring a js file like so: ["/graphql/subscriptions" :as subscriptions] It has an assignment like:

export const onCreateBag = 
  subscription OnCreateBag {
Works fine in dev, but on release (:advanced) the onCreateBag gets munged to $onCreateBag$: and we can’t really use it as a key. This only became a problem from shadow-cljs 2.9.6 onward. (Same code works in 2.9.6 but not on any version after that including 2.10.9) Is there an easy way to tell shadow not to munge that? The only other thing unusual is the graphql/subscripitions.js is being required from a Clj dependency of another library as a git dependency in deps.edn


On a side note, is there an easy way to run a release build locally without setting up a whole webserver environment?


@rberger what kind of JS is that? am I missing something or is this processed in any way? this isn't valid JS subscription OnCreateBag {?


why do you have pseudo-names activated? or is that just to show that it is getting renamed?


I'm surprised that it wasn't getting renamed previously. It should always been renamed but if it wasn't that was a bug.


in which context are you relying on the name? if you are passing the whole ns as an object to something than that is something you shouldn't be doing in the first place


I just put a snippet for the js. But this evening we re-evaluated what we were doing and realized we didn’t need this in JS and switched it all to clojurescript and EDN. So our problem is solved by removing those JS files and replacing with cljs. The use case was a bit funky. The JS files were being generated by CI from some authoritative schema in one project / repo and we needed to get them on the classpath of other projects/repos. I had built the image with --debug on so it was generating psuedo-names to help us figure out where the problem was originally. The one other JS file that we did need to have (`aws-exports.js`) is importing fine. The main weird thing was it all worked in 2.9.6 and earlier. If you want me to gather any other info, let me know.


@rberger well it should have always worked like it does now. the renaming is intentional. you can add externs to stop the renaming. not quite sure why it wasn't renamed before


Yeah, I was wondering if externs would have been the correct answer if we were to continue with that path.


Is there an easy way to test release / :advanced compile in the local environment?


I don't know what your setup is. I run shadow-cljs release whatever locally constantly.


Right that builds the release, but if I wanted to run it without some other setup?


IE run it like things run in dev but obviously not with all the interactivity


I cannot possibly answer that. I design my dev builds to be as close to release as possible so I can just switch between them locally without issue.


but I have no clue what your code does so that might not be as easy for you


I guess I’m asking is there a way to use the shadow-cljs http server to run the release build


if you just need a static server sure. just run shadow-cljs server seperately and keep it running.


Ok, I’ll play around with that. Thanks


You mentioned that snowpack was one of the triggers for this. Is there some usable relationship between cljs/shadow-cljs and snowpack for doing cljs development?

Chris McCormick13:06:37

[shadow.esm :refer (dynamic-import)]


don't look at the implementation 😉


edit: nevermind :D


Hi! I'm using cljs.test and playing with helix and integrating with some npm react library components. 1. How do you run tests in intellij cursive repl when using shadow-cljs? 2. What does it mean by "node REPL"? Is it enough to run tests that needs browser functionality, like simulating click events (I'm not talking about webdriver or opening real browser here. In JS land, there js-dom I'm looking into this guides now, but still struggling to digest the content. PS: I've tried the :browser-test option before, I'm just exploring other option to see which one works well for me.


@jaime.sangcap Good luck. I'm not sure about incorporating testing into shadow-cljs but i would recommend getting them to run from the command line.. incorporating them into intellij later will be simple (in theory)


if my project uses deps: true, and my deps file includes a library via :local/root "../lib-name", does shadow handle the installing of that libraries package.json file? I’m trying to figure out how to package and deploy that library for consumption, and unsure if I need to npm install and bundle it. Sorry if the question is super basic


@haywood it does not look at the package.json no. the library can include a deps.cljs with {:npm-deps {"foo" "version"}} in one of its :paths. those will be installed.

Felipe Marques16:06:20

I was reading about the deps.cljs. How is it added to the JAR? there is any extra step to do it or just using depstar would do it?


no clue what depstar does. it should just put the file in it automatically, just like any other source file.

Felipe Marques16:06:16

oh, so it should be inside a folder like src for example?


genius, thanks!



(ns demo.esm.a
  (:require ["" :as x]))
How is that? And about dependencies?


shadow-cljs will take care about download it?


no, your browser does


huge 1️⃣ on supporting native ESM via CLJS. really glad you’re willing to take on the work to provide us with that, thheller lisphug


well not sure if I will take on the compiler rewrite to emit esm directly 😛


but this works well enough that it was worth publishing


of course, but there are measures in between that and not supporting it, like you have already done 😄

Eric Ihli18:06:48

:modules {:shared
                           {:entries []}
                           {:init-fn app.client/init
                            :depends-on #{:shared}}
                           {:init-fn app.worker/init
                            :depends-on #{:shared}
                            :web-worker :true}}
                 :devtools {:after-load app.client/refresh
                            :browser-inject :main
                            :preloads [com.fulcrologic.fulcro.inspect.preload]}}
I'm trying to test out web workers. I'm getting an error with the above because the preload expects to have access to document. Is there a way to preload at the module-level rather than the build-level? I also tried splitting the web worker module into a completely separate build, but that resulted in an error about goog.debug.Error (for example) already being declared. Perhaps the answer is still multiple builds, but there's something else I need to do to limit the output of the web-worker build? Or wrap the preload in something that checks its environment?


@ericihli just move the :preloads to the :main module. they can be specified per module

🤙 6

You mentioned that snowpack was one of the triggers for this. Is there some usable relationship between cljs/shadow-cljs and snowpack for doing cljs development?


you can use it to handle npm dependencies instead of shadow


I mostly like it because it pushes ESM


and I like what they are doing over what webpack is doing