This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # announcements (1)
- # architecture (1)
- # beginners (125)
- # boot (6)
- # boot-dev (2)
- # calva (69)
- # cider (38)
- # cljs-dev (3)
- # clojure (212)
- # clojure-austin (7)
- # clojure-australia (1)
- # clojure-denver (2)
- # clojure-europe (3)
- # clojure-gamedev (1)
- # clojure-hamburg (8)
- # clojure-italy (10)
- # clojure-nl (31)
- # clojure-russia (3)
- # clojure-uk (57)
- # clojurescript (56)
- # core-async (3)
- # cursive (15)
- # datascript (1)
- # duct (28)
- # emacs (6)
- # events (1)
- # figwheel-main (11)
- # fulcro (22)
- # luminus (59)
- # lumo (2)
- # onyx (4)
- # overtone (1)
- # re-frame (1)
- # reagent (4)
- # remote-jobs (3)
- # rum (2)
- # shadow-cljs (84)
- # spacemacs (7)
- # speculative (5)
- # vim (1)
- # yada (127)
So in https://shadow-cljs.github.io/docs/UsersGuide.html#clj-run I see:
$ shadow-cljs clj-run my.build/release as a thing I could do, but when I do:
$ shadow-cljs clj-run dev.build/main --start-server I get:
$ shadow-cljs clj-run dev.build/main --start-server shadow-cljs - config: /Users/orestis/dev/nosco/gamma/shadow-cljs.edn cli version: 2.7.16 node: v10.15.0 shadow-cljs - starting via "clojure" Unknown option: "--start-server" Usage: shadow-cljs <action> <zero or more build ids> ...
Hi, I'm trying to set
cljs.core/*target* to "default" but apparently is not working
@leocardosoti it is
"default" by default? what is it for you?
:npm-module doesn't set it explicitely at all
Is there a built-in way for shadow to open up a web browser the first time a compilation finishes? Or should I cook something up with build hooks?
Oh if you are taking feature requests for the UI, having a link next to builds which have a built-in http server (or a custom-supplied link for more complex stuff) would be ideal for my use case (a launchpad for our designers)!
I’m trying to make a one-stop-shop command for our designers to use — would it make more sense to use shadow-cljs as a launching pad (have the tools call my code) or flip it around (have my code run the tools)? I’m leaning towards the first, since I can then piggy-back on shadows background server for other things as well.
@orestis that actually already used to be there. just removed it by accident I guess
I couldn't decide when to start them though and not sure if its actually worth doing it since other tools can do it already
Yeah it’s not hard to do that. I’m actually now just writing a
build.clj file that uses
hawk/watch! to reload clojure stuff (for the server) and SCSS and who knows what else 🙂
Not sure if this is the best approach but everything is already there and I can have direct control over what happens so why not do it myself… it’s only glue code.
yeah in my work project I have an ugly watch.js script using
chokidar to run things on file change
having a bit of trouble
:requireing this npm on my project: https://github.com/hexenq/kuroshiro
I’ve been looking at the dist files to try and figure out what’s going on but haven’t been able to come up with anything: https://unpkg.com/[email protected]/
(Kuroshiro.) ;; => Uncaught TypeError: module$node_modules$kuroshiro$lib$index is not a constructor
$ shadow-cljs browser-repl shadow-cljs - config: /mnt/c/Users/thheller/code/shadow-cljs/shadow-cljs.edn version: 2.7.16 shadow-cljs - connected to server [:browser-repl] Configuring build. [:browser-repl] Compiling ... [:browser-repl] Build completed. (134 files, 35 compiled, 0 warnings, 4.25s) [6:1]~cljs.user=> (require '["kuroshiro" :as k]) nil [6:1]~cljs.user=> k #object[Kuroshiro] [6:1]~cljs.user=> (k.) #object[Kuroshiro [object Object]] [6:1]~cljs.user=>
shadow-cljs is awesome, it blows all of the other tools i’ve used out of the water
check whats in your
node_modules/kuroshiro directory and if it matches what unpkg shows
:default is kinda of weird since npm packages can't decide how they want to package stuff
Can I somehow hook into the shadow hud so I can report errors if say an SCSS compilation fails?
@orestis not really. you can send messages to the websocket but the client won't know what to do with them
Seems like it should be straightforward to expose the hud controls from your end — if I could have hud-show/hud-warn/hud-error/hud-hide with even just a single string it would be nice.
clearing it at the appropriate time and not have it interfere with other stuff is the hard part
Hm, yes. Would it then make sense for shadow to expose just a way to call some fully qualified function with some arguments on demand? So getting the UI right is up to the consumer (could just put a console.log to start with), but it’s the websocket connection that’s tricky to get.
Just to clarify, by on-demand I mean that I could from a clojure REPL, using shadow’s API, to send a message to the websocket, which then shadow would then interpret as just calling any arbitrary function.
I would be up for letting you send custom messages through the websocket and exposing a
subscribe method on the client you can use
Yeah makes sense. The function to call would already be in some pre-loaded dev-helper namespace on my end, so I wouldn’t have to worry about it being loaded, but I get that getting right in the general sense would not be trivial. I’m not sure how dynamic CLJS can be — i know it has some limitations compared to Clojure.
I need to get away from the computer. Apologies for keeping asking questions at this time of night…
2.7.17 I added
(shadow.cljs.devtools.api/send-to-runtimes! build-state-or-id some-msg) for the CLJ part which you can call from a hook or the REPL or any other code
on the client you can sub via
(shadow.cljs.devtools.client.env/subscribe! ::some-id (fn [msg] ...))
::some-id so that when code that calls
subscribe! gets reloaded it overwrites the old instead of adding a second one
you can experiment with calling functions from https://github.com/thheller/shadow-cljs/blob/master/src/main/shadow/cljs/devtools/client/hud.cljs but the chances are high that will somehow interfere with regular operations