Fork me on GitHub
#shadow-cljs
<
2019-01-21
>
orestis15:01:41

So in https://shadow-cljs.github.io/docs/UsersGuide.html#clj-run I see: $ shadow-cljs clj-run my.build/release :some/path 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>

...

orestis15:01:20

Passing no arguments calls my function just fine…

leocardoso15:01:43

Hi, I'm trying to set cljs.core/*target* to "default" but apparently is not working

leocardoso15:01:40

My config is

thheller16:01:30

@orestis try shadow-cljs clj-run dev.build/main -- --start-server?

thheller16:01:05

@leocardosoti it is "default" by default? what is it for you? :npm-module doesn't set it explicitely at all

leocardoso12:01:41

It's default rsrs, sorry my fault, I have another problem with webpack

orestis17:01:26

Thanks @thheller that does the trick.

orestis17:01:16

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?

thheller17:01:26

no built-in way no, hooks could certainly do that though

orestis17:01:28

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)!

orestis17:01:54

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.

thheller17:01:51

@orestis that actually already used to be there. just removed it by accident I guess

thheller17:01:12

as for running background processes as part of shadow-cljs that is also planned

thheller17:01:07

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

orestis17:01:20

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 🙂

orestis17:01:59

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.

thheller17:01:59

yeah in my work project I have an ugly watch.js script using chokidar to run things on file change

thheller17:01:13

ugly but has been working fine for 3 years or so 😉

knubie18:01:29

having a bit of trouble :requireing this npm on my project: https://github.com/hexenq/kuroshiro

knubie18:01:55

using (:require ["kuroshiro" :default Kuroshiro] brings back a nil Kuroshiro

knubie18:01:41

using (:require ["kuroshiro" :as Kuroshiro]) returns #js {} (empty object)

knubie18:01:24

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]/

knubie18:01:58

anyone run into something similar?

thheller18:01:22

@steedman87 any messages in the browser console during load?

knubie18:01:23

no messages that I can tell aside from an error when i try instantiate it

knubie18:01:40

e.g. (Kuroshiro.) ;; => Uncaught TypeError: module$node_modules$kuroshiro$lib$index is not a constructor

thheller18:01:27

@steedman87 it works fine for me?

knubie18:01:43

:thinking_face: that’s weird

knubie18:01:56

i’ve been able to require and use other npm packages in this project

thheller18:01:05

check your node_modules/kuroshiro files. maybe something got lost or so?

knubie18:01:24

I’ll try reinstalling

thheller18:01:54

$ 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=>

knubie18:01:07

reinstalling the module did the trick 😅

👍 1
knubie18:01:18

thanks for helping troubleshoot @thheller

knubie18:01:12

shadow-cljs is awesome, it blows all of the other tools i’ve used out of the water

❤️ 1
knubie18:01:22

oh, that’s interesting. I’m getting the same issue again

thheller18:01:20

check whats in your node_modules/kuroshiro directory and if it matches what unpkg shows

thheller18:01:38

sometimes npm does weird stuff when installing nested dependencies and stuff

knubie18:01:59

thanks, I’ll take a look

knubie18:01:50

ok I think it was just because I was using :default instead of :as

thheller18:01:56

yeah :default is kinda of weird since npm packages can't decide how they want to package stuff

thheller18:01:37

been thinking about doing what webpack does to ensure both work the same

thheller18:01:48

but kinda don't like that 😞

orestis18:01:02

Can I somehow hook into the shadow hud so I can report errors if say an SCSS compilation fails?

thheller18:01:05

people should write standard code and not have tools work around their issues 😛

knubie18:01:14

the mix of commonjs and es6 modules is a real pita

thheller18:01:30

@orestis not really. you can send messages to the websocket but the client won't know what to do with them

orestis18:01:06

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.

orestis18:01:20

(Sorry to ask like this — I’m just having such a great time building this 🙂 )

orestis18:01:29

If you prefer I submit a PR I could do that.

thheller18:01:40

showing stuff is not hard

thheller18:01:56

clearing it at the appropriate time and not have it interfere with other stuff is the hard part

orestis18:01:35

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.

orestis18:01:40

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.

orestis18:01:50

Or am I just thinking of a REPL?

thheller18:01:35

I would be up for letting you send custom messages through the websocket and exposing a subscribe method on the client you can use

thheller18:01:21

calling functions directly is ok too but a little more tricky

thheller18:01:29

(ensuring code is loaded and stuff)

orestis19:01:50

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.

thheller19:01:44

well if I add the custom messages you can use them to call functions 😉

orestis19:01:13

Hehe, I can’t think what the API would look like — it’s late 😄

orestis19:01:24

Thanks so much again for all this.

thheller19:01:36

so the CLJ side (api/send-to-client! :the-build-id {:whatever :you :like 1})

thheller19:01:13

client side (env/subscribe! the-msg-handler-callback) which would be (fn [msg] ...)

thheller19:01:31

so you'd add a :preload that does the subscribe

orestis19:01:54

And env comes from requiring shadow.cljs.client.something.env ?

orestis19:01:29

I need to get away from the computer. Apologies for keeping asking questions at this time of night…

orestis19:01:38

Thanks again!

thheller19:01:47

@orestis in 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

thheller19:01:13

it will send the message (any EDN value) to all connected runtimes (browsers)

thheller19:01:53

on the client you can sub via (shadow.cljs.devtools.client.env/subscribe! ::some-id (fn [msg] ...))

thheller19:01:30

needs ::some-id so that when code that calls subscribe! gets reloaded it overwrites the old instead of adding a second one

thheller19:01:47

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

thheller19:01:10

so probably would want to add some to show messages and stuff yourself

orestis19:01:41

Thanks for this! I’ll play around tomorrow.

thheller19:01:20

have fun. let me know what you come up with 🙂