hey folks 👋 I'm having issues with cider-connect-cljs on a shadow-cljs project. I'm not sure this is the right channel to post my question, but I'm in the hope that someone else here would have faced the same issue before and will point me in the right direction or just say the right channel :) I noticed that when I connect Emacs to a running nrepl using cider-connect-cljs, my REPL doesn't work the same way as it does when I use cider-jack-in-cljs for instance. To be honest, I don't know if cider-connect-cljs and cider-jack-in-cljs have different user experiences but I assume they don't. I have recorded a video to try to explain the problem a bit better. What you can see is: - Run shadow-cljs watch to have the app and a REPL running - Use cider-connect-cljs to connect Emacs on the running REPL - Try to set the current namespace using cider-repl-set-ns - Try to eval a fn using cider-eval-last-sexp The project you see on the video is here https://github.com/wcalderipe/cljs-playground (there's nothing special). Versions: macOS Big Sur 11.2.2 Emacs 27.1 Cider latest commit on master (I'm using straight.el)

Not sure what dependency that is causing an issue here but… I am getting an issue with goog.isBoolean not being defined. This is right now only happening in my karma build. And only in the cljs-oops library: https://github.com/binaryage/cljs-oops It is getting called by the oops function (in js terms) Object.oops$core$validate_object_access_dynamically I took a look at the generated output javascript file and I see that stuff like goog.isObject gets assigned and even goog.isDateLike which I don’t think I am directly touching in this project. But there is no similar assign to goog.isBoolean in the output file so it looks like it got pruned. My karma build parameters are: {:target :karma :output-to "target/test-ci.js" :compiler-options {:devcards true :infer-externs true :output-feature-set :es-next :warnings {:redef-in-file false :infer-warning false} :pretty-print true :pseudo-names true}}

@slack1003 those predicate functions were removed from the closure-library, see the CLJS release announcement https://clojurescript.org/news/2021-04-06-release Noteworthy & Breaking Changes

oops got updated

so fixed by moving to 0.7.1

thanks

Is there a way to use something like the leiningen test selectors with the karma build?

All I really want to do is exclude running certain tests that were tagged with the relevant metadata. I have a bunch of webgpu tests which only run in Chrome Canary (and similar) which bail in regular headless chrome. There are work arounds like just checking if various js globals are defined. But I would prefer to just tag relevant namespaces and tests with some metadata and let the test runner figure it out. Since I am also targeting regular clojure too I tend to just run the tests via clojure when I am developing

that is not yet supported no. I have some changes regarding testing planned but didn't get around to them yet. might be a while too.

alright. Do you have some guidance on adding a new target? I just need a hint or two. Is it possible to supply a new target without replacing shadow-cljs with a fork?

great job on the whole system though! It is really nice to work with. This really is the only real sticking point I have come up against which I see I can get around with that regex or snooping for javascript globals

yes you can write targets without changing shadow-cljs. in fact all targets are implemented that way. https://github.com/thheller/shadow-cljs/tree/master/src/main/shadow/build/targets

eg. https://github.com/thheller/shadow-cljs/blob/master/src/main/shadow/build/targets/karma.clj

you can also specify :target your.own-target

that ns would then need to declare a (defn process [build-state] build-state)

none of that is documented in particular though, so will require some digging

and it’ll find it in my project as long as the process bit is there?

can be in your project or a library yes, as long as that ns is on the classpath

its just a regular CLJ namespace and the process function is called repeatedly for each step

:browser is by far the most complicated target but karma pretty straightforward

k thanks for the help there! I’ll take a look. may also just take the shortcut 🙂

fwiw the node-test target already has some configuration options

https://github.com/thheller/shadow-cljs/blob/master/src/main/shadow/test/node.cljs

or rather runtime options configuring which tests to run