Hey there! Would it be possible to somehow run :browser-test and :node-test targets within the same shadow watch process? If I do this at the moment, shadow looks up for namespaces with "-test$" regexp and node-specific tests land in the browser-test target. So the options would be either to run separate shadow processes with different classpaths, or to have more precise namespace naming convention for the regexps (like "$browser([\w-\.]+)test$" and "$node([\w-\.]+)test$")?

@me1676 if you structure your namespaces just right that might be enough too? your.app.frontend.foo-test vs your.app.backend.foo-test or your.app.whatever.foo-test?

happy to add more filtering options if needed too. you also have the option to specify namespaces directly instead of just a regexp

just :namespaces [foo.bar-test ...] and :exclude #{foo.dummy-test} also exists

Ahh that’s nice, didn’t know about :namespaces and :exclude 🙂

if :namespaces is used :ns-regexp has no effect though

Do you think it would be possible to add something like :filepath-regexp to filter based on the file paths?

sure but what would that do?

I mean it doesn't make sense in how I organize my tests so I first need to understand how you organize your tests to make a useful impl 😛

Alright, I’ll try explain. Source directories: src/browser — Namespaces pitch.app., pitch.components., pitch.integrations., pitch.something-else. src/node — Namespaces pitch.node., pitch.something-else. Test directories: test/browser — Namespaces pitch.app.-test, pitch.components.-test, pitch.integrations.-test, pitch.something-else.-test test/node — Namespaces pitch.node.-test, pitch.something-else.-test Unfortunately just by looking at the namespace it’s not possible to understand to if it belongs to browser or node bundle, that’s why ns-regexp can’t work in our case. However, if we can apply a regexp to the filepath of a cljs file, then it becomes easy

lein shadow watch app devcards should work and only give you one JVM

@thheller, do you have any advice on how to enable data_readers.cljc for a self hosted build? here is the shadow-cljs.edn: https://github.com/sritchie/maria/blob/sritchie/last_attempt/editor/shadow-cljs.edn

I found a reference on the site about the compiler option to enable this (and your footgun warning 🙂 ), but it seems to not work when I add :compiler-options {:data-readers true} to the bootstrap build

"not work" means, grabbing the error...

this does indeed work at a repl with data_readers.cljc loaded, and I can see that it did make it into the jar

@sritchie09 for self-hosted that you are compiling you need to handle data-readers in the compiler yourself. nothing shadow-cljs can do to help that.

at least I don't think so. no clue really.

here be dragons!

thanks for the note, @thheller, I'll see if I can figure out how to get it working down the road

and write down my lessons from the mines

Sorry to double-post, but I think I asked this after-hours last night and missed everyone. I'm rather stuck on it, so fingers crossed there's an easy answer:

How should I use a CommonJS/ES6 namespace in a ClojureScript macro? I'm following @thheller's https://code.thheller.com/blog/shadow-cljs/2019/10/12/clojurescript-macros.html, which suggests that `defmacro` within a .`clj` file should use a fully-qualified namespace.  But going by the shadow-cljs User Guide's https://shadow-cljs.github.io/docs/UsersGuide.html#_using_npm_packages, I don't see how to use a fully-qualified namespace with CommonJS/ES6 imports, because they are referred to with strings as in `(:require ["module-name"])`.

@neil.hansen.31 I recommend that you don't access npm packages directly but instead create a helper fn that does so and call that from the macro

Thanks @thheller, I'll try that right now.

That totally worked, I should have thought of that. Thanks!

@me1676 in 2.11.1 you can specify :test-paths ["test/node"] in the test build configs which will only make it use namespaces matching ns-regexp from those paths. they need to be classpath roots and already on the classpath though. maybe that works.