Clojurians Log v2

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

pom.xml works fine, you do NOT need to use deps.edn or project.clj for Cursive. Regardless of what you use though Cursive does not support JS dependencies as of now

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

Awesome.

Thanks!

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 🙂

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

hello, I am using bide (https://github.com/funcool/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

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

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.

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))

{: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"}}}

# 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 <http://localhost:3450>
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 <http://localhost>: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

thanks @thheller!

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

:test
{:dependencies [[binaryage/devtools "1.0.2"]]
 :source-paths ["env/test" "test/src"]}

:lein {:profile "+dev,+test"}
…
:builds
{:dev {...}
:test 
  {:target     :node-test
   :output-to    "test/target/testable.js"
   :ns-regexp    "myapp\\..*"
   :autorun    true}}

$ npx shadow-cljs watch test
…
[:test] Compiling ...
[:test] Build failure:
Resource does not have expected namespace
{:tag :shadow.build.resolve/unexpected-ns, :resource "src/myapp/runner.cljs", :expected-ns src.myapp.runner, :actual-ns myapp.runner}

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

for those interested, this is the commit from closure-library https://github.com/google/closure-library/commit/9325ce1bbebcfe8c7aa54f8342959c73a1762a77

yeah they removed basically all the <http://goog.is|goog.is>* 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

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 🙂

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

https://github.com/thheller/shadow-cljs/issues/865 😉

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

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

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 😛

Thanks 🙂

I have https://www.npmjs.com/package/@ricokahler/oauth2-popup-flow 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

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.

Thanks @thheller

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.

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, https://github.com/thheller/shadow-cljs/blob/3e559b8f9ea80cc1ad1c51772fe4aa8c099a1159/src/main/shadow/js.js#L82, 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?

Also, FWIW, I notice that when I explicitly define window at the top of the web worker’s compiled JS by adding var window = goog.global;, 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.

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? https://unpkg.com/@ricokahler/oauth2-popup-flow@2.0.0-alpha.1/index.js

https://unpkg.com/browse/@ricokahler/oauth2-popup-flow@2.0.0-alpha.1/

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.

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?

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

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

Thanks

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.

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!

thanks a lot!