How is cljs.js/*loaded* intended to be used?

I don't believe you need to use it

why do you think you do?

might also be helpful to understand what you are trying with a short description

like are you loading a bunch of stuff from your server over HTTP or something?

I'm trying to use cljs.js/eval-str to evaluate code that :requires and uses cljs.analyzer/macroexpand-1. Not sure if the right thing to so is to augment my cljs.js/*load-fn* to retrieve the cljs.analyzer source (and all its dependencies) or something more radical like,

(ns …
  (:require [cljs.js :as cljs] 
            [cljs.analyzer]))

(swap! cljs/*loaded* conj 'cljs.analyzer)
(cljs/eval-str …)

Does that answer your question?

@joshuamilesthayer is working with me on this. 🙂

but why do you need to do that?

if you're self hosted analyzer is already there

Ah, okay.

self host fundamentally must have the analyzer & compiler and any deps

Makes sense now that you say that. 🙂

In that case is the right thing to do to have our load-fn return nil for that dependency?

the loading mechanism already checks loaded

I wouldn't do anything at all

just load stuff

if you look at the top of the cljs.js ns you'll see the requires

We're finding that our load-fn is called for cljs.analyzer if the code being eval-str'd :requires it, but that may be because we're making a mistake somewhere else?

oh hrm, I think you're right

we don't populate *loaded*

for what is already included necessarily

might want to look at how Planck etc. handle this

just putting analyzer in there won't be good enough of course

since that's not the transitive graph of deps

Right.

ok, we'll have a look at what Planck does. Thanks!

I can also file an issue for populating *loaded* if you think that's a good idea.

probably not going to bother

it's not as simple as it sounds

since it has to consider the entire build

not just what cljs.js requires

ok. I'll refrain from filing anything then.

one easy thing of course is to just look at the namespaces

this is possible since you're not advanced compiling

i.e. split the ns segments into strings and check goog.global

I'm not sure I understand. Do you mean manually trace the transitive dependencies and conj them all in ourselves?

If so I'm not sure I understand that last part about goog.global.

you don't need to bother with any of that

well for at least a certain set of namespaces

specifically cljs.*

or clojure.*

Ah.

if the ns starts with that

then you can just check goog.global

goog.global["cljs"]["core"] etc.

but that can be done programmatically

you probably don't want to do this in general if you want to support standard REPL behavior for :reload :reload-all

but for core nses should be fine

goog.global is always bound to the global context regardless of JS environment

that's where all the namespaces live

I spoke to David in person about this 👆:skin-tone-2: and he said a better way to deal with this is by dumping the compiler state after requiring the necessary namespaces + passing that state into cljs.js/eval-str.