cc @U5H74UNSF

no, this is not supported. purely happens to work by accident

since a . is just passed through, and isn't validated beyond that

also the "./foo" style require isn't even supported by CLJS only shadow-cljs

yes, I was just going to say I only tested this with shadow-cljs since I didn't even know how to import a local JS file with vanilla CLJS, but this isn't very relevant here, the original report did this with a normal npm lib:

(ns headless-ui
  (:require ["@headlessui/react" :refer [Dialog Dialog.Overlay]]))

(defn modal-overlay [_]
  (into [:> Dialog.Overlay {:class-name "fixed"}]))

yeah :refer is just declared as sequence of symbols

not sequence of symbols without dots 😉

thus is passes validation and is never checked again

(at least in shadow-cljs, no clue about regular CLJS)

technically the Dialog refer already covers Dialog.Overlay, as such cljkondo is correct

but without Foo.Bar in :refer you get this in shadow-cljs:

file:///private/tmp/dudejs/out/cljs-runtime/script.js:4
cljs.core.prn.cljs$core$IFn$_invoke$arity$variadic(cljs.core.prim_seq.cljs$core$IFn$_invoke$arity$2([Foo.Bar], 0));
                                                                                                     ^

ReferenceError: Foo is not defined

hmm. well technically Dialog.Overlay should be (.-Overlay Dialog)

not sure why it doesn't like it though. no warning during compilation?

definitely shouldn't shouldn't be runtime error only

yes, there is a warning during compilation:

------ WARNING #1 - :undeclared-var --------------------------------------------
 File: /private/tmp/dudejs/src/script.cljs:5:6
--------------------------------------------------------------------------------
   2 |   (:require ["./foo" :refer [Foo #_Foo.Bar]]))
   3 |
   4 | (prn Foo)
   5 | (prn Foo.Bar)
------------^-------------------------------------------------------------------
 Use of undeclared Var script/Foo

ok. yeah the case of symbols with dots is still a bit sketchy all over the place

This works though:

(prn Foo)
(prn (.-Bar Foo))

that is expected yes

there is some code that desugars dotted symbols to the proper access

but it doesn't quite cover all cases

@U05224H0W Do you want an issue for this case?

only if it differs from regular CLJS

the fact that its a local JS require shouldn't matter, behaviour for any require should be the same

Is the fact that it's a JS library at all relevant? E.g. (:require [foo :refer [foo.bar]) ?

don't think so no

but :refer against cljs namespaces is checked in the analyzer data, so might yield errors

for JS this is not the case

For a CLJS namespace this already works:

(ns script
  (:require #_["./foo" :refer [Foo #_Foo.Bar]]
            [bar :refer [Foo]]))

(prn Foo)
(prn (.-Bar Foo))
(prn :dude 1)

where bar is:

(ns bar)

(def Foo #js {:Bar 1})

eh wait, dotted symbol

same problem. Now I'll try vanilla CLJS

vanilla CLJS works

#js {:Bar 1}
1
:dude 1
nil

please try in a build, not a repl

IIRC the repl discards warnings in some cases

clj -M:cljs -m cljs.main -t node -c script

With:

clj -M:cljs -m cljs.main -t node -m script

don't know if you got the above message, went through an area with bad internet, I'm on a train right now

With:

clj -M:cljs -m cljs.main -t node -m script

just open an issue, I'll look into it when I have some time

done

@U04V15CAJ thank you!

and thanks Thomas!

should be fine in 2.20.15

@U05224H0W thank you 🙏

I'm using gitlibs to pull the test code and add it to the classpath, then run the tests within the newly compiled bb

The idea can be borrowed, the code itself probably isn't general enough for this

This is the central part of that code: https://github.com/babashka/babashka/blob/965c177bca31ae9882c975ef7db448e12f59984e/test-resources/lib_tests/babashka/run_all_libtests.clj#L56-L68 I look at a config file which describes which libraries to run tests for. They are present as git libs, so then I find their test directories (as described in the config file), add them to the classpath, and then run.

ok, I might take a look at this next week

Perhaps also of interest: I do canary testing on each commit to rewrite-clj by running canary libs' tests. Canaries are current official lib releases (bumped manually by me). Fwiw, here's the https://github.com/clj-commons/rewrite-clj/blob/main/script/test_libs.clj. The https://github.com/clj-commons/rewrite-clj/blob/main/.github/workflows/libs-test.yml runs canary libs tests in parallel.

Or maybe rewrite-clj head is the canary and the libs I test against are the coal mine, but you get what I mean.