Has anyone noticed an error when releasing for :browser with cljs.spec.alpha? We've just started to see and error with the compiled modules with: - shadow-cljs 2.3.30 - clojurescript 1.10.238 - node 10.2.1

Uncaught TypeError: L.l is not a function
at dist/cljs/spec/alpha.cljs:91:19 <- dist/shared.js:513:307

TypeError: L.l is not a function
    at $n (dist/cljs/spec/alpha.cljs:91:19 <- dist/shared.js:513:307)
    at no (dist/cljs/spec/alpha.cljs:300:33 <- dist/shared.js:519:141)
    at dist/io/comp/spec/user_spec.cljc:7:0 

@axrs try compiling with shadow-cljs release app --pseudo-names or --debug

Thanks @thheller, I'll give it a shot and report back

generally that looks like externs trouble but might just be a spec implementation error

I think I ran into something similar when builing a custom spec with deftype and not defrecord

dunno what u/non-empty-string-conformer is

u/non-empty-string-conformer is just a function

doesn't really do too much that would through it off unfortunately

(defn- non-empty-string [s]
  (if (or (not (string? s))
          (string/blank? s))
    ::s/invalid
    (string/trim s)))

(def non-empty-string-conformer (s/conformer non-empty-string))

Thanks @thheller, that solved the problem! Was a strange one

what solved the problem?

don't actually use the --pseudo-names output. that is just for debugging purposes.

if the problem goes away by doing so you have externs problems

try shadow-cljs check app

Ahhh. Yeah, --pseudo-names solved the problem.

yes but it also makes your builds huge

I'll run a check and review all of our interop.

externs problems are sometimes weird to debug since they can mess with your code in unexpected ways

https://shadow-cljs.github.io/docs/UsersGuide.html#infer-externs also helps

Thanks. The check shows we have a few places we can fix up. I'll see if inferring helps shortly

Maybe found another problem now after running check IllegalArgumentException: No matching method found: getGlobalType for class com.google.javascript.rhino.jstype.JSTypeRegistry

IllegalArgumentException: No matching method found: getGlobalType for class com.google.javascript.rhino.jstype.JSTypeRegistry
	clojure.lang.Reflector.invokeMatchingMethod (Reflector.java:53)
	clojure.lang.Reflector.invokeInstanceMethod (Reflector.java:28)
	shadow.build.closure/register-cljs-protocol-properties (closure.clj:387)
	shadow.build.closure/register-cljs-protocol-properties (closure.clj:372)
	shadow.build.closure/check/fn--13533 (closure.clj:1078)
	shadow.build.closure/check (closure.clj:1073)
	shadow.build.closure/check (closure.clj:1071)
	shadow.build/check (build.clj:371)

hmm which version are you running? I fixed a while ago

maybe your closure version is out of date?

shadow-cljs - config: ... cli version: 2.3.30 node: v10.2.1, Clojure 1.9.0, lein 2.8.1

lein ...

run lein deps :tree

check which closure-compiler-unshaded version you get

My problem child... lein...

should be [com.google.javascript/closure-compiler-unshaded "v20180506"]

My unshaded is coming from clojurescript 1.10.238

I'll add a dep and try again

try

[org.clojure/clojurescript "1.10.238"
    :exclusions
    [com.google.javascript/closure-compiler-unshaded]]

or just remove clojurescript dep entirely. shadow-cljs will bring that in

Yep, excluding the unshaded fixed the getGlobalType error. I've got a few warnings that may be the underlying cause (externs related). I'll let you know how I go 🙂

Thanks for everything @thheller

check may be reporting a few false positives. it is not perfect. happy to help if you have questions

@thheller unfortunately, the issue still remains. I've fixed up all the externs within our source. The only thing left I can think of is the (s/def is doing something else funky

do you have any other JS running in your page?

are you using multiple :modules?

No to other JS (in this scenario), but yes to modules

absolutely no other JS in the page?

Yep. Created a seperate html file and loaded just those in

try :compiler-options {:output-wrapper true} just to be sure (in your build config)

Thanks. Will try 🙂

it can sometimes be tough to debug those issues, might need to open up the debugger and step through the code to find out exactly whats happening

Yeah. It's going to be tricky to do so I think. loading all scripts into the page causes it to hang while it trys to do it's thing. I should be able to debug one script at a time hopefully

the problem is L.l is not a function which is closure-shortened variable. with :pseudo-names it will not be that short by rather $something$.$fooBar$

so the changes of that conflicting with something are slim over just .l conflicting with something

you can try adding a externs/<your-build>.txt and adding one line with just l

but it would still be worth finding out where the l is coming from in the first place

Yep. That all makes sense and confirms what I thought it was doing.

curious if the .txt file fixes it or if it just becomes another character 😛

The output wrapper actually fixed it

!

so then there must be some external JS in your page

I'm thinking maybe a race condition

shared.js and app.js were being loaded and evaluated at the same time

or some JS that just forcefully sets L maybe?

no that can't happen

ohh

JS engines are single threaded. so "at the same time" is not possible

That's true.

maybe something just sets window.L or so

Hmm. Maybe. We do have a few npm dependencies that are being being used with Shadow. One of them could be doing something internally.

are you using mapbox? I think they use L by default?

or rather leaflet?

https://leafletjs.com/

in your page with the error check what L is in the console

I assumed the .l property was the problem but maybe its just the L global

but :output-wrapper is fine to use as well

just makes the build slightly larger

Yep. We leaflet is used as a sub dependency in a package, as an npm dep. So that might be the culprit.

Which would make sense, as it's loaded after the shared modules

Thanks for the help again. Such a simple thing can cause a big issue...

yep confirmed. leaflet always creates the L global

meh

https://github.com/Leaflet/Leaflet/issues/2364

guess thats on purpose

Yeah. I think I'll be killing off leaflet. It's being a problem child

I'm reserving L by default now so the compiler will never attempt to use it

just in case someone uses leaflet. not a problem for builds that don't.

Thanks. It feels wrong to do so, but will help others out in the future no doubt

I might just default :output-wrapper to true as well. its not currently default when using multiple modules because the build gets slightly larger

but would be the safer default

Cool. It might be worth adding it to the docs as well. It's not listed as a supported option, but is mentioned above somewhere.

@thheller now shadow-cljs + lein + cider works great!

@doglooksgood cool

Does anyone know if it’s possible to use the suppress annotations provided by closure compiler? Or if not, any kind of workaround that would allow something like the exclusion of particular files from throwing warnings? https://github.com/google/closure-compiler/wiki/@suppress-annotations

@nick828 which warnings do you get?

Use of undeclared Var

how it that related to an annotation?

Well my understanding is that it will allow me to do this: > If you cannot easily fix a JsCompiler warning, you can suppress it using the @suppress annotation in the function’s JSDoc block

I would prefer to fix the warning, but at this stage I’m looking at my options

what kind of code are we looking at?

and what is the full warning? the annotations really only suppress warnings for the function you annotate and that should never be necessary in CLJS

It’s cljs and I’m implementing code-splitting - the warning is triggered by the fact that I need to refer to a function in another namespace that has not been required. If I were to require it in then I believe that the bundles would not be correct. Perhaps this would be better dealt with some other way (by using a macro?)

so the "official" solution is to use resolve

oooo, ok - please do tell me more

so (let [something (resolve 'some.ns/foo)] (something))

ok

that way your code can call a function that it has no require for

sounds great, thanks @thheller

note that you can only actually call the resolved var after the code has been loaded. otherwise it'll just error out

Timely message! I’ve just noticed that 🙂

@thheller Thanks for your help there, it’s now working beautifully 🙂 I’m not sure if I’ve struggled with this because I’m new to Clojure & ClojureScript but I wonder if a slightly fuller example of a code-splitting implementation might be helpful to others? I’ve been following this: https://shadow-cljs.github.io/docs/UsersGuide.html#_loading_code_dynamically

@nick828 unfortunately pretty much all uses for code-splitting and dynamic loading rely pretty heavily on the framework you are using and how your code it structured

coming up with a general purpose example is pretty tough

;; foo.bar is part of module :foo
(def some-var (resolve 'foo.bar/x))

(-> (loader/load "foo")
    (.then (fn []
             ;; foo.bar is now loaded
             (some-var))))

so basically whenever you want to call some-var you probably need to wrap it in a load call to ensure it is loaded

you call check (loader/loaded? "foo") as well

using multi-methods also helps

typically you'd trigger the load in the router or on click

are there any reagent/re-frame examples out there that use routing?

@thheller fair point, I guess the resolve call was all I needed to understand in the context of loading modules dynamically. Good point on checking that the module is loaded, I had noticed that from the docs. For what it’s worth I’m using Kee-frame for routing although there are many ways to handle the routing, that said I wasn’t suggesting that the docs had anything more than a very basic example of using resolve - agnostic of any routing…

is there a kee-frame template or so?

A Kee-frame template that gives an example of how code-split modules could be loaded?

only the routing part

I’m not sure I quite understand what you’ve got in mind, there is a demo project linked to from Kee-frame’s readme: https://github.com/ingesolvoll/kee-frame-sample, the routers.cljs for the demo project is here: https://github.com/ingesolvoll/kee-frame-sample/blob/master/src/cljs/kee_frame_sample/routers.cljs

not a clue what that is about. why 3 different routers?

looks like it already pretty heavily abstracts all the routing logic though. might make it harder to adapt it to be aware of splits

The commit message might be helpful to explain that: > Changed API to support different routing libs. Example implementation…

Do you just want a boilerplate for handling routes in Kee-frame so that you can give an example implementation of code-splitting in your docs?

not the docs but this example could be made more useful. https://github.com/shadow-cljs/examples/tree/master/code-split

I can probably do a framework-less generic example

Ah right! I’m with you now - yeah I’d recommend steering clear of a framework for this, I wonder if a very basic bidi implementation would be enough - you might need more of your own boilerplate to make it work though

to be clear, I’m not saying that this is absolutely necessary in order to understand how to implement code-splitting using Shadow-cljs - just that the current documentation could be a bit clearer about good practices on resolving namespaces that may not have been loaded at the point where the code is first executed

yeah. it is tricky to do this correctly so the docs should definitely clarify this a lot more

I’d love to see an example of how you have done this correctly 🙂 that would be super useful to me

there could also be a little more support by a macro or two

currently you have to know which module a namespace is in which is a bit annoying

Yes, that’s where I think my current implementation is not so great

Are you familiar with ReactBoilerplate?

looked at it yes, used it no

it might be worth having a look at the way it handles code splitting - I haven’t used it for 6months+ but from memory it was pretty straight-forward to implement

It’ll obviously be rather different from how things are handled in the cljs world but I think a lot of the underlying patterns are quite similar

main problem for me is that I don't use reagent. so I have no idea how you'd write it in reagent

Ok, I might be able to convince my people to allow me spin off a generic repo to provide an example in Reagent/Reframe

(defn async-component [the-module the-var]
  (let [loading-ref (r/atom false)]
    (-> (fn []
          (if loading-ref
            [:div "Loading ..."]
            (the-var)))
        (with-meta
          {:component-did-mount
           (fn [this]
             (-> (loader/load the-module)
                 (.then #(reset! loading-ref true))))}))))

(async-component "foo" (resolve 'some.foo/var))

assuming (ns some.foo) (defn var [] [:div "hello world"])

not exactly sure how you are supposed to do lifecycles in reagent

https://github.com/ingesolvoll/kee-frame-sample/blob/master/src/cljs/kee_frame_sample/core.cljs#L21-L25

so instead of [live/live] you do the async-component call

ah, yeah that is a bit of a pain. These docs are quite good: https://github.com/reagent-project/reagent/blob/master/doc/CreatingReagentComponents.md#form-3-a-class-with-life-cycle-methods

This is similar to my first attempt at it, I’ve now moved to a reframe approach using event handlers (coeffects/effects/interceptors) for loading the module at the right time in the application

basically you want a stateful component that re-renders when the code is loaded

alternative when using something like re-frame that has an event handler like :set-current-page or so

instead of directly setting the page you figure out which module to load

and then do the actual :set-current-page in a callback

Not sure if you saw my message above: > I’ve now moved to a reframe approach using event handlers (coeffects/effects/interceptors) for loading the module at the right time in the application

From the reading I’ve done on approaching problems with a React vs Reframe mindset, I’ve decided to move away from the stateful component pattern

doesn't matter which approach you use. somewhere you need some state that gets updated when the code is loaded and triggers a re-render

does not matter *where* the state is

Agreed, the pattern you are suggesting is what needs to happen

The ‘how’ is a little less important

@thheller is this the bhauman library for checking maps you were talking about the other day? https://github.com/bhauman/spell-spec it looks amazing

figwheel had something similar. looks like he extracted it into a proper lib. nice.

but yeah I was talking about those kinds of error messages. figwheel has some really good error messages.

is cljss an offshoot of the shadow.css stuff in the wiki

I noticed that it has similar macro names

no. I think we more or less both took styled-components from the react work as inspiration

the implementations are entirely different

@thheller do you we could update the manifest.json automatically after changing the manifest.edn?