Fork me on GitHub
Slack Archive

This page is not created by, affiliated with, or supported by Slack Technologies, Inc.

2019-05-01

Channels

#shadow-cljs
<
2019-05-01
>
thheller08:05:05

@caleb.macdonaldblack that was indeed a bug. fixed in 2.8.36.

caleb.macdonaldblack09:05:58

Thanks, that fixed it. :thumbsup:

lilactown16:05:26

my asset-path needs to change depending on where it's deployed. - locally: /assets/app/js - deployed on server: /some-path/assets/app/js before we were doing something silly: had it configured to be ../assets/app/js this worked until we added a child route 😛 /some-path/foo/bar breaks it any advice?

polymeris16:05:33

Is it an option to move the local assets to /some-path?

lilactown16:05:14

I'm considering that now but it would be annoying to have to support different behavior in code like that

thheller17:05:11

@lilactown :asset-path "/assets/app/js" :release {:asset-path "/some-path/assets/js"}?

thheller17:05:03

shadow-cljs release app --config-merge '{:asset-path "somewhere/else"}'

anmonteiro17:05:48

do reload hooks need to be configured in the entry point namespace?

thheller17:05:07

no they can be anywhere

anmonteiro17:05:40

I’m probably doing something wrong because shadow is telling me no :after-reload hooks are configured

anmonteiro17:05:53

relevant config:

anmonteiro17:05:14

:widget {:target :browser
                   :dev {:output-dir "resources/static/js/widget"
                         :asset-path "/static/js/widget"}
                   :release {:output-dir "widget"}
                   :devtools {:after-load ladder.reconciler/live-reload!
                              :watch-dir "resources"}
                   :modules {:main {:entries [ladder.widget.ui]
                                    :init-fn ladder.widget.ui/run}}}

thheller17:05:58

I would recommend using the metadata always nowadays but it should be fine? assuming of course that the ladder.reconciler ns is actually included in the build?

anmonteiro17:05:08

it definitely is

anmonteiro17:05:16

it’s clearly not fine 🙂

thheller17:05:38

does the name actually match?

anmonteiro17:05:04

yeah that namespace doesn’t exist…

thheller17:05:48

hehe config could probably validate that after compile 😛

richiardiandrea20:05:39

do you folks think that shadow-cljs could successfully be compiled by the GraalVM compiler?

lilactown21:05:51

p sure the CLJS compiler uses eval for macros

thheller21:05:10

@richiardiandrea no that will never be possible

thheller21:05:51

well shouldn't say never probably but in its current form it is not possible to load and compile code inside a native image

thheller21:05:07

so shadow-cljs could in theory be compiled to a native image

thheller21:05:19

but it couldn't load any other depdencencies or macro code

thheller21:05:07

at least thats my understanding of the current limitations of native-image

richiardiandrea22:05:37

I don't enough either 😄 There use to be a problem with dynamically change class loaders but a tool like shadow probably should not do that (unless it does 😃)

caleb.macdonaldblack22:05:03

@thheller Does shadow-cljs automatically attempt to install missing cljsjs npm packages?

thheller08:05:00

only those that actually properly declare their npm dependencies which most of them don't do

👍 4
polymeris23:05:25

What would the advantage be of compiling with GraalVM? If you want independence from the JVM, self-hosting would probably be easier? (relatively speaking, I am sure it's not "easy", either)

richiardiandrea23:05:36

@polymeris the advantage is mainly startup time. The Cljs compiler is inevitably tied to the JVM now and I don't think this will change in the future. So the only other thing you can do as of this point in time is GraalVM

4