small update on the new closure-library. it completely breaks cljs.loader (and the shadow-cljs variant shadow.loader). no longer accepts pure json data for config but must instead use some TrustedResourceUrl instances. setModuleUris is gone and replaced by setModuleTrustedUris.

a bunch of other smaller issues as well but those are mostly related to shadow-cljs not using the built-in "debug" loader. should be fine in CLJS as @mfikes mentioned.

thanks

Yeah, a few method names where changed goog.module. I was thinking about chasing down changes if nobody else is already tackling it.

not that I'm aware of, those fixes would be good for another incremental release

k, I'll look into it over the weekend. Working on some code-split stuff in-house and I'd like to iron out the kinks.

Maybe we currently have insufficient tests around cljs.loader? (Wondering if Canary would catch Google Closure breaking it.)

I'd love to learn more about how to add tests to the suite. Is that already part of any contrib guide?

@mfikes hrm ...

this goes back to the other thing I want to do

I think there are at least guides telling you how to run all of the various tests (which gives an indirect hint of where they are located). But just ask and I'd be happy to help

which is to parse Closure requires for validation

coo'

I half started on that when I looked at the type inference stuff

Yeah, that was that (comment ...) you had added capturing the bit learned

So stand down? Or circle back with you on guidance?

https://github.com/clojure/clojurescript/blob/f97d766defd02f7d43abd37e3e9b04790a521b1e/src/main/clojure/cljs/externs.clj#L165-L172

@john I think David is just saying Closure reminded him of that cool thing

@john thinking ahead to the real solution to this problem

nothing specific about anyone wanting to pitch in to fix the issue

rather a way to know about problems at compile time

rather than runtime

ah k. So if any basic method name or API changes are necessary, those'd be helpful to chase down?

Ahh, yeah, maybe cljs.loader's code would cause warnings to be emitted at compile time instead of failing at runtime...

yes

because JS fns names changed, arity changed etc.

k

Yeah, really more general than cljs.loader. Just the latest pain point example.

That'd be cool.

also a benefit for ClojureScript tooling

I don't know how much code nav for Closure libs there is outside of Cursive

A smaller, more concrete example: clojure.string/trim could 1) Be inferred as returning a string 2) Cause a compilation warning if, for some odd reason gstring/trim dissappeared, required 2 arguments, etc.

On the subject of cljs.loader... I've found the need for using alias for loaded assets. I've also heard others (2 other users besides myself) asking about alias in cljs in #clojurescript recently. If I had alias, I could convert a lot of my existing codebases to modular format with minimal code changes (just by annotating some hiccup forms with reader tags). So I just wanted throw that on y'all's mental model and let it percolate, in case opportunities avail themselves.

@john I don't know what you mean?

what is alias?

maybe he means this? https://github.com/clojure/spec.alpha/blob/master/src/main/clojure/clojure/spec/alpha.clj#L15

if so I don't really understand anything else about what you've said

I don't see how alias relates to assets or modular format, or anything else

so that needs explaining

Sorry, so, perhaps I'm not thinking about this right... but I'd like to be able to do (cljs.loader/load :blah (fn [] (resolve 'short-alias/some-var))) rather than ... (resolve 'my.really.really.long.name-space/some-var)

Is something like this already possible?

did you try backtick `

oh

I don't think so, but how could that possible know which module's namespace is providing the var?

won't work

anyhow - alias isn't really possible

and this about a convenience as far as I can tell

I don't see how this relates to making this any more "modular"

bbiab

It allows one to use the same aliased var at the call-site, without having to change any code, under some conditions. (if the lazy version of your codebase uses the same convention between ns aliases and a top level call to alias)

Def a convenience feature... But not possible from user-land via macros without support from core.

afaict

actually, there might be a way to do this from user land ...

Especially if I can figure out unquote splicing from tagged literals into the top level

reader conditional unsplicing is not allowed at the top level

Doesn't it work for #?@( though?

that's what I'm saying isn't allowed

oh, works on non-top-level then

there is no context to splice into at the top level

gotcha

Thanks Alex

I have a reader tag that transforms ns forms and I was hoping to drop some extra defs after the ns declaration. I guess a second call to something after the ns form is the only way

To simulate alias modules, I can just have lazy-alias def (in the current namespace) a map of aliases to namespaces and then just do the lookup when later transformations detect a qualified symbol.

many people have tried to build this. it usually doesn't end well.

usually if you need splicing at the top level, then a do wrapper will work, but ns forms are particularly problematic due to the "Gildardi scenario"

at least in Clojure world, don't enough details about cljs

I think ns in a do might have worked in testing... But yeah I'm not sure if I'll trust it long term, given expectations

Never heard of that Gilardi scenario, but technomancy wrote a blog about it: https://technomancy.us/143

it’s also a common problem in boot files: https://github.com/boot-clj/boot/wiki/Run-time-requires-(within-task-definitions)

Hmm... looks like my usage wouldn't be hit by Gillardi, because AFAICT I'm not calling references to the foreign vars directly.

> Gildardi > Gilardi > Gillardi Clearly a controversial subject