require doesn't work inside of expressions

[chriswatrous]

I'm not sure if this is a Lumo or ClojureScript bug or if it's expected behavior:

cljs.user=> (do (require '[clojure.pprint :refer [pprint]]))
nil
cljs.user=> (pprint "a")
Cannot read property 'pprint' of undefined
     (evalmachine.<anonymous>:1:16)
     Script.runInThisContext (vm.cljs:124:20)
     Object.runInThisContext (vm.cljs:314:38)
     (Object.It)
     (Object.lumo.repl.caching_node_eval)
     (NO_SOURCE_FILE <embedded>:6029:9)
     z (NO_SOURCE_FILE <embedded>:6030:22)
     (NO_SOURCE_FILE <embedded>:6025:264)
     Function.cljs.core.trampoline.cljs$core$IFn$_invoke$arity$1 (NO_SOURCE_FILE <embedded>:1927:142)
     Function.cljs.core.trampoline.cljs$core$IFn$_invoke$arity$variadic (NO_SOURCE_FILE <embedded>:1927:280)

cljs.user=> (try (require '[clojure.pprint :refer [pprint]]))
nil
cljs.user=> (pprint "a")
Cannot read property 'pprint' of undefined
     (evalmachine.<anonymous>:1:16)
     Script.runInThisContext (vm.cljs:124:20)
     Object.runInThisContext (vm.cljs:314:38)
     (Object.It)
     (Object.lumo.repl.caching_node_eval)
     (NO_SOURCE_FILE <embedded>:6029:9)
     z (NO_SOURCE_FILE <embedded>:6030:22)
     (NO_SOURCE_FILE <embedded>:6025:264)
     Function.cljs.core.trampoline.cljs$core$IFn$_invoke$arity$1 (NO_SOURCE_FILE <embedded>:1927:142)
     Function.cljs.core.trampoline.cljs$core$IFn$_invoke$arity$variadic (NO_SOURCE_FILE <embedded>:1927:280)

cljs.user=> (identity (require '[clojure.pprint :refer [pprint]]))
missing ) after argument list
     (new)
     createScript (vm.cljs:266:10)
     Object.runInThisContext (vm.cljs:314:10)
     (Object.It)
     (Object.lumo.repl.caching_node_eval)
     (NO_SOURCE_FILE <embedded>:6029:9)
     z (NO_SOURCE_FILE <embedded>:6030:22)
     (NO_SOURCE_FILE <embedded>:6025:264)
     Function.cljs.core.trampoline.cljs$core$IFn$_invoke$arity$1 (NO_SOURCE_FILE <embedded>:1927:142)
     Function.cljs.core.trampoline.cljs$core$IFn$_invoke$arity$variadic (NO_SOURCE_FILE <embedded>:1927:280)

cljs.user=> (require '[clojure.pprint :refer [pprint]])
nil
cljs.user=> (pprint "a")
"a"
nil

These all work in Clojure.

I noticed this problem because the editor plugin I'm trying to use wraps the expression to be evaluated causing require andns to not work. https://github.com/mauricioszabo/repl-tooling/blob/f7ed777fb66613df82c3e6783ba3bc159c2803ec/src/repl_tooling/repl_client/clojurescript.cljs#L15-L17.

[anmonteiro]

You should be comparing this to ClojureScript on the JVM, not Clojure. I think this is by design but I can't check right now.

[Zabolekar]

It doesn't seem to be a lumo bug. Here's what I was able to reproduce:

JVM Clojurescript with (cljs.repl/repl (cljs.repl.node/repl-env)):

ClojureScript 1.10.758
cljs.user=> (when true (require '[clojure.set :refer [union]]))
goog.require could not find: clojure.set
Execution error (Error) at (<cljs repl>:1).
goog.require could not find: clojure.set

cljs.user=> (node:22086) [DEP0097] DeprecationWarning: Using a domain property in MakeCallback is deprecated. Use the async_context variant of MakeCallback or the AsyncResource class instead.

cljs.user=> (identity (require '[clojure.set :refer [union]]))
Execution error (SyntaxError) at (<cljs repl>:1).
missing ) after argument list

cljs.user=> union
Execution error (TypeError) at (<cljs repl>:1).
Cannot read property 'union' of undefined

cljs.user=> (require '[clojure.set :refer [union]])
nil
cljs.user=> (union #{1 2} #{2 3})
#{1 2 3}

JVM Clojurescript with (cljs.repl/repl (cljs.repl.browser/repl-env)):

ClojureScript 1.10.758
cljs.user=> (when true (require '[clojure.set :refer [union]]))
Execution error (Error) at (<cljs repl>:1).
goog.require could not find: clojure.set

cljs.user=> (identity (require '[clojure.set :refer [union]]))
Execution error (SyntaxError) at (<cljs repl>:1).
missing ) after argument list

cljs.user=> union
Execution error (TypeError) at (<cljs repl>:1).
Cannot read property 'union' of undefined

cljs.user=> (require '[clojure.set :refer [union]])
nil
cljs.user=> (union #{1 2} #{2 3})
#{1 2 3}

However, it doesn't look like a design decision to me, especially the SyntaxError.