if you must have one module per namespace then :npm-module is the way to go

:esm also really expects exports, otherwise its pretty useless in an interop scenario

but you'd do it like this

{:target :esm
 :modules {:base {:entries []}
           :app.mod1 {:entries [app.mod1] :depends-on #{:base}}
           :app.mod2 {:entries [app.mod2] :depends-on #{:base}}}}

so all the shared stuff goes into :base

ah

Guess I could hack a bit with the build hooks to scan the -test$ namespaces, then rewrite the :modules config to the above format

as I said. if you must have one namespace per file

then you should really only consider :npm-module

it is possible :esm. but far too much trouble doing everything manually

I have some time in a bit, so I can see if I can figure out your :npm-module problem

Thx! I'll try with npm-module for now.

btw :npm-module doesn't support browser runtimes, right?

I inspected the :worker-info key, and it's nil https://github.com/thheller/shadow-cljs/blob/756d3fc/src/main/shadow/build/targets/npm_module.clj#L69-L70

maybe you should start explaining what you are trying to do exactly?

:npm-module supports browsers, but only with more processing by third party tools as browser can't load commonjs files otherwise

there was a typo, I wanted to say "not support browser runtimes"

So I uses the :npm-module to output things like app.foo-test.cljs to app.foo-test.js and cypress test running would load it and execute it in the browser

ok

and why are you looking into worker-info?

I'm following the logic of the code to check why the browser page doesn't connect back to shadow-cljs as a runtime, maybe I'm looking at the wrong places

btw the :preloads is also not picked up in npm-modules

why do you want the runtime to connect back? tests and repls usually don't play well with each other

I also do not know how cypress handles runtimes and re-running tests

so, if you just want a REPL but let the tests run on their own I recommend running a separate shadow-cljs browser-repl or so

> tests and repls usually don't play well with each other yeah most time they don't, but in my case it's a pretty good match. With the :esm target I can use shadow-cljs's reload for fast test-rerunning

e.g. in ^:dev/after-load to kick a re-run

preloads and runtimes are a bit more complicated with :npm-module since there is no controlled entry point

since you can just load any namespace via JS

which is much faster than the builtin liveReload of cypress (which comes from webpack)

so you'd have something like require("./cljs-out/your.preload") in some prepended configuration or so

require("./cljs-out/shadow.cljs.devtools.client.browser") is the ns for the REPL/hot-reload runtime

:thinking_face:

Thanks for the tips, I'll think about it. Maybe I'll simply go the way of using hooks to crunch the esm modules config like the one you mentioned above

{:target :esm
 :modules {:base {:entries []}
           :app.mod1 {:entries [app.mod1] :depends-on #{:base}}
           :app.mod2 {:entries [app.mod2] :depends-on #{:base}}}}

hooks can't do that

maybe :browser-test works with cypress? I really never looked into cypress much

probably not, cypress has its own tests runner (one based on mocha) so tests have to be defined with mocha's primitives

well you can define your own runner with :browser-test. doesn't have to be cljs.test

but there would be a bunch of other stuff to wire up together, assertions, matchers, etc. so that's an another rabbit hole. Beside cypress is really a totally different beast in conducting the tests, so I'd rather avoid it.

I really know very little about cypress and how it loads things, so really can't comment much from the cypress side

thats not really what I'm talking about there

:browser-test just generates JS, with the assumption that it is executed in a browser environment

it makes no further assumptions whatsoever

however you use cypress now you'd use it then?

I assume there is some kind of npm package you import?

ah right

no npm package, all stuff is injected into the window object by cypress

I'll definitely try that

do you have an example cypress setup?

like with :npm-module?

I'll create a repro today

I do remember trying something with cypress, but can't remember how far I got

It's pretty fascinating for doing react component testing. Otherwiser shadow's builtin browser-test is great enough for normal frontend unit tests

Being a js land tool it's by nature not a native fit for cljs, e.g. assert matchers for cljs data structures has to be custom registered

but once these rough egdes are smoothed it would be like a dream land for component based TDD

oh right it was one of those things that expects files in certain locations and so on

https://clojurians.slack.com/archives/C012GLC2SAZ/p1675775943518429?thread_ts=1675503454.655369&cid=C012GLC2SAZ

This is what I'm using cypress for, i.e. component testing

can't see what you are pressing. do you just save the file and cypress triggers running it or how does cypress get the new results?

or is cypress not watching at all and it just runs via js/it ...?

I can see shadow-cljs reloading something, but can't tell if cypress does anything 😛

Well it's a "customized" version of cypress. The official cypress would actually reload the page completely each time the test ns is rebuilt.

ah

is that configurable or actually hacking the npm package?

not configurable at all, but hacking the bundled js file in cypress electron app

hehe

I now remember why I abandoned looking into cypress more

the bundler configuration seems hardcoded to webpack/vite and can't be extended/replaced

it does supports custom devserver, but the protocol is not publicly documented

https://docs.cypress.io/guides/component-testing/component-framework-configuration#Custom-Dev-Server

ah, maybe that can be used for something

do you maybe have a clue what JS provides the describe it etc functions?

I have something running but I don't know where to get those from 😛

alright, found them

now we are getting somewhere 😉

its mocha

(def cy js/parent.Cypress)
(.onSpecWindow cy js/window #js [])
(.action cy "app:window:before:load" js/window)

seems to make everything work, but I can do better I think

I got it running completely with hot-reload and without vite/webpack

or any other hacks to the electron app

will try some more later but looks promising now. no more hacks 😉

👏

Just to confirm, you are playing with cypress component test, not e2e test, right?

yes, I played with component tests but abandoned it after discovering that the same trick cannot be done for e2e

and I couldn't figure out how to tell cypress to re-run the test after a hot-reload. since there is no documentation for any of this, at least nothing I could find

got tired of reverse engineering the webpack integration

I'm sure its just a dumb function call somewhere but I couldn't find it

For e2e it's simple

(defn ^:dev/before-load click-cypress-ui-restart-button
  []
  (when-not (= js/window.parent js/window)
    (-> (js/window.parent.document.querySelector "button.restart")
        .click)))

emm, on a second thought I agree it might have greater benefit than I have estimated if we have hot reloading in e2e tests, e.g. we can skip lots of time consuming fixtures like logins, cleanups etc. :thinking_face:

e2e can't replace the bundler though

there is no devServer option equivalent as far as I can tell

so it always uses webpack no matter what

yeah it would be more complex than CT. In CT there are two windows: top (cypress UI) & specWindow (where it/describe etc. and app code runs)

In e2e there are 3: top (cypress UI), specWindow (where it/describe etc. runs), and the app iframe