@thheller am I right in assuming that we don’t need to use cljs.core/resolve when code splitting with shadow?

yes and no. all resolve really gives you is the var so if you want to call something from a namespace you otherwise have no access to that is one option

or you can skip all that and call it via js/

eg. you load a module that includes some.ns/foo. calling (some.ns/foo) may cause a compiler warning. but (js/some.ns.foo) is fine since it doesn't try to load analyzer data for the call

https://github.com/thheller/shadow-cljs/blob/0e28c615cd75d4cbce27ede7a8f7f70785d42c86/src/repl/code_split/a.cljs

^ in this example you call (.then #(code-split.c/in-c "from-a"))

should that be wrapped in resolve then?

I personally would never use resolve since produces too much code for what you really want

I know it will give a warning, the reason for my original question was to know whether shadow had a special case for this

(eg. the entire var metadata)

what’s the tradeoff here though?

living with warnings?

I mean, I’m doing this via a macro so I could just add a ^::ana/no-resolve 😉

(defn test-fn []
  (-> (loader/load "c")
      (.then #(js/code_split.c.in_c "from-a"))))

works fine without warnings, just need to manually munge it

thoughts on my sneaky approach?

I have plans for making this nicer but nothing concrete yet

sure if you want to write an extra macro for this 😉

yeah that’s a given

I want this to be possible (loader/load 'code-split.c/in-c (fn [the-val] ...))

we need to write the macro anyway

otherwise we’re repeating too much code

ie. load a specific var and let the compiler figure out which module it is in

that sounds nice

most of my dynamic loading code ends up "cheating" like this currently

https://github.com/thheller/shadow-cljs/blob/master/src/main/shadow/cljs/ui/routing.cljs#L107

so I want to get rid of that 😉

the closure compiler folks are apparently working on dynamic import(...) support so that may be another solution in the future

(more similar to what webpack does regarding code-splits)

not sure how that would work within Closure

but I’ve been away from the internals for a while

yeah the entire :modules stuff would need a rework

but could potentially end up with something simpler. I do like to have strict control over what my modules look like but webpack is certainly easier to use in that regard

just use import(...) and let it split how it likes which is good enough for most cases

@thheller successfully code splitting with React.Suspense

Ohh that’s nice @anmonteiro — are you using Reagent for that?

nop

om.next

@thheller got a couple minutes to chat about module loading?

so right now the module loading support in shadow cljs assumes that the modules will be loaded from the current host / origin

this doesn’t really work for us because we host our scripts in a CDN

to make it work, we’d need support for a custom prefix in Shadow’s module loader

or the alternative might be to write our own

depending on what you’d want to support / maintain

or maybe this is already supported and I’m not aware of it

Hello @thheller, importing of http://recharts.org/ stopped working on 2.7.26 and later versions. I have created a simple test case here: https://github.com/lmanolov/minimal-shadow-cljs-browser/commit/2a1cc97dba7b396f0a005121249db3671282f7dd On 2.7.25 everything works great. On 2.7.26 and later I get the following error:

shadow.js.js:133 Uncaught TypeError: (intermediate value)(intermediate value)(intermediate value).default is not a constructor
    at Object.shadow$provide.module$node_modules$recharts$lib$util$Events (Events.js:13)
    at shadow.js.jsRequire (shadow.js.js:122)
    at Object.shadow$provide.module$node_modules$recharts$lib$chart$generateCategoricalChart (generateCategoricalChart.js:63)
    at shadow.js.jsRequire (shadow.js.js:122)
    at Object.shadow$provide.module$node_modules$recharts$lib$chart$LineChart (LineChart.js:9)
    at shadow.js.jsRequire (shadow.js.js:122)
    at Object.shadow$provide.module$node_modules$recharts$lib$index (index.js:376)
    at Object.shadow.js.jsRequire (shadow.js.js:122)
    at Object.shadow.js.require (shadow.js.js:158)
    at app.main.js:4

is there a way to tell shadow-cljs that cljs.core et. al. will be provided separately?

we have an npm library that is used both in a vanilla JS app with web pack, and a CLJS app with shadow-cljs

(it’s actually an bunch of separate libraries, some written in JS some in CLJS)

we’d like to be able to import into both as an npm lib

but right now it is (of course) importing all of cljs.core with the CLJS npm lib

@anmonteiro this is sort of supported via :asset-path as it is just blindly prepended before the file url. so you could use :release {:asset-path ""} which will end up loading

I think I’ve figured that out too 🙂

I think I’m fighting this one last error now

@lubo which recharts version is that? did you maybe upgrade that version too while upgrading shadow-cljs?

@thheller the recharts version is 1.4.2 and I haven't changed it while upgrading shadow-cljs

well in your example you are using a version range so are you sure that didn't change?

I'm looking at it now, just want to make sure 😉

my module loading is failing even though I see a successful request for it in the network pane

@thheller I just checked with the exact version "recharts": "1.4.2" and it works with 2.7.25 but fails with 2.7.26

do you use the :minimize-require option added in that version?

no. I have just changed the shadow-cljs version. shall I try this option?

no I'm just ruling out places I need to look 😉

@thheller do you know how to enable the goog.log logger in prod?

besides setting DEBUG to true..

not sure no

apparently goog.log.ENABLED

@lubo found the problem, for some reason the compiler thinks the "events" package is unused and just doesn't emit the code for it

I changed how that is detected so I guess I missed something

fixing.

Thanks!

noob question here: is it possible to access environment vars at compile time? (via cljs or shadow-cljs)

via macros yes but should be avoided

is the recommendation to avoid env vars entirely and use compiler optiosn?

you can use :closure-defines {some.goog-define/var #shadow/env "FOO"} in the config

that will use the FOO env var in place of that var

so in the ns you just do (goog-define THING "default value")

wow, okay, great! thank you

I missed that in the docs

this question has come way too often in recent times ... I'll definitely write some docs about this soon 🙂

yeah its not in the docs 😉

ahh there we go haha 🙂

if you have a patreon or donations page or similar please let us know 😄

is it possible that this technique ignores the default value of goog-define?

well you are replacing it with the FOO env vars so yes thats kinda the point 🙂

oh ok so if FOO isn’t set it won’t default to "default value"

if you only want to do that for release builds you can do :release {:closure-defines {some.goog-define/var #shadow/env "FOO"}}

yes it will use an empty value if FOO is not set

https://shadow-cljs.github.io/docs/UsersGuide.html#_release_specific_vs_development_configuration

awesome

all this is a bit messy at the moment. I have plans to make this a bit cleaner

@lubo should be fixed in 2.7.29. thanks for the report.

@thheller I checked it with 2.7.29 and it works perfectly. Thank you very much for the quick fix!

@thheller I’m absolutely in love with:

Module Entry "ladder.views.api" was moved out of module ":static-pages".
It was moved to ":main" and used by #{:static-pages :main}.

well done

tells me I need to remove a require

which I tend to forget 😓

hehe yeah me too 🙂

@thheller the only thing that feels weird to me having done code splitting in bare CLJS is how module ids become strings out of keywords

maybe this is for historical reasons / backwards compat?

I added a new thing today which might be useful to some people here. https://clojureverse.org/t/using-none-code-resources-in-cljs-builds/3745

@anmonteiro the shadow.loader is written in JS since I wanted to be able to use it without CLJS. eg. create a tiny initial loader that then loads the rest

cljs.loader always makes the assumption that cljs.core is in the base which I didn't want to force

but yeah it should probably support keywords, I don't like that part either

https://github.com/thheller/shadow-cljs/blob/master/src/main/shadow/loader.js

from what I see it just gets an argument and forwards it

so that argument could actually be anything

no it must be a string since the module manager expects a string

maybe if it were a keyword you’d have to str it?

gotcha

yeah, and that would introduce a dependency on cljs.core

that makes sense

yeah but the real problem I want to remove is that you need to remember which module to load

you should just be loading namespaces and let it figure out which module it is in

it could still call id.toString() and remove : if it starts with that

that would make it work with keywords without depending on cljs.core

bbl

@mhuebert this may be useful for your builds, new in 2.7.30. https://shadow-cljs.github.io/docs/UsersGuide.html#config-merge