Fork me on GitHub

I have never used bazel but I know someone did. Just forgot who or how


I can’t specify nrepl port via user config, right?


you should never ever specify a fixed port for nrepl


let it use a random port and read it from .shadow-cljs/nrepl.port in the project


if by user config you mean ~/.shadow-cljs/config.edn then no since that would start to conflict as soon as you run more than one shadow-cljs instance at the same time


The issue arose because the only Cursive wielding user in our project wanted to add a fixed port. But you are a Cursive user too, aren’t you, @thheller?


I am and Cursive is perfectly capable of using that file. Absolutely no use for a fixed port in Cursive




didn't even need the "specify custom file" there, but yeah 😄


In my project I do because I also use lein and don't want it to get confused. Otherwise the other option also works yes.


I'm running shadow-cljs watch, and am accessing my frontend via nginx -> my backend service (which serves up my index.html). My browser connects to shadow-cljs just fine, and code reloading works. However, CSS reloading isn't happening. Is there a reason for this, or could it be a bug? Is there a fix? Actually, scratch that. I restarted everything and now it works 🙂


hello, I am using bide ( to routing and this library makes a call to goog.isDefAndNotNull function. However, I got an error like this:

Execution error (TypeError) at (<cljs repl>:1).
goog.isDefAndNotNull is not a function
there is any additional config I need to setup to make this work on shadow-cljs side?


@iagwanderson that function was removed in the newer closure-library. bide will need to change that.


yeah they removed basically all the * functions over the past few years. we were stuck with a quite old closure-library version for a while due to those incompatibilities even in cljs.core. the new CLJS release (announcement still upcoming) fixed those but a lot of libraries still need adjustments for the newer version as well

🚀 1

or downgrade shadow-cljs to 2.11.26. 2.12.0 was the released with the new closure-library version


Hello. I'm trying to migrate some builds from lein-figwheel to shadow-cljs and fail at it :face_palm: Shadow-cljs doesn't find my namespace: The required namespace "data-request.core" is not available. I've slimed down my src/cljs/data_request/core.cljs to this:

(ns data-request.core)

(defn ^:export initialize [x]
  (prn x))
And my shadow-cljs.edn looks like this:
{:source-paths ["src/cljs/data_request"]
 :dependencies []
 :builds {:data-request {:target :browser
                         :modules {:main {:entries [data-request.core]}}
                         :output-dir "../output/dev/"
                         :asset-path "/cljs/output/dev/data-request_target"}}}
But still:
# yarn shadow-cljs watch data-request

yarn run v1.22.10
$ /webapp/cljs/admin/node_modules/.bin/shadow-cljs watch data-request
shadow-cljs - config: /webapp/cljs/admin/shadow-cljs.edn
shadow-cljs - updating dependencies
shadow-cljs - dependencies updated
shadow-cljs - server version: 2.12.1 running at 
shadow-cljs - nREPL server started on port 7890
shadow-cljs - watching build :data-request
[:data-request] Configuring build.
[:data-request] Compiling ...
[:data-request] Build failure:
The required namespace "data-request.core" is not available.


the ns data-request.core would be expected to be at <classpath-root>/data_request/core.cljs. Since your classpath root is src/cljs/data_request, it will be looking for src/cljs/data_request/data_request/core.cljs and not finding it


Doh 😉 I was pretty sure I tried that. Thanks 🙂


The :asset-path also looks incorrect. that should be the path under which you access the files over HTTP, that likely isn't :port/cljs/output/dev/data-request_target/main.js?


With figwheel, we were serving this through Rails and a middleware there was hooking things up. Is that still a good approach for shadow-cljs?


if it makes sense for you yes. they are still just plain static javascript files, no difference on that front


the code just needs to be able to connect back to the http://localhost:3450 server. dunno why you reconfigured that from the default 9630. the is only the webserver used for the UI and websockets. It does nothing regarding your other code.


also you want to avoid using a fixed :nrepl {:port ...} if you can. most editors nowadays support reading that port rom the generated .shadow-cljs/nrepl.port file instead


Hello! Trying to config the test runner, but running into some problems regarding namespace when trying to compile. Here’s the configs: project.clj

{:dependencies [[binaryage/devtools "1.0.2"]]
 :source-paths ["env/test" "test/src"]}
:lein {:profile "+dev,+test"}
{:dev {...}
  {:target     :node-test
   :output-to    "test/target/testable.js"
   :ns-regexp    "myapp\\..*"
   :autorun    true}}
And here’s the problem:
$ npx shadow-cljs watch test
[:test] Compiling ...
[:test] Build failure:
Resource does not have expected namespace
{:tag, :resource "src/myapp/runner.cljs", :expected-ns src.myapp.runner, :actual-ns myapp.runner}
Any ideas why it doesn’t accept the namespaces? It hasn’t been a problem with our previous test runner. A potentially relevant side note is that Cursive also complains in these files that the namespace is missing a src. (for example in (ns myapp.test.db ...) ) but it seems to me this shouldn’t be needed.


@emil.eriksson41 what are the :source-paths you have configured in project.clj? you do not need a "runner" for the tests, that is generated for you by the :node-test target.


Source paths are ["env/test" "test/src"] - some environment configuration variables, and then all the test files. File hierarchy is e.g. test/src/myapp/test/db.cljs You’re right, the runner file remained from old solution. After removing it, same problem remains but for other files (e.g :expected-ns src.myapp.test.api.transform, :actual-ns myapp.test.api.transform)


it looks like you have "test" on the classpath, which is the default when using lein via :test-paths ["test"]. You need to override that so the classpath doesn't contain duplicated entries.


but which shadow-cljs version is this with? either you are using a very old shadow-cljs version or something else is going on?


Using 2.11.18 right now. Looks like we didn’t have a :test-paths set in project.clj at all, so I tried setting it to ["test/src"] which seems to have solved the namespace issue! Now I get another error instead but it seems related to our own code.

Rob Knight16:04:28

It seems that the most recent Closure Compiler has removed the stripTypePrefixes compiler option 😞


they did indeed. it was always the absolute nuclear option anyways though 🙂

Rob Knight16:04:48

Yeah, now I need to figure out exactly what is adding 94kb of cljs.analyzer to my release build


there used to be a function for that but it broke a while back. really need to bring that back

Rob Knight16:04:53

Ah, but that would take all of the fun out of it 😄

Rob Knight16:04:12

Is that kind of information available anywhere, even if it's hard to get at? I don't mind hacking around


not in an easily accessible way no. really low level would be in the build-state from a build hook


from the CLJ REPL (eg. shadow-cljs clj-repl) you can call (def build-state (shadow/compile! :the-build))


you use (tap> build-state) and look at entire state in the shadow-cljs UI


do not try to print it from the REPL, it is way too large and will take forever 😉


there is a :compiler-env key and that has :cljs.analyzer/namespaces


if you really want to dig in that is the place to do it 😛

Rob Knight17:04:16

Is there a way of getting this information for a release build? My problem is that there is various spec-related stuff that I want in my dev builds, but not in my release builds.


there is a release! but just noticed that has a bad return value


but (shadow/release* (shadow/get-build-config :the-build) {}) should be ok


I have in deps.cljs in a library. oauth2-popup-flow has a few dev dependencies like typescript that are needed to compile it. It seems dev dependencies are somehow lost. So I had to add all transient dev dependencies of oauth2-popup-flow to my deps.cljs. Is this intended behavior?


npm packages generally contain the already compiled code and dev dependencies are used for THEIR development


they will generally not be used when you use the library so you adding those dependencies to deps.cljs seems like something you should absolutely not do. shadow-cljs will also never compile typescript for you so they'll like remain unused.


so yes, that is intended


I have seen a lot of npm libraries that build themselves on npm-install. I dont quite understand why it works in the library, but not via deps.cljs. I will have to investigate more.


I have not seen a single npm library do that? well maybe those with native dependencies but certainly not typescript


the library you asked about also seems to contain the compiled JS code as expected?[email protected]/index.js


it also doesn't contain any of the actual .ts code so it couldn't even compile itself?


never ever look at the git repo when looking at npm libraries. those never reflect how the library is actually distributed.


thanks a lot!

Neil Ashton17:04:36

Hey all! I’m having some issues with shadow-cljs’s build of a web worker. Within that web worker, I’m getting ReferenceError: window is not defined errors; it looks like it’s happening when this line runs,, as a result of my “shared” module calling SHADOW_ENV.evalLoad("cljsjs.jquery.js", …) because of another library’s jQuery dependency (namely castra.core’s). Has anyone else solved this problem in a project?

Neil Ashton17:04:16

Also, FWIW, I notice that when I explicitly define window at the top of the web worker’s compiled JS by adding var window =;, that problem goes away – but then I start to get a document is not defined error that seems to ultimately be caused by shadow.dom.js.


when building a web-worker it is your code (or depdencies of that) that must not load references using window


you also must configure the :module you are using as a web-worker via :web-worker true?


FWIW the goal should be to get the jquery out of the code loaded by the worker. you might do so by introducing an extra module somewhere in your graph.

Neil Ashton20:04:51

Yes, looks like that did it. Instead of having all modules depend directly on :shared, I inserted another module between :shared and those modules with jQuery dependencies. No more window-related errors. Thank you!

👍 1