Fork me on GitHub
#cljs-dev
<
2019-02-15
>
thheller17:02:41

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.

thheller17:02:53

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.

john19:02:14

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

dnolen19:02:52

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

john19:02:02

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.

mfikes19:02:52

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

john19:02:14

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

dnolen19:02:08

this goes back to the other thing I want to do

mfikes19:02:12

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

dnolen19:02:23

which is to parse Closure requires for validation

dnolen19:02:09

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

mfikes19:02:46

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

john19:02:20

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

mfikes19:02:03

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

dnolen19:02:28

@john thinking ahead to the real solution to this problem

dnolen19:02:28

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

dnolen19:02:53

rather a way to know about problems at compile time

dnolen19:02:55

rather than runtime

john19:02:41

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

mfikes19:02:48

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

dnolen19:02:09

because JS fns names changed, arity changed etc.

mfikes19:02:26

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

mfikes19:02:47

That'd be cool.

dnolen19:02:23

also a benefit for ClojureScript tooling

dnolen19:02:42

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

mfikes19:02:17

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.

john20:02:31

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.

dnolen20:02:57

@john I don't know what you mean?

dnolen20:02:15

what is alias?

dnolen20:02:17

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

dnolen20:02:29

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

dnolen20:02:34

so that needs explaining

john20:02:47

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)

john20:02:43

Is something like this already possible?

dnolen20:02:58

did you try backtick `

john20:02:28

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

dnolen20:02:29

won't work

dnolen20:02:48

anyhow - alias isn't really possible

dnolen21:02:02

and this about a convenience as far as I can tell

dnolen21:02:13

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

john21:02:32

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)

john21:02:32

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

john21:02:42

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

john21:02:42

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

Alex Miller (Clojure team)21:02:04

reader conditional unsplicing is not allowed at the top level

john21:02:50

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

Alex Miller (Clojure team)21:02:25

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

john21:02:36

oh, works on non-top-level then

Alex Miller (Clojure team)21:02:42

there is no context to splice into at the top level

john21:02:21

Thanks Alex

john21:02:38

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

john21:02:55

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.

Alex Miller (Clojure team)22:02:31

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

Alex Miller (Clojure team)22:02:33

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"

Alex Miller (Clojure team)22:02:59

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

john22:02:06

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

borkdude22:02:05

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

john22:02:17

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

aisamu22:02:30

> Gildardi > Gilardi > Gillardi Clearly a controversial subject