Clojurians Log v2

I was looking for just this a few months ago. Thanks for releasing! Are you following the Duct reloading scheme, so that Duct controls when the CLJS source is reloaded?

The updates to the cljs source are done by shadow because AFAIK it doesn't provide an API so that we can do this programmatically. If you are willing to investigate further I will be glad to help in the process.

Now that I think about it shadow has this kinda built in. You can pass to a build :devtools {:watch-options {:autobuild false}} and then from the repl call (shadow.cljs.devtools.api/watch-compile-all!) to trigger a compilation of all your builds. Is that something you would like to see done automatically by the duct module? say that if for a build :autobuild is false then (reset) will do the (shadow.cljs.devtools.api/watch-compile-all!) thing?

No strong preference, but I'm curious about the question and any experience reports. I haven't used Duct and/or Clojurescript in a while, so I'm not certain what behavior would be best. I do remember recalling Luminus starting to become really heavy once auto-compiling CLJS was turned on, which slowed down my REPL reduced developer experience somewhat.

I have no experience with Luminus but I know that shadow is pretty fast. I am working on a sizable project and the compile times are barely noticeable. I actually use the autobuild and I am pretty happy

You can add a :duct.profile/test profile to your configuration with the overrides you need, and only activate that in tests.

Sorry for the stupid question, but how do I do that? I'm rather new to Clojure. I've got a profile being used for tests, but not sure how to replace the implementation of the middleware and not the routes.

I'm not sure if that is too specific to the implementation to be of help

You can change the arguments passed into the implementation (init-key) of your middleware. :duct.profile/test can use other keys instead of your prod implementation. Then the middleware implementation can look at those keys and do whatever it needs to do based on that

When the test profile and base profiles are merged together, any configuration in the test profile overrides configuration in the base profile, similarly to how Leiningen profiles work.

Simple example (just pseudo code, not tested). Skip the auth middleware if test is running.

Not sure if this is really good practice, since you're putting test related logic in the middleware

However, if I'm not mistaken. This is how you could add arguments to keys in specific profiles