Sorry for copy the topic, but this group is more active. Anybody know this issue? I have this first time with figwheel-main https://clojurians.slack.com/archives/CALJ3BFLP/p1571930616030100

https://clojurians.slack.com/archives/CALJ3BFLP/p1571930671030200

I was trying with npx webpack --mode=production and npx webpack --mode=development - both work during figwheel developing

So it has to be something about figwheel-main hmm

@kwladyka that looks like an externs issue. try enabling :infer-externs. you can debug this a little by setting :pseudo-names true in your build config. that'll still error out but it'll make the "problem" easier to find

it seems difficult to figure out a supported/current cljs test runner tool.

Also, there are a ton of references out there to using phantomjs based ones - which is an unsupported, dying project

then there is karma+chrome /etc. which requires some node setup. that can work, but requires cooperation from the infrastructure - like travis

which is another hunt to find

the annual clojure survey had a question about what people are using in cljs, in case those results are helpful

I thought lein-doo was the place to be now, but it looks to be falling behind too

I always do read the surveys! but don’t remember that one, will look

background is just trying to get clara-rules cljs-side a bit more up-to-date. it’s using phantom and facing troubles there

and I feel using phantom just really isn’t a good answer anymore

https://www.surveymonkey.com/results/SM-S9JVNXNQV/ Q24

I'm just glad "not running tests" isn't the highest anymore :)

thanks

haha 2nd place

the open ended comments are useful here too

so there is “headless browser” @ #1, I think probably a karma-style setup then

#2 no tests, #3 doo

interesting this survey view says (64), but will only show me like 4

and I would welcome feedback about what the available options should be in this question for 2020

can you scroll that pane?

doesn’t let me in chrome, will try something else - probably a UI quirk though

looks fine in firefox, maybe I just didn’t do it right in chrome

open it harder

> Move code to cljc and test Clojure part - Getting testing to work for cljs is not a pleasant experience. this one speaks to me - I’ve done this a good deal hah (obviously not testing dom-side)

koacha is making a name for itself in the 64 comments though - interesting to explore

with shadow-cljs, I can’t use lein-doo or cljs-test-runner because shadow-cljs does a lot to add on top of the CLJS compiler that my application needs

yeah, I’d fear that

I was trying out lein-doo but pretty annoyed with some of it’s opaque issues - that have several github issues linked to it, but no details and I don’t think it is really actively maintained (at least it seems)

so if I’m going to move away from phantomjs issues, I don’t really want to move to another unmaintained thing

fun times

the current best practice with shadow is to install and use karma

In my specific case of clara-rules, don’t really care about DOM-like things anyways. It’s just a non-visual lib that can be used in JS. So just want to test it compiling and working in that way. So a bit nicer. I’m not trying to get carried away here and tests layout stuff etc

I know karma is big an popular

it has a :karma target that makes this pretty easy. but I don’t think this actually does a whole lot other than look for tests, spit them in a file and a simple runner ns

I guess I can figure out how to do this sort of thing in this travis setup

open-source github repo integration thing in this case

you might consider testing in node? if you think that gives you the confidence you want from your CI process

I think node would still be fine

will have to explore

there’s a node-test build in shadow-cljs as well: https://shadow-cljs.github.io/docs/UsersGuide.html#target-node-test

I'll just generally hand-wave around this and suggest cljs testing might be an area for clojurists together to help in

FWIW the "design" for this in shadow-cljs separates out the compilation from the actual running of the tests

so the karma route just runs the tests without it even knowing about shadow-cljs

things are really simple when running tests in node is an option

interesting, I’ll read up on it

thanks for the links/advice

testing is mostly complicated if you need to run them in a browser environment

node is a whole lot easier since you just run node the-test.js and don't need to setup an entire headless browser and so on

yeah, that makes sense indeed

has anyone noticed differences in advanced compilation with Java 11? we do...

what kind of difference?

we get this error: Uncaught TypeError: http://SortableHOC.Sl is not a constructor while we didn't get that one with Java 8

sounds like an externs problem but not sure how the java version would affect that

yeah, weird right?

unless you also changed other dependencies while updrading the java version

nope

looking at the code the error isn't weird. it's maybe weirder that it used to work in Java 8 😉

sorry I can't come up with a good repro now

just wanted to inform if anyone else had this problem

I did an update of my library https://github.com/kwladyka/form-validator-cljs to validate form in cljs using spec and fn. I added a demo with example of code https://kwladyka.github.io/form-validator-cljs/ Now it is easier to see what library can do, but it has more use cases. What do you think about the library and the demo? Is it understandable? Is it useful for you?

@kwladyka cool! there is also a #announcements channel btw

Is there an alternative to requiring-resolve in ClojureScript? Otherwise I have to create a whole other namespace for 1 function which uses a library conditionally.

no. dynamic require isn't possible at all

I suppose in ClojureScript you pay the bulk of all your libraries anyway (until compilation), so there a top-level require would do the job?

oh, but it would need to be in a macro to be conditional on the namespace existing, boo

out of curiosity, if resolve can work, why not requiring-resolve? :thinking_face:

resolve is fake and resolves at compile time. it cannot be used dynamically

Sure. But so could requiring-resolve.

require can't be done dynamically because it requires blocking IO

in JS all IO is async. so loading the namespace would require a callback before it can continue

also conditions around require would probably make advanced compilation and analysis much more tricky?

the closure compiler doesn't support this at all too. that would be another reason yes

Maybe this is just for my case, but I would assume that all branches are accessible (except where google closure can assume otherwise)

I should probably try and understand a little better: how does clojurescript determine the dependencies? Doesn't it analyze the whole file? Couldn't all requiring-resolve be appended to the list of namespaces to goog.require?

I understand the general context of where I'm getting to if I want a semantic match. But the behavior I'm really looking for is: - If ns is known, then add to goog.require for the file, and call resolve on the sym. - if ns is unknown, do nothing unless function is called then blow up

goog.require is basically a noop

it does absolutely nothing.

so if you think about this as just getting an extra goog.require in there you are looking at the wrong thing

I thought that was the magic for analysis. My mistake.

the problem is that all dependencies have to be loaded before the actual file is loaded because of the async IO

so the code would be loaded regardless of the goog.require being conditional or not

but the closure compiler doesn't allow it anyways so it doesn't really matter

All dependencies have to be loaded before the js, but not the cljs, no? I must not be understanding

at runtime there is only JS

I'm not really trying to prevent loading. I'm trying to make it so require didn't blow up.

What is the situation in which the namespace exists in some cases, but not in others? Different ClojureScript compilation runs with different environment variable settings (or similar), but at least some common source files in both compilation runs?

I don't understand that question

you can't reliably "mix" output from different compilation runs

My question was directed towards dominicm -- sorry if that wasn't clear

It's an optional dependency of the library that enables the use of one function.

the only way to get "optional" dependencies right now is via :preloads

but :require is completely static and cannot be dynamic in any way

require in the REPL is completely different and has different rules

require in a file is fake and not like the REPL at all

Sure. I know. It's there to be detected for static analysis right? Or wrong?

it was added to allow files without an ns form and is completely static yes

So perhaps one way to achieve the goal is to have two source files foo1.clj and foo2.clj, where foo1.clj is compiled if the dependency is present, and calls the real function, and foo2.clj is compiled if the dependency is not present, and throws an exception if its function (with the same name) is ever called? Sounds a bit clunky, but possible.

So, just so I'm entirely clear, I'm not after deferred loading here. I understand the limitations there. What I'm thinking of is another lie. A static requiring-resolve that that does the same thing as require. But if it didn't find the namespace it would replace requiring resolve with something that would blow up at runtime. Otherwise, it replaces it with whatever resolve does right now.

I don't really understand your goal or what require-resolve has to do with anything

(def my-magic-function (atom nil)) (defn call-the-thing [a b c] (@my-magic-function a b c)

then have the "optional" ns swap! into that atom

Is there a run-time cljs way to check whether a specific namespace exists?

no, in fact namespace don't exist at all anymore in :advanced compiled builds

You only need compile time detection.

I guess. Is there an inside-cljs way at compile time to detect whether a namespace exists?

define "exists", it is relative and time dependent

I think so. Else it couldn't tell you about requiring non existent name spaces

if you don't have an explicit require for something it is not guaranteed to exist before the ns checking it is compiled

Right, so seems like catch-22 for an inside-cljs-language solution to the desire. Only alternative I can see is something in the compile/build infrastructure that does it.

(the previous comment is assuming that the optional dependency's source code is not under dominicm's control or ability to modify -- thheller your suggestion about the atom seems to work if the optional dependency's source code is under dominicm's control)

we are working with the limitations of JS and somewhat the Closure Compiler here

so it really doesn't help to compare to CLJ/JVM features

I think domincm is dancing around the idea of a macro or reader thing that looks at the classpath, sees if a particular namespace exists, then emits some code. but I don’t know if the compiler/analyzer lifecycle works like that

it doesn't matter what is on the classpath

the only way to affect what ends up in a build is via build config and :require in the actual sources

macros can't do it

@thheller this is roughly what I was getting at

(defmacro require-resolves
  [body]
  (let [to-require
        (set
          (map #(namespace (second (second %)))
               (filter #(and (seqable? %) (= 'requiring-resolve (first %)))
                       (tree-seq seqable? seq body))))]
    (if (every? #(io/resource
                   (str (-> %
                            (string/replace "-" "_")
                            (string/replace "." java.io.File/separator))
                        ".cljs"))
                to-require)
      `(do ~@(map #(list 'require (list 'quote (symbol %))) to-require)
           ~(walk/postwalk
              (fn [x]
                (if (and (seqable? x)
                         (= 'requiring-resolve (first x)))
                  (list 'resolve (second x))
                  x))
              body))
      (walk/postwalk
        (fn [x]
          (if (and (seqable? x)
                   (= 'requiring-resolve (first x)))
            `(throw (ex-info (str "Unable to find " (first x)) {}))
            x))
        body))))

(require-resolves
  (defn foo
    []
    (let [x (requiring-resolve 'cljs.core/foo)]
      (x))))

obviously the detection of existence wouldn't just be doing io/resource on the file, I'm assuming there's some compiler internal for that.