Newbie question: let's say I'm using only shadow-cljs and reagent, how do I hook up TailwindCSS to automaticaly process my css files (and trigger live reload etc)? Do I still need to use something like webpacker/browserify?

I'm using a third party npm library in my project (BabylonJS) and the compilation breaks if I try to update it to the latest version. The offending typescript code does this: public dispose(disposeAll = true): void { super.dispose(disposeAll); if (this._depthRenderer && disposeAll) { delete this._depthRenderer.getDepthMap().getScene()?._depthRenderer[this._depthRendererId]; this._depthRenderer.dispose(); this._depthRenderer = null; } } and the error I get is: "Invalid delete operand. Only properties can be deleted." If I understand correctly the issue is the usage of the "?." operator together with "delete" and it can be fixed by using an if statement instead. However I'd rather avoid patching the library. Do I have other options here like maybe a compiler flag to pass to shadow-cljs ?

shadow-cljs does not support typescript so you are looking at the wrong code

look at the code that is actually getting included

not the typescript sources. npm likely contains the transpiled code.

DepthReducer.prototype.dispose = function (disposeAll) { if (disposeAll === void 0) { disposeAll = true; } var _a; _super.prototype.dispose.call(this, disposeAll); if (this._depthRenderer && disposeAll) { if(this._depthRenderer.getDepthMap().getScene()) delete this._depthRenderer.getDepthMap().getScene()._depthRenderer[this._depthRendererId]; this._depthRenderer.dispose(); this._depthRenderer = null; } };

this is the corresponding JS code

either thats an invalid use of delete or a bug in the closure compiler

not much I can do in shadow-cljs

looks fine to me, dunno why it complains

wouldn't be the first time the closure-compiler found an actual bug in a library though

so this might actually be invalid and just nobody ever runs into that actual code

yes, very possible indeed. I'll try to convince the library authors to patch it then.

Thanks

Can the version of the closure compiler used by shadow-cljs be changed ?

Sorry I realize the JS code above is not the offending one. It's the code I get after manually patching it. The offending code is:

DepthReducer.prototype.dispose = function (disposeAll) { if (disposeAll === void 0) { disposeAll = true; } var _a; _super.prototype.dispose.call(this, disposeAll); if (this._depthRenderer && disposeAll) { delete ((_a = this._depthRenderer.getDepthMap().getScene()) === null || _a === void 0 ? void 0 : _a._depthRenderer[this._depthRendererId]); this._depthRenderer.dispose(); this._depthRenderer = null; } };

right yeah that looks invalid

I'm playing with the lifecycle-hooks. And putting in the shadow-cljs.edn the following hook: {:devtools {:after-load my-devtools/reload}. But the hook is not called (`reloading code but no :after-load hooks are configured!`). I imagine that because I'm not requiring my namespace (`my-devtools`) anywhere in my code it is not running the function. Because, when I add a require into my main-file it runs the hook. Is this the expected behavior? I would think that shadow-cljs would require que namespace specified in the devtools.

it is expected that the namespaces are actually requireed by you

otherwise you should use :devtools {:preloads [your.ns.with-hooks]}

and in there do (defn ^:dev/after-load the-hook [] ...)

hummm, got it

thanks!

not sure what you mean by requiring it runs the hook

because that only happens if you actuall call the hook yourself

Oh, sorry, I wasn't clear. When I add (:require [my-devtools]) at some file that is compiled and loaded by shadow and then trigger the reload by editing some file, the hook runs.

I guess it could add the namespaces to the build automatically but typically people have the hooks directly in the main ns

humm, the hook I'm injecting is hooks that I use in my personal development flow. I'm injecting it dynamically by loading the config-map, editting it and then giving it to shadow to watch it. The other developers in the project don't use these same hooks as I do. That is why I don't put these hooks in the main ns.

Using the preloads worked well for me (just tried it), don't know if it is necessary to add the namespaces to the build automatically. Maybe put in the documentation that the namespace must be required somewhere

you can do shadow-cljs watch app --config-merge "{:devtools {:preloads [hooks.that.only.i-want]}"

yes, that is basically what I'm doing, but I'm doing it inside a clojure file

I start the server and the watch command through clojure using the shadow.cljs.devtools.api .

This is the function that I use.

(defn watch-with-profile
  [build-id profile]
  (println "Running " build-id " with profile " profile)
  (-> (shadow.config/get-build! build-id)
      (assoc :profile profile)
      set-devtools-hooks
      shadow.api/watch))

you can also do the config merge there

(shadow.api/watch :the-build {:config-merge [{:devtools {:preloads '[the.extra]}}]})

but your way works too

oh, didn't know that shadow.api/watch had this option, cool!

Thanks for the help! 😄

Hey all, I'm trying to run tests in my shadow-cljs project via the CLI. I've created a build called :cljs-tests with the following config:

{:target :node-test
            :js-options {:node-modules-dir "../"}
            :output-to "out/node-tests.js"
            :autorun true
            :main my-app-name.events-test/start}

(defn start []
  (cljs.test/run-tests))

aborted par-compile, [:shadow.build.classpath/resource "my_app_name/events_test.cljs"] still waiting for #{my-app-name.events-test}
{:aborted [:shadow.build.classpath/resource "my_app_name/events_test.cljs"], :pending #{my-app-name.events-test}}
ExceptionInfo: aborted par-compile, [:shadow.build.classpath/resource "my_app_name/events_test.cljs"] still waiting for #{my-app-name.events-test}
	shadow.build.compiler/par-compile-one (compiler.clj:854)
	shadow.build.compiler/par-compile-one (compiler.clj:819)
	shadow.build.compiler/par-compile-cljs-sources/fn--12733/iter--12755--12759/fn--12760/fn--12761/fn--12762 (compiler.clj:937)
	clojure.core/apply (core.clj:665)
	clojure.core/with-bindings* (core.clj:1973)
	clojure.core/with-bindings* (core.clj:1973)
	clojure.core/apply (core.clj:669)
	clojure.core/bound-fn*/fn--5734 (core.clj:2003)
	java.util.concurrent.FutureTask.run (FutureTask.java:264)
	java.util.concurrent.ThreadPoolExecutor.runWorker (ThreadPoolExecutor.java:1128)
	java.util.concurrent.ThreadPoolExecutor$Worker.run (ThreadPoolExecutor.java:628)
	java.lang.Thread.run (Thread.java:834)

if you are just calling run-tests then you don't need :main at all because its what it does by default?