@U5H74UNSF why do we need this if have already have a REPL, and e.g. https://github.com/borkdude/deflet? You can "debug" your build as you're writing it and use the code you wrote to "debug" as the final product

yeah, doesn’t get me the selectors/locators though

the inspector lets me drive the browser interactively and generates the test code for us

oh, right

including the locators at the right specificity

it’s pretty neat

then maybe you don't need to write any CLJS, just use what it produced?

you can load / wrap that code from nbb

yeah, considering that

https://playwright.dev/docs/debug

all this tooling is pretty great, uphill battle to replicate it, maybe better to just use nbb to talk to our api but stick to js for the browser tests

sure

these reports and traces also look pretty nice https://playwright.dev/docs/trace-viewer-intro

Maybe they have an API to let you plug in what language you want to generate, but not sure if it's worth it compared to the generated JS

yep

npx playwright codegen is so good and the reason we have typescript test files in our cljs project

what I tried to add at src/nbb/impl/main.cljs

(when (:print-classpath opts)
  (println (process/shell "bb" "print-deps" "--format" "classpath"))
  (js/process.exit 0))

what is process here?

I tried with both babaska.process and clojure.java.shell, for babashka.process I tried adding on deps.edn but didn't find the deps, not sure if I should do something else

you can look at impl/deps.cljs to see how to shell out to bb

babashka.process and clojure.java.shell don't work in CLJS

yeah, that was what I thought since runs on js, thanks will take a look

Works :)

I'm doing ATM

(println (.toString (cproc/execSync "bb --config nbb.edn print-deps --format classpath")))

config should be sufficient

nice, so I think it's done, I will try to add tests and send a PR, thanks!

I couldn't find a better way to test the shell-out https://github.com/babashka/nbb/pull/321

My first nbb PR :D

I think it would be useful to have the same API as with bb:

bb print-deps --format <classpath> | <deps>

Sounds good, is it ok to support only classpath format for now?

well I will only delegate to bb so I think it's ok to support both right now

yes, only classpath is ok

you can use babashka.cli to parse args

haven't looked at the code yet ;)

I think print-deps might print too much when going through bb though, it will print its own deps too and e.g. not promesa etc, I think?

hum, yeah, I think so

what you think nbb should print?

the deps that it has built-in, see the nbb deps.edn

Ah yeah, what's your suggestion of print those deps?

what do you mean?

I mean, the correct for nbb would be to print the deps from nbb's deps.edn right? but bb print-deps --format classpath would print bb deps which are not included in nbb IIUC

yeah

I think we need to include the deps.edn into the CLJS build via a macro

so we can print it later

bb print-deps --config <nbb-deps.edn-location> would probably work right?

yes

that will work, but it will not print the built-in deps

and it will also still print the built-in deps of bb

I see

> include the deps.edn into the CLJS build via a macro how can we do that, not sure I get how that will work

I think it might be better to not use bb print-deps after all. See nbb.impl.deps which extracts the dependencies of nbb.edn into .nbb/.cache/.blablabla and this is what nbb uses as its classpath. you can get this classpath with nbb.classpath/get-classpath

The only thing left is to add the built-in deps to the classpath

humm I see

so would be a merge of nbb.classpath/get-classpath + builtin deps that are in nbb's deps.edn

yeah

for the built-ins we can still use babashka, by doing:

(babashka.deps/add-deps {:deps {built-in-deps}}) + babashka.classpath/get-classpath

🤯

and then combine those

cool, I'll give it a try, I think I got it