Fork me on GitHub

is it possible to run say watch with a config that’s passed in without a shadow-cljs.edn? I want to do something like this from figwheel

(fig/start {:id "dev"
              :options {:main (symbol main)
                        :nrepl-port 7002
                        :output-to "target/public/cljs-out/main.js"}
              :config {:watch-dirs paths}})
I have a little code visualizer, that updates a page as you make changes, in a ‘target’ project. got it working with figwheel, but need to to get it working with shadow since most of my ui code uses shadow and figwheel doesn’t understand the string requires, etc. I was poking through the devtools api, and it seems like watch can take a map, but i’m not clear on how that ‘maps’ to whats in the normal config file I guess as a workaround I could create a separate build for it in the project that it’s looking at. but I was trying to keep it as self-contained as possible


I'm having a weird issue where despite my locally installed-in-node_modules folder, I have react 16.8.1, but for whatever reason the version getting compiled into my build is 16.7.0


my guess is there's an old dependency from the project that relied on this and I have a cache to clean


... indeed, rm -rf .shadow-cljs worked


@eoliphant that use-case is not currently supported. you can instruct it to watch without a config file just fine but running the complete shadow-cljs instance isolated is not supported. one design choice I made is only allowing one shadow-cljs runtime per JVM. shadow-cljs.edn is also required currently.


If you explain your use-case a bit more I can maybe relax some of those requirements


maybe the embedded API already solves most of your issues


@mattly I just fixed a bug where changes to node_modules files were not picked up properly by running watch processes


are you 100% certain that you fully restarted the watch before wiping .shadow-cljs?


it should never be possible to get into a state where a freshly started shadow-cljs picks up files that no longer exist or of the wrong version


since 2.7.32 it also shouldn't be possible to get into that state while watch is running


hey, I'm trying to get chlorine working with shadow-cljs. but for whatever reason when running shadow-cljs there is no socket connection being opened

$ npx shadow-cljs server
shadow-cljs - config: ...\shadow-cljs.edn  cli version: 2.7.32  node: v10.15.1
shadow-cljs - socket connect failed, server process dead?
shadow-cljs - HTTP server for :app available at 
shadow-cljs - server version: 2.7.32 running at 
shadow-cljs - nREPL server started on port 53349


how do I solve this?


not sure I understand the question? which "socket connection"?


sorry, I mean the socket repl


I've seen that in many examples of shadow-cljs a socket repl is started when running shadow-cljs


socket repl is started by default yes


it just doesn't log anything on startup?


it isn't for me though, so wondering if I'm doing something wrong


hm, but it does in some examples, like at the bottom here:


that was removed a very long time ago


if you want to find the port you can check .shadow-cljs/socket-repl.port


the socket repl is started regardless of the log message


I see, thanks


by default a random port is used


I couldn't find it anywhere in the docs 🙂


you can set a fixed port by setting :socket-repl {:port 12345} in the shadow-cljs.edn


nobody seemed to be using the socket-repl so I removed the extra print


ah, I see. thanks for the info 🙂


the nrepl log message is only there because of cider


I'm not sure, but I think chlorine is the most fully featured atom clojure package, and it uses socket repl


I'm super new to cljs overall though, so I don't know


I have not tested chlorine yet since its still relatively new


but yeah I didn't want people looking for random port numbers on startup. tools should just check .shadow-cljs/socket-repl.port instead


or you set a fixed port up to you 🙂


okay. it'd be neat to have the fixed port in the docs at least 🙂


hah, I got it to work now! thanks a lot @thheller


cool, awesome 🙂


Hey @thheller thanks for the clarification. Based on what you're saying I think, I'll just need to add a build, etc. Basically, I have a little lib that I use to create a sorta generic domain/attribute model. From that model I can generate datomic/relational schemas, APIs, etc. I have a visualizer that uses plantuml, and just spits out an SVG, but I also started working on one that's interactive and dynamically rendered with JS. So the goal was include the lib, and setup a deps alias that runs the viewer against the target ns. Based on what you mentioned about only allowing one shadow instance, what I was trying to do probably won't work. But conversely, adding a :my-viewer build to a project isn't a big deal either


you can start builds without having them in the config just fine


you just can't start the server without a shadow-cljs.edn


you can run (shadow.cljs.devtools.api/watch* build-config {})


there build-config is a map as it would appear in the shadow-cljs.edn with an extra :build-id key


{:build-id :your-viewer :target :browser ...}


I'm unsure why this needs to be a dynamic build though?


or built at all for that matter? does it not just require some data?


hmm.. I might be conflating the terms (server, build, etc) a bit and as we’re talking about this, I just realized there’s already a ‘shadowy’ lol, model for what I want to do. In say, fulcro apps, workspaces are conceptually the same thing I’m doing, a different ‘view’ of some portion of my application code. Just adding a ‘build’ and the setup code, is probably fine. Well the way my stuff works, is that I have a DSL, that jams stuff into an internal datascript db (imagine spec’s global registry). So if I add an attribute in say the `mydomain.person’ namespace, that should be reloaded, which updates the db, and my dynamic view shold get updated as well


ah so you are relying on somethat that is generated at runtime?


so must be run as part of the normal code?


yeah well I guess it’s technically read/compile time. but the idea was to make the data available for generators and what have you, but also, at application runtime.


and yeah the ‘domain defintions’ are part of the normal app code


maybe some architecture like fulcro-inspect makes sense? ie. user adds a preload?


ah yeah, I think the preload would be a good way to genericize it