@thheller regarding testing I was really wanting to check that I couldn’t ‘program’ that behaviour in some way from the available tools

you can with the karma or browser-test stuff

(original question … can I run tests on node,js after a file has changed?)

but for node not yet

ok, fair enough …. like I say I can wait if you have something in the works

you can use anything that watches files really

I might end up installing another set of tools but would rather avoid it if poss

that’s true

https://github.com/remy/nodemon also works

the chokidar thing works well enough and just just an yarn add chokidar-cli --dev away

ok, thanks for the options

can I link that into the shadow-cljs server

or do I just kick off a build / node test?

(with chokidar)

(assuming the latter)

you can run any clojure code via shadow-cljs clj-run some.ns/fn

so you could write a clojure fn that starts the chokidar process

or even just do it in pure clojure without chokidar

@raymcdermott what do you usually use to do this? maybe I can steal some ideas.

honestly I usually just use cursive and run the tests as I go along in the REPL

but that doesn’t work so well for CLJS

yeah same here. I do that all the time for CLJ. probably not doing many tests for CLJS since I can't do it there

in short, I’ve got nothing 😉

what I can offer you is that I just add a simple option that just runs node when a build completes

@raymcdermott in 2.2.6 you can do

{:target :node-test
 :autorun true
 :output-to "out/demo-test-node/script.js"}

just runs node out/demo-test-node/script.js when the build completes

that would be plenty good enough

yeah seemed silly to use another tool for this

you can use :ns-regexp "some.ns-test" to only run the test ns you care about (instead of all -test)

esp since you have all the mechanics there already

there is some backstory to testing https://github.com/thheller/shadow-cljs/issues/57. so I had the autorun thing before but removed it because it didn't make sense in many other testing scenarios (eg. browser-test, karma). but now that they are different targets it really makes sense for :node-test

wow, nice

the thing I'm working on is a gui that lets you select which test-ns or singular test you care about

and then auto runs those in the browser or node

too many plans not enough time though 😉

:autorun should be an ok temp solution

on a purely selfish note, works for me 🙂

so assuming this…

what does the autorun? the build server watching the files?

whatever is running the watch

in other words would now shadow-cljs watch script be enough?

yep

do you have an idea when will that be available?

now with the 2.2.6 release

so I can just npm update … cool!

yep

oh wait shadow-cljs watch script would not be enough. shadow-cljs watch script test would. or second shadow-cljs watch test process

but I guess you meant watch test

ok, I’ll give it a spin

what also works is making a REPL command in Cursive for (shadow.cljs.devtools.api/compile :test)

then bind it to a key to run tests on demand rather than watch

ok, good to know - I’ll try that out too

hmmm nothing happening, watch seems to do nothing

even on standard builds

@raymcdermott btw :optimizations only applies to release builds. so :none is actually invalid. :none is enforced for watch and compile always so you do not need to set it to :none ever.

do I have to do a standard build first?

did you restart the server? after updating?

I’ll shut up

there might be an issue with the output and where it ends up

shadow-cljs - error ENOENT: no such file or directory, open '.shadow-cljs/logging.properties'

hmm odd. this was supposed to be fixed.

seems like it needs something new

what did you run?

shadow-cljs watch script test

and there really is no .shadow-cljs/logging.properties?

wrong folder!

oh. its supposed to be smart about that

oh well, in the top dir it’s working

next version it will work in nested folders as well 😉

I feel less dumb now 🙂

if I only use semantic-ui (seems to work well with the default compiler) would you still recommend going with shadow-cljs for the project ?

of course!

why would you want to run anything else 😉

🙂

@thheller we previous discussed not embedding shadow into a running project, If I used something like https://github.com/RutledgePaulV/clj-embed except without the isolation (you can access cljs/clj files from the parent classloader) do you see any reason why this would be ill advised?

its perfectly fine to embed shadow in a project. I just don't recommend doing so since you are then in charge of resolving conflicts and such and the tool can't help you with that.

clj-embed you might as well start a new JVM since you'll be paying the full startup cost for the isolation

you can't not-isolate the clojure runtime

you can't "fork" it

The benefit is simpler running for developers, without the conflicts. The startup cost isn't what I'm avoiding, it's the complex "start this, then that". Hmm, I will have to ensure that piggieback is happy to work cross-classloader. I'm not certain it will be.

start one thing for clojure and another thing for clojurescript seems perfectly reasonable

Sorry, I was referring to being able to access the parent classloader. I know clojure.lang.RT must be isolated.

you can't share the parent classloader

clojure just doesn't work this way

I think we're misunderstanding each other. I'm referring to having clj-embed have an embedded version of clojure, but being able to access files on the classpath of the parent, so that cljs compilation can happen as normal.

but the clojure stuff does not need the CLJS deps

No, that's correct.

clj-embed also doesn't allow using the parent classloader IIRC?

I guess I don't really understand what your goal is

It doesn't, but the code is relatively short, and changing that is simply switching a flag.

if you expose the parent classloader you have to deal with the same conflicts you'd have when just embedding

yes but this flag is what makes it work in the first place

Not quite, because the local classloader gets priority.

if you switch it nothing works anymore

The different version of immutant isn't loaded into the nested container, as the local one gets priority.

Essentially, the idea is to minimize friction to running the project. Having the cljs load with cider's jack-in is very useful for emacs users who are used to that. Same for ProtoREPL's "Start REPL" etc.

I honestly don't know what a good approach for all of this is. All tools seem to treat CLJS like CLJ but it just isn't the same. Things work differently in almost all aspects.

so sure you can all do it over one process just fine. the only downside is having to deal with conflicts manually.

besides that it works just fine

Hi, I'm trying to write a boot task for shadow-cljs. Can I programmatically set the :output-to and :output-dir options?