[CLJS-2743] Docstring for sort-by misspells "function" Created: 24/Apr/18  Updated: 18/May/18  Resolved: 18/May/18

Status: Closed
Project: ClojureScript
Component/s: None
Affects Version/s: 1.10.238
Fix Version/s: None

Type: Defect Priority: Trivial
Reporter: Mike Fikes Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: docstring, newbie

Attachments: Text File 0001-CLJS-2743-Fix-docstring-misspelling.patch    
Patch: Code
Approval: Accepted

 Description   

Docstring includes "Comp can be boolean-valued comparison funcion"



 Comments   
Comment by Erik Assum [ 17/May/18 3:46 PM ]

Fixed email address

Comment by David Nolen [ 18/May/18 10:34 AM ]

fixed https://github.com/clojure/clojurescript/commit/0ef73e0d02bdff3d3e6c46c2eaf5cfff9cf155ba





[CLJS-3059] Contrary to their docstrings, long and unchecked-long are not identical to int Created: 05/Mar/19  Updated: 05/Mar/19

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: 1.10.238
Fix Version/s: None

Type: Defect Priority: Trivial
Reporter: Miikka Koskinen Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Environment:

ClojureScript 1.10.520, Node 11.10.0



 Description   

The docstrings for cljs.core/long and cljs.core/unchecked-long say: "Coerce to long by stripping decimal places. Identical to `int'." However, their implementation and behavior differs from cljs.core/int. Some examples:

x (int x) (long x)
-5671919744 -1376952448 -5671919744
##Inf 0 ##Inf
"a" 0 ##NaN
"24248082057" -1521721719 24248082057

unchecked-long's implementation is identical to long's so the results are the same. The solution I propose is to just drop the claim about identicalness.






[CLJS-3061] chunked-seq? docstring needs correction Created: 15/Mar/19  Updated: 29/Mar/19  Resolved: 29/Mar/19

Status: Closed
Project: ClojureScript
Component/s: None
Affects Version/s: 1.10.238
Fix Version/s: None

Type: Enhancement Priority: Trivial
Reporter: Sergey A. Assignee: Mike Fikes
Resolution: Completed Votes: 0
Labels: None
Environment:

anything, not relevant here


Attachments: Text File 0001-CLJS-3061-Fix-docstring-for-chunked-seq.patch    
Patch: Code
Approval: Accepted

 Description   

Hi.
core.cljs contains the following piece of code:

(defn ^boolean chunked-seq?
"Return true if x is satisfies IChunkedSeq."
[x] (implements? IChunkedSeq x))

The "if x is satisfies" part hurts my eyes. How about deleting is here?
Thank you.



 Comments   
Comment by Mike Fikes [ 15/Mar/19 7:15 AM ]

LGTM

Comment by Mike Fikes [ 18/Mar/19 6:36 AM ]

0001-CLJS-3061-Fix-docstring-for-chunked-seq.patch does not apply on master

Comment by Erik Assum [ 18/Mar/19 7:05 AM ]

New patch uploaded. Sorry about the screw up.

Comment by Mike Fikes [ 29/Mar/19 1:28 PM ]

fixed https://github.com/clojure/clojurescript/commit/03360446b1252d4a85c894c4538756f327d2a773





[CLJS-2365] Self-host: Unable to reload namespace while in it Created: 18/Sep/17  Updated: 19/Nov/17  Resolved: 19/Nov/17

Status: Closed
Project: ClojureScript
Component/s: None
Affects Version/s: 1.10.238
Fix Version/s: None

Type: Defect Priority: Minor
Reporter: Mike Fikes Assignee: Unassigned
Resolution: Declined Votes: 0
Labels: bootstrap


 Description   

There is an unreleased self-host regression where requiring a namespace while in that namespace triggers circular dependency detection.

As a concrete example, let's say you are in a REPL, and you require a namespace, go into that namespace (using in-ns), exercise it a little, and then change the code to fix something and then reload it. This now fails on master for self-hosted code.

A repro following this example is the following:

(require 'cljs.js)

(def st (cljs.js/empty-state))

(cljs.js/eval st
  '(require (quote foo.core))
  {:context :expr
   :eval cljs.js/js-eval
   :load (fn [_ cb]
           (cb {:lang :clj
                :source "(ns foo.core) (def x 1)"}))}
  prn)

(cljs.js/eval st
  '(require (quote foo.core) :reload)
  {:context :expr
   :ns 'foo.core
   :eval cljs.js/js-eval
   :load (fn [_ cb]
           (cb {:lang :clj
                :source "(ns foo.core) (def x 2)"}))}
  prn)

This causes the following on master, but not with the 1.9.908 release:

{:error #error {:message "Circular dependency detected foo.core -> foo.core", :data {:tag :cljs/analysis-error}}}

(Strictly speaking, the above example is not minimal in that :reload is not required in order to reproduce it: It will happen if you simply attempt to require the namespace while "in" it.)



 Comments   
Comment by Mike Fikes [ 18/Sep/17 10:19 AM ]

Git bisect result implicates CLJS-2356:

238028ccc51afe45de98fb853be4396a71afb602 is the first bad commit
commit 238028ccc51afe45de98fb853be4396a71afb602
Author: Antonio Nuno Monteiro <anmonteiro@gmail.com>
Date:   Sun Sep 10 21:24:22 2017 -0700

    CLJS-2356: Self-host: circular dependency detection is not correct

:040000 040000 a93d466e3f1ea042e730fb78ca911f92319880d0 29108cab4b45247e641d430d85dda85c436e95fe M	src
Comment by Mike Fikes [ 18/Sep/17 3:22 PM ]

Here is the result from some analysis by António and me: There are a few places in the self-host compiler code which make use of :def-emits-var to deduce that self-host is being used to implement a REPL. In particular, the code being exercised in the ticket description works if you include :def-emits-var true in the options passed. But, if you are evaluating a "load" form, such as require and others, if :def-emits-var is set, then it can be seen that code inside the loaded namespaces gets compiled with def (and derived) forms producing Vars. (This can be seen if you make use of the self-hosted caching option.) Perhaps this is incorrect behavior (I believe it doesn't occur with JVM ClojureScript, for example). With the current behavior, if a REPL chooses to not set :def-emits-var true for "load" forms, then you encounter the issue described in the ticket description. So, in short, the underlying issue in this ticket could either be fixed or deemed OK, and the other issue mentioned here regarding def forms inside required namespaces could be split off as a separate ticket that could be pursued on its own.

Comment by Mike Fikes [ 20/Sep/17 1:10 PM ]

With CLJS-2367, I suspect this ticket becomes a non-issue, because REPLs can unconditionally (always) set :def-emits-var.

Comment by Mike Fikes [ 19/Nov/17 8:26 PM ]

Retracting this ticket as I no longer see it as an issue.





[CLJS-2439] FileNoteFoundException thrown when have URL configed in :foreign-libs/:file Created: 12/Dec/17  Updated: 12/Dec/17

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: 1.9.908, 1.10.238
Fix Version/s: None

Type: Defect Priority: Minor
Reporter: Shark Xu Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: cljs, compiler
Environment:

OS: Ubuntu 16.04



 Description   

When I have URL configed in :foreign-libs/:file (via build option or deps.cljs), I get FileNoteFoundException.

URL example: https:/raw.githubusercontent.com/mrdoob/three.js/dev/examples/js/controls/OrbitControls.js

Error Log:

51. Unhandled java.io.FileNotFoundException
6 /home/shark/git/apps/https:/raw.githubusercontent.com/mrdoob/three.js/dev/examples/js/controls/OrbitControls.js
7 (No such file or directory)
8
9 FileInputStream.java: -2 java.io.FileInputStream/open0
10 FileInputStream.java: 195 java.io.FileInputStream/open
11 FileInputStream.java: 138 java.io.FileInputStream/<init>
12 io.clj: 238 clojure.java.io/fn
13 io.clj: 235 clojure.java.io/fn
14 io.clj: 69 clojure.java.io/fn/G
15 io.clj: 165 clojure.java.io/fn
16 io.clj: 69 clojure.java.io/fn/G
18 io.clj: 102 clojure.java.io/reader
19 io.clj: 86 clojure.java.io/reader
20 RestFn.java: 410 clojure.lang.RestFn/invoke
21 closure.clj: 422 cljs.closure/eval7540/fn
22 js_deps.cljc: 121 cljs.js_deps$eval2733$fn_2756$G2724_2765/invoke
23 closure.clj: 418 cljs.closure/eval7540/fn
24 js_deps.cljc: 121 cljs.js_deps$eval2733$fn_2756$G2724_2765/invoke
25 closure.clj: 1723 cljs.closure/write-javascript
26 closure.clj: 1699 cljs.closure/write-javascript
27 closure.clj: 1748 cljs.closure/source-on-disk
28 closure.clj: 1743 cljs.closure/source-on-disk
29 closure.clj: 2604 cljs.closure/build/fn
30 core.clj: 2646 clojure.core/map/fn
31 LazySeq.java: 40 clojure.lang.LazySeq/sval
32 LazySeq.java: 49 clojure.lang.LazySeq/seq
33 Cons.java: 39 clojure.lang.Cons/next
34 RT.java: 688 clojure.lang.RT/next
35 core.clj: 64 clojure.core/next
36 core.clj: 3033 clojure.core/dorun
37 core.clj: 3039 clojure.core/doall
38 closure.clj: 2604 cljs.closure/build
40 closure.clj: 2507 cljs.closure/build
41 api.clj: 205 cljs.build.api/build
42 api.clj: 189 cljs.build.api/build
43 api.clj: 192 cljs.build.api/build
44 api.clj: 189 cljs.build.api/build
45 REPL: 62 apps.cljs-rt-browser/-main



 Comments   
Comment by Shark Xu [ 12/Dec/17 8:30 AM ]

Add my config code:

1{:foreign-libs
2 [{:file "https://raw.githubusercontent.com/mrdoob/three.js/dev/examples/js/controls/OrbitControls.js"
3 :provides ["cljsjs.three-orbitcontrols"]
4 :requires ["cljsjs.three"]
5 }
6 {:file "https://raw.githubusercontent.com/dataarts/dat.gui/master/build/dat.gui.js"
7 :provides ["cljsjs.dat-gui"]
8 }
9 {:file "https://raw.githubusercontent.com/mrdoob/three.js/dev/examples/js/ParametricGeometries.js"
10 :provides ["cljsjs.three-parametricgeometries"]
11 :requires ["cljsjs.three"]
12 }
13
14 ]
15 }





[CLJS-2734] Add :arglists to defmulti Created: 11/Apr/18  Updated: 13/Apr/18  Resolved: 13/Apr/18

Status: Closed
Project: ClojureScript
Component/s: None
Affects Version/s: 1.10.238
Fix Version/s: None

Type: Enhancement Priority: Minor
Reporter: Mike Fikes Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: docstring

Attachments: Text File CLJS-2734.patch    
Patch: Code

 Description   

(doc defmulti) in ClojureScript doesn't show the arg list as in Clojure.

ClojureScript:

cljs.user=> (doc defmulti)
-------------------------
cljs.core/defmulti
([mm-name & options])
Macro
  Creates a new multimethod with the associated dispatch function.
  The docstring and attribute-map are optional.
...

Clojure:

user=> (doc defmulti)
-------------------------
clojure.core/defmulti
([name docstring? attr-map? dispatch-fn & options])
Macro
  Creates a new multimethod with the associated dispatch function.
  The docstring and attr-map are optional.
...


 Comments   
Comment by David Nolen [ 13/Apr/18 3:06 PM ]

fixed https://github.com/clojure/clojurescript/commit/ce505b99dd791a728102bfb95b80ec481b931173





[CLJS-2722] result of eval-str callback no longer returned Created: 03/Apr/18  Updated: 13/Apr/18  Resolved: 13/Apr/18

Status: Resolved
Project: ClojureScript
Component/s: None
Affects Version/s: 1.10.238
Fix Version/s: None

Type: Defect Priority: Minor
Reporter: Richard Davies Assignee: Unassigned
Resolution: Declined Votes: 0
Labels: None


 Description   

Prior to 1.10.238 this code

(cjs/eval-str (cjs/empty-state) "(+ 1 1)" nil {:eval cjs/js-eval} (fn [x] (println x) x))

The callback would print the result map and then eval-str would return the result of the callback. Since 1.10.238 this code returns nil. While it is still possible to get at the result from the callback, the previous behaviour was convenient and the absence of a return value may break existing code.



 Comments   
Comment by Mike Fikes [ 08/Apr/18 5:22 PM ]

This is not a defect. IIRC, the observed change in behavior is a result of https://github.com/clojure/clojurescript/commit/a1d49b536b714c16d2d6a292593662eba100dccb#diff-2de6ee5c159942f834b2dabed7c891b1





[CLJS-2543] IndexingPushbackReader error when compiling :reload-all with cljs.spec.alpha Created: 22/Feb/18  Updated: 22/Feb/18

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: 1.10.238
Fix Version/s: None

Type: Defect Priority: Minor
Reporter: Andrea Richiardi Assignee: David Nolen
Resolution: Unresolved Votes: 1
Labels: None

Attachments: Text File cljs-master-error.txt    

 Description   

There seems to be an error when the following happens:

(ns repro.a-namespace
  (:require [cljs.spec.alpha :as s] :reload-all))

There is a repro here: https://github.com/arichiardi/cljs-reload-all-repro

The stack is enormous so I attached a file but the gist of it is:

Caused by: clojure.lang.ExceptionInfo: No implementation of method: :read-char of protocol: #'clojure.tools.reader.reader-types/Reader found for class: clojure.tools.reader.reader_types.IndexingPushbackReader {:type :reader-exception}
	at clojure.core$ex_info.invokeStatic(core.clj:4739)
	at clojure.core$ex_info.invoke(core.clj:4739)
	at clojure.tools.reader$read_STAR_.invokeStatic(reader.clj:941)
	at clojure.tools.reader$read_STAR_.invoke(reader.clj:905)
	at clojure.tools.reader$read.invokeStatic(reader.clj:972)
	at clojure.tools.reader$read.invoke(reader.clj:949)
	at cljs.analyzer$forms_seq_STAR_$forms_seq___3119$fn__3120$fn__3121.invoke(analyzer.cljc:3676)
	at cljs.analyzer$forms_seq_STAR_$forms_seq___3119$fn__3120.invoke(analyzer.cljc:3669)
	at clojure.lang.LazySeq.sval(LazySeq.java:40)
	at clojure.lang.LazySeq.seq(LazySeq.java:49)
	at clojure.lang.RT.seq(RT.java:528)
	at clojure.core$seq__5124.invokeStatic(core.clj:137)
	at clojure.core$seq__5124.invoke(core.clj:137)
	at cljs.compiler$emit_source.invokeStatic(compiler.cljc:1389)
	at cljs.compiler$emit_source.invoke(compiler.cljc:1370)
	at cljs.compiler$compile_file_STAR_$fn__4580.invoke(compiler.cljc:1471)
	at cljs.compiler$with_core_cljs.invokeStatic(compiler.cljc:1285)
	at cljs.compiler$with_core_cljs.invoke(compiler.cljc:1274)
	at cljs.compiler$compile_file_STAR_.invokeStatic(compiler.cljc:1456)
	at cljs.compiler$compile_file_STAR_.invoke(compiler.cljc:1449)
	at cljs.compiler$compile_file$fn__4611.invoke(compiler.cljc:1553)
	... 37 more


 Comments   
Comment by Mike Fikes [ 22/Feb/18 1:43 PM ]

Minimal repro, with no links to projects:

Place the following in src/repro/a_namespace.cljs:

(ns repro.a-namespace
  (:require [cljs.spec.alpha :as s]))

and compile with

clojure -Sdeps '{:deps {org.clojurescript {:git/url "https://github.com/clojure/clojurescript" :sha "7c754fbb9ffb9da790f21776d53a3b83deef922b"}}}' -m cljs.main -O simple -t node -c repro.a-namespace

This will compile properly.

Then revise the source file to add :reload-all in the ns form:

(ns repro.a-namespace
  (:require [cljs.spec.alpha :as s] :reload-all))

and attempt the same compile:

$ clojure -Sdeps '{:deps {org.clojurescript {:git/url "https://github.com/clojure/clojurescript" :sha "7c754fbb9ffb9da790f21776d53a3b83deef922b"}}}' -m cljs.main -O simple -t node -c repro.a-namespace
Exception in thread "main" clojure.lang.ExceptionInfo: failed compiling file:/Users/mfikes/Desktop/src/repro/a_namespace.cljs {:file #object[java.io.File 0x2904bb45 "/Users/mfikes/Desktop/src/repro/a_namespace.cljs"]}
	at clojure.core$ex_info.invokeStatic(core.clj:4739)
	at clojure.core$ex_info.invoke(core.clj:4739)
	at cljs.compiler$compile_file$fn__4619.invoke(compiler.cljc:1567)
	at cljs.compiler$compile_file.invokeStatic(compiler.cljc:1528)
	at cljs.compiler$compile_file.invoke(compiler.cljc:1504)
	at cljs.closure$compile_file.invokeStatic(closure.clj:558)
	at cljs.closure$compile_file.invoke(closure.clj:549)
	at cljs.closure$eval6938$fn__6939.invoke(closure.clj:627)
	at cljs.closure$eval6874$fn__6875$G__6863__6882.invoke(closure.clj:511)
	at cljs.closure$compile_sources$iter__7062__7066$fn__7067.invoke(closure.clj:972)
	at clojure.lang.LazySeq.sval(LazySeq.java:40)
	at clojure.lang.LazySeq.seq(LazySeq.java:49)
	at clojure.lang.Cons.next(Cons.java:39)
	at clojure.lang.RT.next(RT.java:706)
	at clojure.core$next__5108.invokeStatic(core.clj:64)
	at clojure.core$dorun.invokeStatic(core.clj:3134)
	at clojure.core$doall.invokeStatic(core.clj:3140)
	at clojure.core$doall.invoke(core.clj:3140)
	at cljs.closure$compile_sources.invokeStatic(closure.clj:968)
	at cljs.closure$compile_sources.invoke(closure.clj:957)
	at cljs.closure$build.invokeStatic(closure.clj:2756)
	at cljs.closure$build.invoke(closure.clj:2662)
	at cljs.build.api$build.invokeStatic(api.clj:205)
	at cljs.build.api$build.invoke(api.clj:189)
	at cljs.build.api$build.invokeStatic(api.clj:192)
	at cljs.build.api$build.invoke(api.clj:189)
	at cljs.cli$default_compile.invokeStatic(cli.clj:299)
	at cljs.cli$default_compile.invoke(cli.clj:274)
	at cljs.cli$compile_opt.invokeStatic(cli.clj:305)
	at cljs.cli$compile_opt.invoke(cli.clj:303)
	at cljs.cli$main.invokeStatic(cli.clj:427)
	at cljs.cli$main.doInvoke(cli.clj:416)
	at clojure.lang.RestFn.applyTo(RestFn.java:139)
	at clojure.core$apply.invokeStatic(core.clj:659)
	at clojure.core$apply.invoke(core.clj:652)
	at cljs.main$_main.invokeStatic(main.clj:60)
	at cljs.main$_main.doInvoke(main.clj:52)
	at clojure.lang.RestFn.applyTo(RestFn.java:137)
	at clojure.lang.Var.applyTo(Var.java:702)
	at clojure.core$apply.invokeStatic(core.clj:657)
	at clojure.main$main_opt.invokeStatic(main.clj:317)
	at clojure.main$main_opt.invoke(main.clj:313)
	at clojure.main$main.invokeStatic(main.clj:424)
	at clojure.main$main.doInvoke(main.clj:387)
	at clojure.lang.RestFn.applyTo(RestFn.java:137)
	at clojure.lang.Var.applyTo(Var.java:702)
	at clojure.main.main(main.java:37)
Caused by: clojure.lang.ExceptionInfo: No implementation of method: :read-char of protocol: #'clojure.tools.reader.reader-types/Reader found for class: clojure.tools.reader.reader_types.IndexingPushbackReader {:type :reader-exception}
	at clojure.core$ex_info.invokeStatic(core.clj:4739)
	at clojure.core$ex_info.invoke(core.clj:4739)
	at clojure.tools.reader$read_STAR_.invokeStatic(reader.clj:941)
	at clojure.tools.reader$read_STAR_.invoke(reader.clj:905)
	at clojure.tools.reader$read.invokeStatic(reader.clj:972)
	at clojure.tools.reader$read.invoke(reader.clj:949)
	at cljs.analyzer$forms_seq_STAR_$forms_seq___3329$fn__3330$fn__3331.invoke(analyzer.cljc:3676)
	at cljs.analyzer$forms_seq_STAR_$forms_seq___3329$fn__3330.invoke(analyzer.cljc:3669)
	at clojure.lang.LazySeq.sval(LazySeq.java:40)
	at clojure.lang.LazySeq.seq(LazySeq.java:49)
	at clojure.lang.RT.seq(RT.java:528)
	at clojure.core$seq__5124.invokeStatic(core.clj:137)
	at clojure.core$seq__5124.invoke(core.clj:137)
	at cljs.compiler$emit_source.invokeStatic(compiler.cljc:1389)
	at cljs.compiler$emit_source.invoke(compiler.cljc:1370)
	at cljs.compiler$compile_file_STAR_$fn__4588.invoke(compiler.cljc:1471)
	at cljs.compiler$with_core_cljs.invokeStatic(compiler.cljc:1285)
	at cljs.compiler$with_core_cljs.invoke(compiler.cljc:1274)
	at cljs.compiler$compile_file_STAR_.invokeStatic(compiler.cljc:1456)
	at cljs.compiler$compile_file_STAR_.invoke(compiler.cljc:1449)
	at cljs.compiler$compile_file$fn__4619.invoke(compiler.cljc:1553)
	... 44 more
Caused by: java.lang.IllegalArgumentException: No implementation of method: :read-char of protocol: #'clojure.tools.reader.reader-types/Reader found for class: clojure.tools.reader.reader_types.IndexingPushbackReader
	at clojure.core$_cache_protocol_fn.invokeStatic(core_deftype.clj:583)
	at clojure.core$_cache_protocol_fn.invoke(core_deftype.clj:575)
	at clojure.tools.reader.reader_types$eval19106$fn__19118$G__19095__19123.invoke(reader_types.clj:24)
	at clojure.tools.reader$read_STAR_.invokeStatic(reader.clj:916)
	... 62 more




[CLJS-2741] Function invoke errors report arity off by 1 Created: 21/Apr/18  Updated: 07/May/18  Resolved: 07/May/18

Status: Closed
Project: ClojureScript
Component/s: None
Affects Version/s: 1.10.238
Fix Version/s: None

Type: Defect Priority: Minor
Reporter: Mike Fikes Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: error-reporting, errormsgs, regression

Attachments: Text File CLJS-2741.patch    
Patch: Code and Test

 Description   

((fn ([x]) ([x y]))) results in Error: Invalid arity: -1
((fn ([x]) ([x y])) 1 2 3) results in Error: Invalid arity: 2

This is a regression caused by CLJS-1519.



 Comments   
Comment by David Nolen [ 07/May/18 3:40 PM ]

fixed https://github.com/clojure/clojurescript/commit/e4e4a295cda29ea81d3798e553673bc745c5f4bc





[CLJS-2736] Elements returned from sets as functions are not the actual elements in the set. Created: 13/Apr/18  Updated: 15/Jun/18  Resolved: 15/Jun/18

Status: Closed
Project: ClojureScript
Component/s: None
Affects Version/s: 1.10.238
Fix Version/s: None

Type: Defect Priority: Minor
Reporter: Paula Gearon Assignee: David Nolen
Resolution: Completed Votes: 1
Labels: bug


 Description   

When a set called as a function returns an element, then the argument is returned rather than the element of the set. This is apparent when the values have metadata:

=> (def my-set #{(with-meta [:a] {:n 42})})
=> (meta (my-set [:a]))
nil
=> (meta (my-set (with-meta [:a] {:x 1})))
{:x 1}


 Comments   
Comment by Paula Gearon [ 13/Apr/18 2:05 PM ]

As per Enzzo Cavallo, this is in the code for -lookup on PersistentHashSet.
(existing code)

(-lookup [coll v not-found]
    (if (-contains-key? hash-map v)
      v
      not-found))

My suggestion is to use similar code to -lookup on PersistentTreeSet (which does not have this bug).

(suggested code)

(-lookup [coll v not-found]
    (if-let [entry (-find hash-map v)
      (key entry)
      not-found))
Comment by David Nolen [ 15/Jun/18 2:39 PM ]

fixed https://github.com/clojure/clojurescript/commit/6b7e9402dd841eeb63e2bb3ae3b397eced388def





[CLJS-2749] Internal compiler error with npm dependency on hc-sticky Created: 08/May/18  Updated: 15/Jun/18

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: 1.10.238
Fix Version/s: None

Type: Defect Priority: Minor
Reporter: Vlad Protsenko Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None


 Description   

I try to add {:install-deps true :npm-deps {:hc-sticky "2.1.6"} ,,,} to my cljsbuild definition, but then it throws exception:

vlaaad@laptop ~/P/repka> lein cljsbuild once dev                                                                                                                                                          master!+?
Compiling ClojureScript...
Compiling ["resources/public/js/app.js"] from ["src/cljs" "src/cljc" "env/dev/cljs"]...
Compiling ["resources/public/js/app.js"] failed.
java.lang.RuntimeException: INTERNAL COMPILER ERROR.
Please report this problem.

The new child node has previous siblings.
  Node(SCRIPT): /home/vlaaad/Projects/repka/node_modules/hc-sticky/dist/hc-sticky.js:11:0
!function(t,e){"use strict";if("object"==typeof module&&"object"==typeof module.exports){if(!t.document)throw new Error("HC-Sticky requires a browser to run.");module.exports=e(t)}else"function"==typeof define&&define.amd?define("hcSticky",[],e(t)):e(t)}("undefined"!=typeof window?window:this,function(t){"use strict";var e={top:0,bottom:0,bottomEnd:0,innerTop:0,innerSticker:null,stickyClass:"sticky",stickTo:null,followScroll:!0,queries:null,queryFlow:"down",onStart:null,onStop:null,onBeforeResize:null,onResize:null,resizeDebounce:100,disable:!1},o=t.document,n=function(i,s){if("string"==typeof i&&(i=o.querySelector(i)),!i)return!1;var r={},a=n.Helpers,l=i.parentNode;"static"===a.getStyle(l,"position")&&(l.style.position="relative");var c=function(){var t=arguments.length>0&&void 0!==arguments[0]?arguments[0]:{};a.isEmptyObject(t)&&!a.isEmptyObject(r)||(r=Object.assign({},e,r,t))},f=function(){return r.disable},p=function(){if(r.queries){var o=t.innerWidth,n=r.queryFlow,i=r.queries;if(function(t){r=Object.assign({},e,t||{})}(s),"up"===n)for(var l in i)o>=l&&!a.isEmptyObject(i[l])&&c(i[l]);else{var f=[];for(var p in r.queries){var u={};u[p]=i[p],f.push(u)}for(var d=f.length-1;d>=0;d--){var g=f[d],m=Object.keys(g)[0];o<=m&&!a.isEmptyObject(g[m])&&c(g[m])}}}},u={css:{},position:null,stick:function(){var t=arguments.length>0&&void 0!==arguments[0]?arguments[0]:{};a.hasClass(i,r.stickyClass)||(!1===d.isAttached&&d.attach(),u.position="fixed",i.style.position="fixed",i.style.left=d.offsetLeft+"px",i.style.width=d.width,void 0===t.bottom?i.style.bottom="auto":i.style.bottom=t.bottom+"px",void 0===t.top?i.style.top="auto":i.style.top=t.top+"px",i.classList?i.classList.add(r.stickyClass):i.className+=" "+r.stickyClass,r.onStart&&r.onStart.call(i,r))},release:function(){var t=arguments.length>0&&void 0!==arguments[0]?arguments[0]:{};if(t.stop=t.stop||!1,!0===t.stop||"fixed"===u.position||null===u.position||!(void 0===t.top&&void 0===t.bottom||void 0!==t.top&&(parseInt(a.getStyle(i,"top"))||0)===t.top||void 0!==t.bottom&&(parseInt(a.getStyle(i,"bottom"))||0)===t.bottom)){!0===t.stop?!0===d.isAttached&&d.detach():!1===d.isAttached&&d.attach();var e=t.position||u.css.position;u.position=e,i.style.position=e,i.style.left=!0===t.stop?u.css.left:d.positionLeft+"px",i.style.width="absolute"!==e?u.css.width:d.width,void 0===t.bottom?i.style.bottom=!0===t.stop?"":"auto":i.style.bottom=t.bottom+"px",void 0===t.top?i.style.top=!0===t.stop?"":"auto":i.style.top=t.top+"px",i.classList?i.classList.remove(r.stickyClass):i.className=i.className.replace(new RegExp("(^|\\b)"+r.stickyClass.split(" ").join("|")+"(\\b|$)","gi")," "),r.onStop&&r.onStop.call(i,r)}}},d={el:o.createElement("div"),offsetLeft:null,positionLeft:null,width:null,isAttached:!1,init:function(){for(var t in u.css)d.el.style[t]=u.css[t];var e=a.getStyle(i);d.offsetLeft=a.offset(i).left-(parseInt(e.marginLeft)||0),d.positionLeft=a.position(i).left,d.width=a.getStyle(i,"width")},attach:function(){l.insertBefore(d.el,i.nextSibling),d.isAttached=!0},detach:function(){d.el=l.removeChild(d.el),d.isAttached=!1}},g=void 0,m=void 0,h=void 0,y=void 0,v=void 0,b=void 0,S=void 0,w=void 0,k=void 0,E=void 0,x=void 0,L=void 0,T=void 0,j=void 0,O=void 0,C=void 0,z=void 0,N=void 0,R=function(){u.css=function(t){var e=a.getCascadedStyle(t),o=a.getStyle(t),n={height:t.offsetHeight+"px",left:e.left,right:e.right,top:e.top,bottom:e.bottom,position:o.position,display:o.display,verticalAlign:o.verticalAlign,boxSizing:o.boxSizing,marginLeft:e.marginLeft,marginRight:e.marginRight,marginTop:e.marginTop,marginBottom:e.marginBottom,paddingLeft:e.paddingLeft,paddingRight:e.paddingRight};return e.float&&(n.float=e.float||"none"),e.cssFloat&&(n.cssFloat=e.cssFloat||"none"),o.MozBoxSizing&&(n.MozBoxSizing=o.MozBoxSizing),n.width="auto"!==e.width?e.width:"border-box"===n.boxSizing||"border-box"===n.MozBoxSizing?t.offsetWidth+"px":o.width,n}(i),d.init(),g=!(!r.stickTo||!("document"===r.stickTo||r.stickTo.nodeType&&9===r.stickTo.nodeType||"object"==typeof r.stickTo&&r.stickTo instanceof("undefined"!=typeof HTMLDocument?HTMLDocument:Document))),m=r.stickTo?g?o:"string"==typeof r.stickTo?o.querySelector(r.stickTo):r.stickTo:l,O=(N=function(){var t=i.offsetHeight+(parseInt(u.css.marginTop)||0)+(parseInt(u.css.marginBottom)||0),e=(O||0)-t;return e>=-1&&e<=1?O:t})(),y=(z=function(){return g?Math.max(o.documentElement.clientHeight,o.body.scrollHeight,o.documentElement.scrollHeight,o.body.offsetHeight,o.documentElement.offsetHeight):m.offsetHeight})(),v=g?0:a.offset(m).top,b=r.stickTo?g?0:a.offset(l).top:v,S=t.innerHeight,C=i.offsetTop-(parseInt(u.css.marginTop)||0),h=r.innerSticker?"string"==typeof r.innerSticker?o.querySelector(r.innerSticker):r.innerSticker:null,w=isNaN(r.top)&&r.top.indexOf("%")>-1?parseFloat(r.top)/100*S:r.top,k=isNaN(r.bottom)&&r.bottom.indexOf("%")>-1?parseFloat(r.bottom)/100*S:r.bottom,E=h?h.offsetTop:r.innerTop?r.innerTop:0,x=isNaN(r.bottomEnd)&&r.bottomEnd.indexOf("%")>-1?parseFloat(r.bottomEnd)/100*S:r.bottomEnd,L=v-w+E+C},H=t.pageYOffset||o.documentElement.scrollTop,A=0,B=void 0,I=function(){O=N(),y=z(),T=v+y-w-x,j=O>S;var e=t.pageYOffset||o.documentElement.scrollTop,n=Math.round(a.offset(i).top),s=n-e,c=void 0;B=e<H?"up":"down",A=e-H,H=e,e>L?T+w+(j?k:0)-(r.followScroll&&j?0:w)<=e+O-E-(O-E>S-(L-E)&&r.followScroll&&(c=O-S-E)>0?c:0)?u.release({position:"absolute",bottom:b+l.offsetHeight-T-w}):j&&r.followScroll?"down"===B?s+O+k<=S?u.stick({bottom:k}):"fixed"===u.position&&u.release({position:"absolute",top:n-w-L-A+E}):s+E<0&&"fixed"===u.position?u.release({position:"absolute",top:n-w-L+E-A}):n>=e+w-E&&u.stick({top:w-E}):u.stick({top:w-E}):u.release({stop:!0})},q=!1,F=!1,M=function(){q&&(a.event.unbind(t,"scroll",I),q=!1)},D=function(){R(),O>=y?M():(I(),q||(a.event.bind(t,"scroll",I),q=!0))},W=function(){i.style.position="",i.style.left="",i.style.top="",i.style.bottom="",i.style.width="",i.classList?i.classList.remove(r.stickyClass):i.className=i.className.replace(new RegExp("(^|\\b)"+r.stickyClass.split(" ").join("|")+"(\\b|$)","gi")," "),u.css={},u.position=null,!0===d.isAttached&&d.detach()},P=function(){W(),p(),f()?M():D()},V=function(){r.onBeforeResize&&r.onBeforeResize.call(i,r),P(),r.onResize&&r.onResize.call(i,r)},Y=r.resizeDebounce?a.debounce(V,r.resizeDebounce):V,$=function(){F&&(a.event.unbind(t,"resize",Y),F=!1),M()},Q=function(){F||(a.event.bind(t,"resize",Y),F=!0),p(),f()?M():D()};this.options=function(t){return t?r.option||null:Object.assign({},r)},this.reinit=P,this.update=function(t){c(t),s=Object.assign({},s,t||{}),P()},this.attach=Q,this.detach=$,this.destroy=function(){$(),W()},c(s),Q(),a.event.bind(t,"load",P)};if(void 0!==t.jQuery){var i=t.jQuery;i.fn.extend({hcSticky:function(t){return this.length?this.each(function(){var e=i.data(this,"hcSticky");e?e.update(t):(e=new n(this,t),i.data(this,"hcSticky",e))}):this}})}return t.hcSticky=t.hcSticky||n,n}),function(t){"use strict";var e=t.hcSticky,o=t.document;"function"!=typeof Object.assign&&Object.defineProperty(Object,"assign",{value:function(t,e){if(null==t)throw new TypeError("Cannot convert undefined or null to object");for(var o=Object(t),n=1;n<arguments.length;n++){var i=arguments[n];if(null!=i)for(var s in i)Object.prototype.hasOwnProperty.call(i,s)&&(o[s]=i[s])}return o},writable:!0,configurable:!0}),Array.prototype.forEach||(Array.prototype.forEach=function(t){var e,o;if(null==this)throw new TypeError("this is null or not defined");var n=Object(this),i=n.length>>>0;if("function"!=typeof t)throw new TypeError(t+" is not a function");for(arguments.length>1&&(e=arguments[1]),o=0;o<i;){var s;o in n&&(s=n[o],t.call(e,s,o,n)),o++}});var n=function(){function e(e){var o=t.event;return o.target=o.target||o.srcElement||e,o}var n=o.documentElement,i=function(){};n.addEventListener?i=function(t,e,o){t.addEventListener(e,o,!1)}:n.attachEvent&&(i=function(t,o,n){t[o+n]=n.handleEvent?function(){var o=e(t);n.handleEvent.call(n,o)}:function(){var o=e(t);n.call(t,o)},t.attachEvent("on"+o,t[o+n])});var s=function(){};return n.removeEventListener?s=function(t,e,o){t.removeEventListener(e,o,!1)}:n.detachEvent&&(s=function(t,e,o){t.detachEvent("on"+e,t[e+o]);try{delete t[e+o]}catch(n){t[e+o]=void 0}}),{bind:i,unbind:s}}(),i=function(e,n){return t.getComputedStyle?n?o.defaultView.getComputedStyle(e,null).getPropertyValue(n):o.defaultView.getComputedStyle(e,null):e.currentStyle?n?e.currentStyle[n.replace(/-\w/g,function(t){return t.toUpperCase().replace("-","")})]:e.currentStyle:void 0},s=function(e){var n=e.getBoundingClientRect(),i=t.pageYOffset||o.documentElement.scrollTop,s=t.pageXOffset||o.documentElement.scrollLeft;return{top:n.top+i,left:n.left+s}};e.Helpers={isEmptyObject:function(t){for(var e in t)return!1;return!0},debounce:function(t,e,o){var n=void 0;return function(){var i=this,s=arguments,r=o&&!n;clearTimeout(n),n=setTimeout(function(){n=null,o||t.apply(i,s)},e),r&&t.apply(i,s)}},hasClass:function(t,e){return t.classList?t.classList.contains(e):new RegExp("(^| )"+e+"( |$)","gi").test(t.className)},offset:s,position:function(t){var e=t.offsetParent,o=s(e),n=s(t),r=i(e),a=i(t);return o.top+=parseInt(r.borderTopWidth)||0,o.left+=parseInt(r.borderLeftWidth)||0,{top:n.top-o.top-(parseInt(a.marginTop)||0),left:n.left-o.left-(parseInt(a.marginLeft)||0)}},getStyle:i,getCascadedStyle:function(e){var n=e.cloneNode(!0);n.style.display="none",Array.prototype.slice.call(n.querySelectorAll('input[type="radio"]')).forEach(function(t){t.removeAttribute("name")}),e.parentNode.insertBefore(n,e.nextSibling);var i=void 0;n.currentStyle?i=n.currentStyle:t.getComputedStyle&&(i=o.defaultView.getComputedStyle(n,null));var s={};for(var r in i)!isNaN(r)||"string"!=typeof i[r]&&"number"!=typeof i[r]||(s[r]=i[r]);if(Object.keys(s).length<3){s={};for(var a in i)isNaN(a)||(s[i[a].replace(/-\w/g,function(t){return t.toUpperCase().replace("-","")})]=i.getPropertyValue(i[a]))}if(s.margin||"auto"!==s.marginLeft?s.margin||s.marginLeft!==s.marginRight||s.marginLeft!==s.marginTop||s.marginLeft!==s.marginBottom||(s.margin=s.marginLeft):s.margin="auto",!s.margin&&"0px"===s.marginLeft&&"0px"===s.marginRight){var l=e.offsetLeft-e.parentNode.offsetLeft,c=l-(parseInt(s.left)||0)-(parseInt(s.right)||0),f=e.parentNode.offsetWidth-e.offsetWidth-l-(parseInt(s.right)||0)+(parseInt(s.left)||0)-c;0!==f&&1!==f||(s.margin="auto")}return n.parentNode.removeChild(n),n=null,s},event:n}}(window);
  Parent(ROOT): [source unknown]

	at com.google.common.base.Preconditions.checkArgument(Preconditions.java:134)
	at com.google.javascript.rhino.Node.replaceChild(Node.java:872)
	at com.google.javascript.jscomp.ProcessCommonJSModules$FindImportsAndExports.replaceUmdPatterns(ProcessCommonJSModules.java:1040)
	at com.google.javascript.jscomp.ProcessCommonJSModules.shouldTraverse(ProcessCommonJSModules.java:102)
	at com.google.javascript.jscomp.NodeTraversal.handleScript(NodeTraversal.java:723)
	at com.google.javascript.jscomp.NodeTraversal.traverseBranch(NodeTraversal.java:749)
	at com.google.javascript.jscomp.NodeTraversal.traverseChildren(NodeTraversal.java:843)
	at com.google.javascript.jscomp.NodeTraversal.traverseBranch(NodeTraversal.java:768)
	at com.google.javascript.jscomp.NodeTraversal.traverse(NodeTraversal.java:305)
	at com.google.javascript.jscomp.NodeTraversal.traverseEs6(NodeTraversal.java:680)
	at com.google.javascript.jscomp.ProcessCommonJSModules.process(ProcessCommonJSModules.java:75)
	at com.google.javascript.jscomp.Compiler.whitespaceOnlyPasses(Compiler.java:1040)
	at cljs.closure$convert_js_modules.invokeStatic(closure.clj:1831)
	at cljs.closure$convert_js_modules.invoke(closure.clj:1810)
	at cljs.closure$process_js_modules.invokeStatic(closure.clj:2557)
	at cljs.closure$process_js_modules.invoke(closure.clj:2518)
	at cljs.closure$handle_js_modules.invokeStatic(closure.clj:2672)
	at cljs.closure$handle_js_modules.invoke(closure.clj:2633)
	at cljs.closure$build.invokeStatic(closure.clj:2814)
	at cljs.closure$build.invoke(closure.clj:2718)
	at cljs.build.api$build.invokeStatic(api.clj:208)
	at cljs.build.api$build.invoke(api.clj:189)
	at cljs.build.api$build.invokeStatic(api.clj:195)
	at cljs.build.api$build.invoke(api.clj:189)
	at cljsbuild.compiler$compile_cljs$fn__718.invoke(compiler.clj:61)
	at cljsbuild.compiler$compile_cljs.invokeStatic(compiler.clj:60)
	at cljsbuild.compiler$compile_cljs.invoke(compiler.clj:48)
	at cljsbuild.compiler$run_compiler.invokeStatic(compiler.clj:168)
	at cljsbuild.compiler$run_compiler.invoke(compiler.clj:129)
	at user$eval847$iter__895__899$fn__900$fn__926.invoke(form-init3044140597862699919.clj:1)
	at user$eval847$iter__895__899$fn__900.invoke(form-init3044140597862699919.clj:1)
	at clojure.lang.LazySeq.sval(LazySeq.java:40)
	at clojure.lang.LazySeq.seq(LazySeq.java:49)
	at clojure.lang.RT.seq(RT.java:528)
	at clojure.core$seq__5124.invokeStatic(core.clj:137)
	at clojure.core$dorun.invokeStatic(core.clj:3125)
	at clojure.core$doall.invokeStatic(core.clj:3140)
	at clojure.core$doall.invoke(core.clj:3140)
	at user$eval847.invokeStatic(form-init3044140597862699919.clj:1)
	at user$eval847.invoke(form-init3044140597862699919.clj:1)
	at clojure.lang.Compiler.eval(Compiler.java:7062)
	at clojure.lang.Compiler.eval(Compiler.java:7052)
	at clojure.lang.Compiler.load(Compiler.java:7514)
	at clojure.lang.Compiler.loadFile(Compiler.java:7452)
	at clojure.main$load_script.invokeStatic(main.clj:278)
	at clojure.main$init_opt.invokeStatic(main.clj:280)
	at clojure.main$init_opt.invoke(main.clj:280)
	at clojure.main$initialize.invokeStatic(main.clj:311)
	at clojure.main$null_opt.invokeStatic(main.clj:345)
	at clojure.main$null_opt.invoke(main.clj:342)
	at clojure.main$main.invokeStatic(main.clj:424)
	at clojure.main$main.doInvoke(main.clj:387)
	at clojure.lang.RestFn.applyTo(RestFn.java:137)
	at clojure.lang.Var.applyTo(Var.java:702)
	at clojure.main.main(main.java:37)
Caused by: java.lang.IllegalArgumentException: The new child node has previous siblings.
	... 55 more
Subprocess failed



 Comments   
Comment by Mike Fikes [ 12/May/18 8:06 AM ]

Hey Vlad, please see https://clojurescript.org/community/reporting-issues regarding creating a minimal repro.

For example, if you were to run the following, what would need to be in src/foo/core.cljs to repro?

clj -m cljs.main -co '{:install-deps true, :npm-deps {:hc-sticky "2.1.6"}}' -O simple -o main.js -t node -c foo.core




[CLJS-2783] with-out-str conflicts with :infer-externs Created: 16/Jun/18  Updated: 16/Jun/18  Resolved: 16/Jun/18

Status: Closed
Project: ClojureScript
Component/s: None
Affects Version/s: 1.10.238
Fix Version/s: None

Type: Defect Priority: Minor
Reporter: Gal Dolber Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: infer-externs
Environment:

macOS


Patch: Code
Approval: Accepted

 Description   
(println (with-out-str (println "bug")))

Produces the following warning by producing a wrong inferred-externs.js:

WARNING: target/node/dev/inferred_externs.js:3: WARNING - name goog is not defined in the externs.
goog.string;
^^^^

Jun 16, 2018 2:55:45 PM com.google.javascript.jscomp.LoggerErrorManager println
WARNING: target/node/dev/inferred_externs.js:4: WARNING - name goog is not defined in the externs.
goog.string.StringBuffer;
^^^^

Jun 16, 2018 2:55:45 PM com.google.javascript.jscomp.LoggerErrorManager println
WARNING: target/node/dev/inferred_externs.js:5: WARNING - name goog is not defined in the externs.
goog.string.StringBuffer.prototype.append;
^^^^

The problem seems to go away when removing the "js/" below on "js/goog.string.StringBuffer.":

(core/defmacro with-out-str
  "Evaluates exprs in a context in which *print-fn* is bound to .append
  on a fresh StringBuffer.  Returns the string created by any nested
  printing calls."
  [& body]
  `(let [sb# (js/goog.string.StringBuffer.)]
     (binding [cljs.core/*print-newline* true
               cljs.core/*print-fn* (fn [x#] (.append sb# x#))]
       ~@body)
     (cljs.core/str sb#)))


 Comments   
Comment by David Nolen [ 16/Jun/18 9:06 PM ]

fixed https://github.com/clojure/clojurescript/commit/6048bc95001e1d5f1c996c5cda187cdfc0193bc8





[CLJS-2821] Update doto docstring to not use Java example Created: 14/Jul/18  Updated: 17/Jul/18  Resolved: 17/Jul/18

Status: Closed
Project: ClojureScript
Component/s: None
Affects Version/s: 1.10.238
Fix Version/s: None

Type: Enhancement Priority: Minor
Reporter: Mike Fikes Assignee: Mike Fikes
Resolution: Completed Votes: 0
Labels: docstring

Attachments: Text File CLJS-2821.patch    
Patch: Code
Approval: Accepted

 Description   

doto's docstring employs java.util.HashMap.



 Comments   
Comment by Mike Fikes [ 14/Jul/18 2:26 PM ]

This would normally just be a simple textual docstring update, but since it the docstring comes from Clojure for JVM ClojureScript, it involves defining the macro in that case in order to define its docstring.

Comment by Mike Fikes [ 17/Jul/18 1:37 PM ]

fixed https://github.com/clojure/clojurescript/commit/99efac4aa8a21d49dc2adacb442abf3561347222





[CLJS-2905] NodeJS Foreign Libs Behave Differently With Optimizations Created: 13/Sep/18  Updated: 14/Sep/18

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: 1.10.238
Fix Version/s: None

Type: Defect Priority: Minor
Reporter: Garrett Hopper Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None


 Description   

When using `:foreign-libs` in a `:target :nodejs` build, the foreign lib bundle must define variables as `this.EXAMPLE = "value"` instead of just `EXAMPLE = "value"` for `:global-exports` to work with `:optimizations :simple`. However, when `:optimizations :none` is set, the `EXAMPLE = "value"` `:global-exports` works just fine.






[CLJS-2922] Perhaps a compiler issue? Created: 26/Sep/18  Updated: 15/Oct/18  Resolved: 27/Sep/18

Status: Closed
Project: ClojureScript
Component/s: None
Affects Version/s: 1.10.238
Fix Version/s: None

Type: Defect Priority: Minor
Reporter: Luke Horton Assignee: Unassigned
Resolution: Not Reproducible Votes: 0
Labels: compiler
Environment:

Sorry, but we're not sure. We use CircleCI which is likely a linux flavor.

shadow-cljs is our build tool at 2.4.10.


Attachments: PNG File Screen Shot 2018-09-26 at 9.41.24 AM.png    

 Description   

It appears that we very occasionally get generated javascript that is invalid. Invalid here means it will compile and run, but during runtime it will throw an error because of missing variable names / null or undefined.

It's really hard / impossible to reliably recreate, and as mentioned only seems to happen once out of every few hundred builds.

The code in question:

(defn priorities-last-modified [priorities]
  (last (sort (concat
                (map :last-modified-date priorities)
                (mapcat
                  (comp (partial map :last-modified-date) :goals) priorities)))))

(Yes, this is terrible code but it works 99% of the time.)

The erring output looks like this:

jT(
    v([
      fG,
      function(a) {
        a = uh(a, new E(null, 4, 5, F, [Iu, Zk, fy, LF], null));
        a = Lf(BH, a);
        var b = yg.j(
          G.j(gs, priorities__$1),
          mh(Xg.j(Yg.j(G, gs), GA), v([priorities__$1]))
        );
        b = Jf(Gf, b);
        return new h(null, 2, [LF, a, MN, We(b)], null);
      }
    ])
  );

A recompile fixes the output and spits out this:

hT(
    v([
      eG,
      function(a) {
        var b = uh(a, new E(null, 4, 5, F, [Hu, $k, dy, KF], null));
        a = Lf(zH, b);
        b = We(Jf(Gf, yg.j(G.j(fs, b), mh(Xg.j(Yg.j(G, fs), FA), v([b])))));
        return new h(null, 2, [KF, a, NN, b], null);
      }
    ])
  );

The issue from the first compilation results in a runtime error of "priorities__$1 is not defined"

We are using



 Comments   
Comment by Luke Horton [ 26/Sep/18 2:25 PM ]

Will provide a minimum reproducible project shortly.

Comment by Mike Fikes [ 26/Sep/18 9:11 PM ]

Does your project have some other namespace that starts off with priorities.? (Such as priorities.core.)
Are you using the :parallel-build compiler option set to true?

Comment by Luke Horton [ 27/Sep/18 9:30 AM ]

Yes to both counts:
```
src/priorities/views.cljs
1:(ns priorities.views

src/priorities/goals.cljs
1:(ns priorities.goals

src/priorities/specs.cljs
1:(ns priorities.specs

src/priorities/events.cljs
1:(ns priorities.events

src/priorities/core.cljs
1:(ns priorities.core
```

https://shadow-cljs.github.io/docs/UsersGuide.html#compiler-options (parallel builds is always enabled).

Comment by Luke Horton [ 27/Sep/18 11:32 AM ]

After closer inspection I'm fairly confident the above code working/not-working are at least pointing to the same compiled fn. We use keywords "goals" and "order", which are allocated in the working file as:
```
FA = new C(null, "goals", "goals", -1712076283),
zH = new C(null, "order", "order", -1254677256),
```
and we can see that the output code makes use of both `zH` and `FA`.

Comment by David Nolen [ 27/Sep/18 11:44 AM ]

This is just not minimal enough to consider

Comment by Thomas Heller [ 15/Oct/18 3:40 PM ]

FWIW this is an actual CLJS compiler race condition.

cljs.compiler/munge decides to munge a variable if a namespace "root" starts with that variable name but it decides that based on the currently known namespaces. Due to parallel compilation a namespace might be added while still emitting one form so at the beginning it would not munge but then later on it would. This is extremely difficult to reproduce reliable due to the time window where this may happen.

(ns demo.bug)

(let [bar 1]
  (do-other-stuff)
  (do-with-bar bar))

;; elsewhere parallel compilation begins
(ns bar.app)
...

Resulting code somewhat looks like

var bar = 1;
demo.bug.do_other_stuff();
demo.bug.do_with_bar(bar__$1);

This was sort of fixed accidentally recently [1]. Since the memoize ensures that at least the same munge/unmunged name is used throughout the file. Not sure anything needs to be done but the strategy for choosing which namespaces to munge seems rather brittle considering this.

[1] https://github.com/clojure/clojurescript/commit/284872fb50cac0bd3a5d13c8e3aeaecd3481e03f#diff-55b85385d2d0bfb6dc20d59ed982d5c8R1477





[CLJS-2753] Extra out directory in path with load-file Created: 18/May/18  Updated: 15/Oct/18

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: 1.10.238
Fix Version/s: None

Type: Defect Priority: Minor
Reporter: Mike Fikes Assignee: David Nolen
Resolution: Unresolved Votes: 0
Labels: None
Environment:

{:deps {org.clojure/clojurescript {:mvn/version "1.10.238"}}}


Attachments: Text File CLJS-2753.patch    
Patch: Code

 Description   
foo.cljs
(def x 3)

Working with -d:

$ clj -m cljs.main -re node -d out -r
ClojureScript 1.10.238
cljs.user=> (load-file "foo.cljs")
nil
cljs.user=> x
3

You will end up with out/out/cljs/user/fooAD3E4B4.js

Otherwise things appear to work.



 Comments   
Comment by Herald Reierskog [ 15/Oct/18 1:38 PM ]

cljs.closure/compile-file adds :output-dir from opts to file, causing it to appear double. Passing (dissoc opts :output-dir) as third argument to cljs.closure/src-file->target-file (as is done in cljs.repl.rhino,nashorn,node,graaljs) avoids adding the first instance of output-dir to fix this bug, and fixes CLJS-2917 as well.

Comment by Mike Fikes [ 15/Oct/18 5:14 PM ]

CLJS-2753.patch LGTM and passes in CI and Canary.

I confirmed correct behavior for the ticket as written and for CLJS-2917 and I also did some light testing with other scenarios.





[CLJS-3018] Preserve type of function with metadata Created: 15/Dec/18  Updated: 15/Dec/18

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: 1.10.238, Next
Fix Version/s: None

Type: Enhancement Priority: Minor
Reporter: William Acton Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: cljs
Environment:

N/A


Attachments: Text File CLJS-3018.patch    

 Description   

Currently, IWithMeta is implemented for functions by wrapping the function in a MetaFn type.

However, this breaks certain expectations about the typeof of the meta-fied value:

(defn Foo [_] "bar")

(goog/typeOf Foo)
;; => "function"

(goog/typeOf (with-meta Foo {:bar "baz"}))
;; => "object"

The primary case when this is not ideal is when interoping with JS code that does checks using typeof, like React does:

(react-is/isValidElementType Foo)
;; => true

(react-is/isValidElementType (with-meta Foo {:bar "baz"}))
;; => false

Ideally, with-meta would preserve the typeof value when possible.



 Comments   
Comment by William Acton [ 15/Dec/18 4:10 PM ]

There's a separate issue about MetaFn's and varargs, https://dev.clojure.org/jira/browse/CLJS-2446, whose proposed implementation also solves this particular edge case.

Comment by William Acton [ 15/Dec/18 7:00 PM ]

Attached patch:

  • replaces `MetaFn` type with `meta-fn` helper that creates new fn
    with IMeta specify!'d on it.
  • Also fixes CLJS-2446: with-meta doesn't work for variable arguments functions
  • Adds tests for metadata and fns




[CLJS-2994] Errors that occour in a ClojureScript pREPL connection are :ret as data under :val, not as a string Created: 28/Nov/18  Updated: 28/Dec/18  Resolved: 28/Dec/18

Status: Closed
Project: ClojureScript
Component/s: None
Affects Version/s: 1.10.238
Fix Version/s: None

Type: Defect Priority: Minor
Reporter: Oliver Caldwell Assignee: Mike Fikes
Resolution: Completed Votes: 0
Labels: bug, cljs, prepl
Environment:

Arch Linux x86_64


Attachments: Text File CLJS-2994.patch    
Patch: Code
Approval: Accepted

 Description   

I'm working on some pREPL based tooling and noticed that if a JVM Clojure pREPL throws an error it is sent to stderr as well as a `:ret` under the `:val` keyword as a string.

When ClojureScript throws an error (in this case within nodejs) there is no stderr output and the `:val` contains actual EDN data, not a string. This inconsistency breaks the assumption that `:val` will always be a string of EDN data.

I've never raised an issue with Clojure before or submitted a patch, I am happy to do so if this is deemed a valid issue and worth fixing.



 Comments   
Comment by David Nolen [ 29/Nov/18 5:34 AM ]

I'm pretty sure the Clojure behavior is intentional - we should align.

Comment by Oliver Caldwell [ 05/Dec/18 5:22 AM ]

I'm happy to do this, should I submit the patch through here or can I fork the ClojureScript repository? I've never contributed to any core repository before. I may have to sign a CLA?

Comment by Mike Fikes [ 05/Dec/18 6:41 PM ]

Oliver, see the links under the Development section at https://clojurescript.org/community/resources. Yes a CA is required, which is covered in those links.

Comment by Oliver Caldwell [ 20/Dec/18 3:10 AM ]

So I think I understand the issue now, the errors slip through because `eval-cljs` always return a string but still throws exceptions, which we catch and return through :val: https://github.com/clojure/clojurescript/blob/6ccb629e365f46a9516e4defeced652cce9d4d35/src/main/clojure/cljs/core/server.clj#L108

I think there's two ways around this:

1. We catch as early as possible and ensure these exceptions are reported as strings. (via pr-str)
2. We catch as late as possible and upgrade the valf function to pr-str things that aren't already strings: https://github.com/clojure/clojurescript/blob/6ccb629e365f46a9516e4defeced652cce9d4d35/src/main/clojure/cljs/core/server.clj#L146

I personally think we should just pr-str (as well as Throwable->map) at the time they're caught and placed under a :val key. This is what Clojure does as well as setting :exception true on the response. Thoughts?

Comment by Oliver Caldwell [ 20/Dec/18 3:14 AM ]

https://github.com/clojure/clojure/blob/28b87d53909774af28f9f9ba6dfa2d4b94194a57/src/clj/clojure/core/server.clj#L247-L258

The above is the code I think we should align with but with an additional valf for exceptions that defaults to converting it to data and then into a string.

Comment by Oliver Caldwell [ 21/Dec/18 6:16 AM ]

This updates the default valf to pr-str if it encounters a non-string. At the moment, this will only ever be a map returned by Throwable->map.

Comment by Oliver Caldwell [ 21/Dec/18 6:16 AM ]

I've attached one way to fix this, happy to approach it another way if you don't like it!

Comment by Mike Fikes [ 27/Dec/18 11:00 AM ]

CLJS-2994.patch passes CI

Comment by David Nolen [ 27/Dec/18 9:30 PM ]

Oliver, I believe this patch allows more than the Clojure pREPL, yes? i.e. the valf customization bit?

Comment by Oliver Caldwell [ 28/Dec/18 4:39 AM ]

Not as far as I know, unless I'm misunderstanding your question. Clojure also allows you to provide valf to io-prepl which defaults to pr-str.

I've tried to align this as closely as I can, the main difference here is that ClojureScript eval already returns results as strings, so identity is okay in most cases. When our prepl returns exceptions however we now pr-str those.

Comment by David Nolen [ 28/Dec/18 12:43 PM ]

Thanks, I double checked and can confirm. Looks good to me.

Comment by Mike Fikes [ 28/Dec/18 12:47 PM ]

fixed https://github.com/clojure/clojurescript/commit/5a52244813e8351cead549de86e81b7b0032da85





[CLJS-3035] Update sort-by and sort docstrings to indicate they will be stable sorts Created: 09/Jan/19  Updated: 13/Feb/19

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: 1.10.238
Fix Version/s: None

Type: Enhancement Priority: Minor
Reporter: daniel sutton Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: docstring
Environment:

Clojurescript 1.10.439 but I was unable to select in the "Affects Version/s" list



 Description   

Clojure sort and sort-by both promise "Guaranteed to be stable: equal elements will not be reordered."

The current implementations of `sort` and `sort-by` in ClojureScript are from

9ee4dbf63d3968b70f29708aa03aace98cdcb624
Author:     Stuart Halloway <stu@thinkrelevance.com>
AuthorDate: Thu Jul 14 12:18:34 2011 -0500
core.cljs
(defn sort
  "Returns a sorted sequence of the items in coll. Comp can be
   boolean-valued comparison function, or a -/0/+ valued comparator.
   Comp defaults to compare."
  ([coll]
   (sort compare coll))
  ([comp coll]
   (if (seq coll)
     (let [a (to-array coll)]
       ;; matching Clojure's stable sort, though docs don't promise it
       (garray/stableSort a (fn->comparator comp))
       (seq a))
     ())))

(defn sort-by
  "Returns a sorted sequence of the items in coll, where the sort
   order is determined by comparing (keyfn item).  Comp can be
   boolean-valued comparison function, or a -/0/+ valued comparator.
   Comp defaults to compare."
  ([keyfn coll]
   (sort-by keyfn compare coll))
  ([keyfn comp coll]
     (sort (fn [x y] ((fn->comparator comp) (keyfn x) (keyfn y))) coll)))

Since this implementation has apparently called google's stableSort for the last 8 years perhaps the docstring could be amended to reflect this.

For reference, the google closure array documentation: https://google.github.io/closure-library/api/goog.array.html:

Note that stableSort's docstring actually doesn't mention stability but the sort function contains "This sort is not guaranteed to be stable."



 Comments   
Comment by Sean Corfield [ 09/Jan/19 12:48 PM ]

(from a discussion on Slack, I offered this opinion which someone suggested I should add to this ticket)

I think it would be good to explicitly state either:

Guaranteed to be stable: equal elements will not be reordered.

or:

Not guaranteed to be stable.

That way developers will *know* that either they can depend on stability or they should not depend on it (even tho' the current implementation happens to be stable).

Comment by Phill Wolf [ 09/Jan/19 5:43 PM ]

Clojure's sort docstring says, "Guaranteed to be stable: equal elements will not be reordered." Earlier, it had been stable but not documented as such. See https://dev.clojure.org/jira/browse/CLJ-1414

I hope CLJS will (a) be stable in the same way and (b) match Clojure's documentation of stability.

Comment by saurabh [ 31/Jan/19 4:55 AM ]

I would like to to work on this issue, if it is still open

Comment by David Nolen [ 13/Feb/19 10:29 AM ]

Go for it, have you submitted your CA?





[CLJS-3057] Changes in macro namespaces should propagate to dependent namespaces during recompile Created: 28/Feb/19  Updated: 28/Feb/19

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: 1.10.238
Fix Version/s: None

Type: Defect Priority: Minor
Reporter: Matt Huebert Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None


 Description   

Re-compiling a ClojureScript project in which macros have been changed, does not recompile namespaces that consume those macros - cached versions are used instead.

Reproduction:
1. compile a project, eg. `clj -m cljs.main --optimizations advanced -c app.core`
2. make a change to a macro that `app.core` depends on, say `app.macros`
3. re-run the same compile,
`app.core` does not pick up the changes in `app.macros` - instead one must delete the `out` dir or make a changes to `app.core` in order for it to correctly re-compile.






[CLJS-3056] runtime namespace load order is independent from ordering in ns macro :require form Created: 24/Feb/19  Updated: 03/Apr/19

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: 1.9.908, 1.10.238
Fix Version/s: None

Type: Defect Priority: Minor
Reporter: Chance Russell Assignee: Unassigned
Resolution: Unresolved Votes: 1
Labels: compiler

Attachments: File a.cljs     File b.cljs     File c.cljs     Text File CLJS-3056.patch     File d.cljs     File deps.edn     File e.cljs     File f.cljs     File g.cljs    
Patch: Code

 Description   

The order that namespaces are loaded at runtime is independent of the order that the namespaces are {{require}}d in user code. This seems to affect all optimization levels. This means that developers can't rely on side-effectful code in a given namespace to be run before another namespace that depends on the side effect is loaded.

Reproduction steps:

Running the command

clj --main cljs.main --compile-opts '{:target :nodejs :main a}' --compile a

will compile the a namespace defined in a.cljs. That namespace requires—via the :require form of the ns macro—namespaces b through g in alphabetical order.

After compiling, observe the following:

  • The goog.addDependency call for a.js in the output out/cljs_deps.js file includes its dependencies in an arbitrary order. For example, one run on my machine resulted in:
goog.addDependency("../a.js", ['a'], ['cljs.core', 'e', 'c', 'g', 'b', 'd', 'f']);
  • The console output given by running the compiled code with node out/main.js indicates that the runtime load order is identical to the ordering reflected in out/cljs_deps.js
body of e

body of c

body of g

body of b 

body of d

body of f

Analysis:

It looks like some work to ensure the ordering at compile time was done as part of CLJS-1453(https://dev.clojure.org/jira/browse/CLJS-1453), but it seems that things can get out of order by the time cljs_deps.js is emitted.

It seems that the output in cljs_deps.js for a given ClojureScript file is ultimately determined by the output of cljs.compiler/emit-source. The code there removes duplicate deps in the same way that the 'ns parse method in cljs.analyzer did prior to CLJS-1453.

The attached patch resolves the issue for my narrow use case, but I believe the underlying functions are passing the `:uses` and `:requires` around as maps, so more work may be needed for a full solution.



 Comments   
Comment by Chance Russell [ 24/Feb/19 10:58 PM ]

Apologies for cluttering up the ticket with markdown—thought I would be able to clean it up after submission.

Comment by Mike Fikes [ 03/Mar/19 10:58 AM ]

CLJS-3056.patch passes CI and Canary

Comment by Thomas Heller [ 03/Mar/19 4:08 PM ]

The attached patch still uses the deps map which will only maintain insertion order until the array-map threshold is hit and once it starts using a hash-map things will be not be ordered again. In shadow-cljs I handle this by maintaining an addition :deps vector in addition to the usual :requires map.

Comment by Chance Russell [ 03/Mar/19 4:35 PM ]

That’s probably the best solution—I didn’t want to attempt to modify the type of the maps in the existing code.

I’ll take a look at this this evening—it seems like the patch for CLJS-1453 may have the same problem.

That said, I wonder what the semantics for ordering should be when an ns form contains both :require and :use?

Comment by Thomas Heller [ 03/Mar/19 4:43 PM ]

Ah looks like a :deps vector is already maintained in the analyzer parse 'ns and 'ns*. Just need to use that in the cljs.compiler/emit-source fn instead taking the vals of the requires/uses maps.

Comment by Chance Russell [ 24/Mar/19 12:04 PM ]

Thomas was right, the :deps vector is present and in the expected order, so I've submitted a new patch that uses that.

One question—what should the ordering of cljs.core and cljs.core.constants be when both are present? Obviously the ordering wasn't guaranteed with the previous code, but I'd like to get that right.

(The test in test-cljs-1882-constants-table-is-sorted would seem to imply that cljs.core should go first.)

Comment by Mike Fikes [ 24/Mar/19 12:48 PM ]

CLJS-3056.patch of 24/Mar/19 12:58 PM passes CI and Canary

Comment by David Nolen [ 29/Mar/19 10:09 AM ]

cljs.core must come before cljs.core.constants as `cljs.core.contants` won't work without the keyword construct being defined. The ordering was most definitely guaranteed otherwise we would have heard a lot of complaints about failing advanced builds.

Comment by Chance Russell [ 03/Apr/19 11:10 PM ]

David, when you say "ordering was most definitely guaranteed", are you referring to just cljs.core and cljs.core.constants, or the dependencies as a whole? The current code is {{conj}}ing onto sets, which isn't guaranteed to maintain any ordering AFAIK.





[CLJS-2394] npm modules not inserted into cljs_deps when compiler is restarted Created: 02/Nov/17  Updated: 17/Nov/17  Resolved: 17/Nov/17

Status: Closed
Project: ClojureScript
Component/s: None
Affects Version/s: 1.10.238
Fix Version/s: None

Type: Defect Priority: Major
Reporter: Hendrik Poernama Assignee: Unassigned
Resolution: Completed Votes: 0
Labels: None

Attachments: Text File CLJS-2394-patch-1.patch    

 Description   

When restarted, compiler would rewrite cljs_deps and remove all npm modules dependency. Problem only appears when rebuilding, not from clean compilation.

Workaround: Do a clean build every time compiler has to be restarted.

Minimal example: https://github.com/poernahi/cljsbuild_wrongdeps

Steps to reproduce using above example:
1. Copy/symlink clojurescript uberjar into project root as cljs.jar
2. make clean && make && wc -l out/cljs_deps.js # Should return 186 lines
3. touch src/cljsbuild_wrongdeps/core.cljs && make && wc -l out/cljs_deps.js # Now returns only 4 lines!!

I think this is related to CLJS-2339. I narrowed down to this line
https://github.com/clojure/clojurescript/commit/245bdee2c35e19a9685b7a0849f26fce8bdaf7ca#diff-84ffd22349e5ca1fe6322cb0e379b3b1R2250

When a new compiler instance is run, the cache in ::transitive-dep-set is empty and index-node-modules return nil.



 Comments   
Comment by Hendrik Poernama [ 02/Nov/17 6:49 AM ]

Fix attempt

Comment by David Nolen [ 17/Nov/17 3:17 PM ]

fixed https://github.com/clojure/clojurescript/commit/2389e52049a9bd001d173a1cb4772ed8a25de196





[CLJS-2544] No such namespace: pg Created: 22/Feb/18  Updated: 23/Feb/18  Resolved: 23/Feb/18

Status: Closed
Project: ClojureScript
Component/s: None
Affects Version/s: 1.10.238
Fix Version/s: None

Type: Defect Priority: Major
Reporter: Andrea Richiardi Assignee: Unassigned
Resolution: Completed Votes: 0
Labels: None


 Description   

I have a problem with a simple require

(ns repro.pg-ns
  (:require pg))

Repro is here: https://github.com/arichiardi/cljs-pg-error

The error is the classic Caused by: clojure.lang.ExceptionInfo: No such namespace: pg, could not locate pg.cljs, pg.cljc, or JavaScript source providing "pg" in file src/repro/pg_ns.cljs

and my compiler options look like:

{:main 'repro.pg-ns
 :output-to "out/pg-ns.js"
 :output-dir "out"
 :optimizations :none
 :source-map true
 :source-map-timestamp false
 :target :nodejs
 :install-deps true
 :npm-deps {:pg "7.4.1"}}


 Comments   
Comment by Corin Lawson [ 23/Feb/18 6:16 AM ]

I note that pg's entrypoint is ./lib (see its package.json, line 20). Setting that to be ./lib/index.js is a workaround to the problem.

Comment by Andrea Richiardi [ 23/Feb/18 11:38 AM ]

That was the problem!

Thanks a lot and sorry for the noise. I also PR-ed the repo. It seems like lumo uses more forgiving facilities compared to what CLJS is using now. I saw that the Google Closure Compiler has a couple of modes about dependency management...anyways. Again a big thank you!

Comment by Andrea Richiardi [ 23/Feb/18 5:52 PM ]

Nah, so the maintainer did not like the patch and replied:

./lib is a module by virtue of containing an index.js; you should report a bug with the failing tools.

Meaning more digging is needed.





[CLJS-2621] Excluding MapEntry breaks defrecord Created: 06/Mar/18  Updated: 06/Mar/18  Resolved: 06/Mar/18

Status: Closed
Project: ClojureScript
Component/s: None
Affects Version/s: 1.10.238
Fix Version/s: None

Type: Defect Priority: Major
Reporter: Miikka Koskinen Assignee: Unassigned
Resolution: Completed Votes: 1
Labels: None
Environment:

ClojureScript 1.10.126


Attachments: Text File CLJS-2621.patch    

 Description   

I encountered this problem when trying the pre-release 1.10.126 against a production codebase.

If you do `(:refer-clojure :exclude [MapEntry])` in your namespace declaration and define a record, the record's `seq` implementation is broken. Consider the following code:

(ns cljs.defrecord-test
  (:refer-clojure :exclude [MapEntry])
  (:require [cljs.test :refer-macros [deftest is]]))

(defrecord Foo [a])

(deftest foo-test
  (= '([:a "test"]) (seq (Foo. "test"))))

You'll get the following compiler warnings:

WARNING: Use of undeclared Var cljs.defrecord-test/MapEntry at line 5 /Users/miikka/code/clojurescript/src/test/cljs/cljs/defrecord_test.cljs
WARNING: Use of undeclared Var cljs.defrecord-test/MapEntry at line 5 /Users/miikka/code/clojurescript/src/test/cljs/cljs/defrecord_test.cljs

The test fails:

Testing cljs.defrecord-test

ERROR in (foo-test) (TypeError:NaN:NaN)
Uncaught exception, not in assertion.
expected: nil
  actual: #object[TypeError TypeError: kRa.Rh is not a constructor]

If you run the same test without the exclusion, the test passes as expected. In practice this bug prevents the prismatic/schema library from working with the upcoming ClojureScript release.



 Comments   
Comment by Miikka Koskinen [ 06/Mar/18 11:52 AM ]

Here's a suggested fix and a test. I've also verified that it fixes the prismatic/schema problem in practice.

Comment by David Nolen [ 06/Mar/18 12:05 PM ]

fixed https://github.com/clojure/clojurescript/commit/ed385ad484f9c6b2471b0ee371fac805d8194c3e





[CLJS-2592] :npm-deps using ES6 modules with .mjs extensions are not detected correctly Created: 02/Mar/18  Updated: 10/Mar/18  Resolved: 10/Mar/18

Status: Closed
Project: ClojureScript
Component/s: None
Affects Version/s: 1.10.238
Fix Version/s: None

Type: Defect Priority: Major
Reporter: Jannis Pohlmann Assignee: Unassigned
Resolution: Completed Votes: 0
Labels: None
Environment:

Tested with both ClojureScript 1.10.64 and ClojureScript master (4375a63)


Attachments: Text File CLJS-2592.3.patch     Text File CLJS-2592.4.patch     Text File CLJS-2592.patch     Text File CLJS-2592.patch    

 Description   

Several modern JS libraries have adopted the .mjs extension for ES6 modules. Two examples of such libraries are https://github.com/leebyron/iterall/ and https://github.com/graphql/graphql-js/.

Indexing packages that use this file extension (e.g. for their index.mjs) and adding them to the compiler environment is currently broken. As a result, these packages will not be resolvable at runtime, leading to errors such as this:

base.js:1357 Uncaught Error: Undefined nameToPath for iterall
    at visitNode (base.js:1357)
    at Object.goog.writeScripts_ (base.js:1369)
    at Object.goog.require (base.js:706)
    at index.html:7

I've created a minimal repository to reproduce the issue here: https://github.com/Jannis/cljs-npm-deps-mjs-issue.

I'll attach a patch with a fix and two tests (one to verify indexing, one to verify building) shortly.



 Comments   
Comment by Jannis Pohlmann [ 02/Mar/18 7:41 AM ]

I realise this is probably not specific to {:npm-deps} at all and would affect any way in which foreign libs are defined?

Comment by Jannis Pohlmann [ 02/Mar/18 8:40 AM ]

Patch that fixes the issue and adds two tests (to verify indexing and to verify build output).

I can confirm that the repo to reproduce the issue works fine when using a local build of ClojureScript after applying the patch.

Comment by Jannis Pohlmann [ 02/Mar/18 8:47 AM ]

Updated patch with tests renamed to mention this JIRA issue.

Comment by Jannis Pohlmann [ 02/Mar/18 9:34 AM ]

Another update: as much as I'd like to see this fixed, the provided patch only works with simple JS packages like iterall. It doesn't work with e.g. graphql yet, which has many .mjs files that reference each other, and also has .js files parallel to that.

Comment by Jannis Pohlmann [ 09/Mar/18 12:14 PM ]

Updated patch that adds an optional :package-json-resolution flag (supported values: :webpack, :nodejs, ["foo", "bar", ...].

Comment by Jannis Pohlmann [ 10/Mar/18 5:33 AM ]

Revised version of the previous patch that doesn't introduce a :browser target.

Comment by David Nolen [ 10/Mar/18 9:08 AM ]

fixed https://github.com/clojure/clojurescript/commit/233b42338c182e72391466eba2d00bae34271e58





[CLJS-2742] lein-doo fails with Clojurescript 1.10.238 (AOT version) Created: 22/Apr/18  Updated: 23/Apr/18  Resolved: 23/Apr/18

Status: Closed
Project: ClojureScript
Component/s: None
Affects Version/s: 1.10.238
Fix Version/s: None

Type: Defect Priority: Major
Reporter: Joel Sánchez López Assignee: Unassigned
Resolution: Not Reproducible Votes: 0
Labels: None


 Description   

Running this command: `lein doo chrome-headless test once`
Results in:

```
Exception in thread "main" java.lang.NoSuchMethodError: cljs.js_deps.IJavaScript._url(Ljava/lang/Object;)Ljava/lang/Object;, compiling/tmp/form-init7914580949796230591.clj:1:73)
at clojure.lang.Compiler.load(Compiler.java:7526)
at clojure.lang.Compiler.loadFile(Compiler.java:7452)
at clojure.main$load_script.invokeStatic(main.clj:278)
at clojure.main$init_opt.invokeStatic(main.clj:280)
at clojure.main$init_opt.invoke(main.clj:280)
at clojure.main$initialize.invokeStatic(main.clj:311)
at clojure.main$null_opt.invokeStatic(main.clj:345)
at clojure.main$null_opt.invoke(main.clj:342)
at clojure.main$main.invokeStatic(main.clj:424)
at clojure.main$main.doInvoke(main.clj:387)
at clojure.lang.RestFn.applyTo(RestFn.java:137)
at clojure.lang.Var.applyTo(Var.java:702)
at clojure.main.main(main.java:37)
Caused by: java.lang.NoSuchMethodError: cljs.js_deps.IJavaScript._url(Ljava/lang/Object;)Ljava/lang/Object;
at cljs.closure$rel_output_path.invokeStatic(closure.clj:1706)
at cljs.closure$rel_output_path.invoke(closure.clj:1698)
at cljs.closure$write_javascript.invokeStatic(closure.clj:1856)
at cljs.closure$write_javascript.invoke(closure.clj:1850)
at cljs.closure$source_on_disk.invokeStatic(closure.clj:1899)
at cljs.closure$source_on_disk.invoke(closure.clj:1894)
at cljs.closure$build$fn__5906.invoke(closure.clj:2825)
at clojure.core$map$fn__5587.invoke(core.clj:2747)
at clojure.lang.LazySeq.sval(LazySeq.java:40)
at clojure.lang.LazySeq.seq(LazySeq.java:49)
at clojure.lang.RT.seq(RT.java:528)
at clojure.core$seq__5124.invokeStatic(core.clj:137)
at clojure.core$dorun.invokeStatic(core.clj:3125)
at clojure.core$doall.invokeStatic(core.clj:3140)
at clojure.core$doall.invoke(core.clj:3140)
at cljs.closure$build.invokeStatic(closure.clj:2825)
at cljs.closure$build.invoke(closure.clj:2718)
at cljs.build.api$build.invokeStatic(api.clj:208)
at cljs.build.api$build.invoke(api.clj:189)
at cljs.build.api$build.invokeStatic(api.clj:195)
at cljs.build.api$build.invoke(api.clj:189)
at user$eval27281.invokeStatic(form-init7914580949796230591.clj:1)
at user$eval27281.invoke(form-init7914580949796230591.clj:1)
at clojure.lang.Compiler.eval(Compiler.java:7062)
at clojure.lang.Compiler.eval(Compiler.java:7052)
at clojure.lang.Compiler.load(Compiler.java:7514)
... 12 more
Subprocess failed
```

See https://github.com/JoelSanchez/cljs-aot-doo-repro



 Comments   
Comment by Joel Sánchez López [ 22/Apr/18 3:03 PM ]

Second repro, with cljsbuild (no doo involved):
https://github.com/JoelSanchez/cljs-aot-cljsbuild-repro

Comment by Joel Sánchez López [ 22/Apr/18 4:44 PM ]

Turns out I was depending on 'tubular', which in turn was depending on 'clojure.core.typed'. A new 'tubular' release fixed the issue.
Please someone close this...I can't.





[CLJS-2622] Add support for package tarballs in :npm-deps Created: 06/Mar/18  Updated: 30/Apr/18

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: 1.10.238
Fix Version/s: None

Type: Enhancement Priority: Major
Reporter: Jannis Pohlmann Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: npm-deps

Attachments: Text File CLJS-2622.patch    

 Description   

NPM supports installing packages from tarballs via {npm install /path/to/foo.tgz}. This can be useful for trying a local (modified) version of a package, or generally any unpublished and/or private JS project; all that's needed is a {package.json} and a {.js} file and {npm pack} can generate a tarball.

It would be nice if ClojureScript would support this as well, through {:npm-deps}.

Proposed syntax:

{:npm-deps {"/path/to/tarball.tgz" "0.1.0"
            "/path/to/bar.tgz" ""}}

The version isn't needed with tarballs, so it could be anything.

I have the code for this working but I still want to add a test before I submit a patch.



 Comments   
Comment by Jannis Pohlmann [ 07/Mar/18 7:18 AM ]

This patch implements the feature and adds tests for indexing and building with a tarball dependency.

Comment by Thomas Heller [ 30/Apr/18 2:53 PM ]

What benefit does this provide over just running npm install ./some.tgz?

I don't think this is a good idea.





[CLJS-2739] Optimize node_modules indexing Created: 17/Apr/18  Updated: 07/May/18  Resolved: 07/May/18

Status: Closed
Project: ClojureScript
Component/s: None
Affects Version/s: 1.10.238
Fix Version/s: None

Type: Enhancement Priority: Major
Reporter: Mike Fikes Assignee: David Nolen
Resolution: Completed Votes: 5
Labels: npm-deps

Attachments: Text File CLJS-2739.patch    
Patch: Code

 Description   

Indexing node_modules can take quite a while. As an example, with the node_modules directory that is set up for React Native projects, on a 2012 Mac Pro, this can take about 45 seconds. This is long enough where, if node_modules isn't actually being used for ClojureScript, using :npm-deps false is highly motivated.

If there was a way to make this closer to instantaneous (perhaps via caching or other clever approaches), then this would benefit all users.



 Comments   
Comment by Juho Teperi [ 17/Apr/18 10:38 AM ]

Based on Mike's test this is mostly caused by index-node-modules-dir, which reads the node modules dir tree using JVM: https://gist.github.com/mfikes/c99cfac7b9f5ae48fc9644bbde492a3c

Comment by Mike Fikes [ 06/May/18 5:06 PM ]

For one of my projects the attached patch drops the time spent in index-node-modules-dir from 30 seconds to 5 seconds.

Comment by David Nolen [ 07/May/18 3:29 PM ]

fixed https://github.com/clojure/clojurescript/commit/e577d46c1e9fc5ecea8e727f6f6c31cc8e5a6652





[CLJS-2724] Native Node modules Node (like "fs") cannot be required Created: 05/Apr/18  Updated: 07/May/18  Resolved: 07/May/18

Status: Closed
Project: ClojureScript
Component/s: None
Affects Version/s: 1.10.238
Fix Version/s: None

Type: Defect Priority: Major
Reporter: David Nolen Assignee: David Nolen
Resolution: Completed Votes: 13
Labels: None

Attachments: Text File CLJS-2724.patch    
Patch: Code and Test

 Description   

test.cljs

(require 'fs)
(println (fs/readFileSync "README.md" "utf8"))

command:

clj -A:cljs test.cljs


 Comments   
Comment by Mike Fikes [ 08/Apr/18 5:19 PM ]

I can reproduce this only when running a file, but not when in the REPL.

deps.edn
{:deps {org.clojure/clojurescript {:mvn/version "1.10.238"}}}
test.cljs
(require 'fs)
(println (fs/readFileSync "deps.edn" "utf8"))

REPL

$ clj -Srepro -m cljs.main -re node
ClojureScript 1.10.238
cljs.user=> (require 'fs)
nil
cljs.user=> (println (fs/readFileSync "deps.edn" "utf8"))
{:deps {org.clojure/clojurescript {:mvn/version "1.10.238"}}}

nil
cljs.user=>

Run Directly

$ clj -Srepro -m cljs.main -re node test.cljs
Exception in thread "main" clojure.lang.ExceptionInfo: No such namespace: fs, could not locate fs.cljs, fs.cljc, or JavaScript source providing "fs" at line 1 test.cljs {:file "test.cljs", :line 1, :column 1, :root-source-info {:source-type :fragment, :source-form (require (quote fs))}, :tag :cljs/analysis-error}
	at clojure.core$ex_info.invokeStatic(core.clj:4739)
	at clojure.core$ex_info.invoke(core.clj:4739)
	at cljs.analyzer$error.invokeStatic(analyzer.cljc:697)
	at cljs.analyzer$error.invoke(analyzer.cljc:693)
	at cljs.analyzer$error.invokeStatic(analyzer.cljc:695)
	at cljs.analyzer$error.invoke(analyzer.cljc:693)
	at cljs.analyzer$analyze_deps.invokeStatic(analyzer.cljc:2129)
	at cljs.analyzer$analyze_deps.invoke(analyzer.cljc:2103)
	at cljs.analyzer$ns_side_effects.invokeStatic(analyzer.cljc:3476)
	at cljs.analyzer$ns_side_effects.invoke(analyzer.cljc:3471)
	at cljs.analyzer$analyze_STAR_$fn__2510.invoke(analyzer.cljc:3596)
	at clojure.lang.PersistentVector.reduce(PersistentVector.java:341)
	at clojure.core$reduce.invokeStatic(core.clj:6747)
	at clojure.core$reduce.invoke(core.clj:6730)
	at cljs.analyzer$analyze_STAR_.invokeStatic(analyzer.cljc:3596)
	at cljs.analyzer$analyze_STAR_.invoke(analyzer.cljc:3586)
	at cljs.analyzer$analyze.invokeStatic(analyzer.cljc:3616)
	at cljs.analyzer$analyze.invoke(analyzer.cljc:3598)
	at cljs.analyzer$analyze_seq.invokeStatic(analyzer.cljc:3378)
	at cljs.analyzer$analyze_seq.invoke(analyzer.cljc:3355)
	at cljs.analyzer$analyze_form.invokeStatic(analyzer.cljc:3545)
	at cljs.analyzer$analyze_form.invoke(analyzer.cljc:3541)
	at cljs.analyzer$analyze_STAR_.invokeStatic(analyzer.cljc:3595)
	at cljs.analyzer$analyze_STAR_.invoke(analyzer.cljc:3586)
	at cljs.analyzer$analyze.invokeStatic(analyzer.cljc:3616)
	at cljs.analyzer$analyze.invoke(analyzer.cljc:3598)
	at cljs.repl$evaluate_form$fn__6365.invoke(repl.cljc:543)
	at cljs.repl$evaluate_form.invokeStatic(repl.cljc:542)
	at cljs.repl$evaluate_form.invoke(repl.cljc:484)
	at cljs.repl$evaluate_form.invokeStatic(repl.cljc:491)
	at cljs.repl$evaluate_form.invoke(repl.cljc:484)
	at cljs.repl$evaluate_form.invokeStatic(repl.cljc:489)
	at cljs.repl$evaluate_form.invoke(repl.cljc:484)
	at cljs.repl$load_stream.invokeStatic(repl.cljc:575)
	at cljs.repl$load_stream.invoke(repl.cljc:570)
	at cljs.cli$default_main$fn__6799$fn__6800.invoke(cli.clj:348)
	at cljs.cli$default_main$fn__6799.invoke(cli.clj:347)
	at cljs.compiler$with_core_cljs.invokeStatic(compiler.cljc:1285)
	at cljs.compiler$with_core_cljs.invoke(compiler.cljc:1274)
	at cljs.compiler.api$with_core_cljs.invokeStatic(api.clj:50)
	at cljs.compiler.api$with_core_cljs.invoke(api.clj:34)
	at cljs.compiler.api$with_core_cljs.invokeStatic(api.clj:42)
	at cljs.compiler.api$with_core_cljs.invoke(api.clj:34)
	at cljs.cli$default_main.invokeStatic(cli.clj:326)
	at cljs.cli$default_main.invoke(cli.clj:299)
	at cljs.cli$script_opt.invokeStatic(cli.clj:403)
	at cljs.cli$script_opt.invoke(cli.clj:401)
	at cljs.cli$main.invokeStatic(cli.clj:612)
	at cljs.cli$main.doInvoke(cli.clj:601)
	at clojure.lang.RestFn.applyTo(RestFn.java:139)
	at clojure.core$apply.invokeStatic(core.clj:659)
	at clojure.core$apply.invoke(core.clj:652)
	at cljs.main$_main.invokeStatic(main.clj:61)
	at cljs.main$_main.doInvoke(main.clj:52)
	at clojure.lang.RestFn.applyTo(RestFn.java:137)
	at clojure.lang.Var.applyTo(Var.java:702)
	at clojure.core$apply.invokeStatic(core.clj:657)
	at clojure.main$main_opt.invokeStatic(main.clj:317)
	at clojure.main$main_opt.invoke(main.clj:313)
	at clojure.main$main.invokeStatic(main.clj:424)
	at clojure.main$main.doInvoke(main.clj:387)
	at clojure.lang.RestFn.applyTo(RestFn.java:137)
	at clojure.lang.Var.applyTo(Var.java:702)
	at clojure.main.main(main.java:37)
Comment by Mike Fikes [ 05/May/18 6:42 PM ]

The root cause is that in the code path when cljs.main executes a script, it uses the ensure macro, which ends up establishing a compiler environment that isn't set up for Node—set up using (cljs.env/default-compiler-env). If an opts map is passed to cljs.env/default-compiler-env which contains :target :nodejs entry, then the desired native Node modules, in cljs.js-deps/native-node-modules will be included.

The fix is to instead of using ensure, either use with-compiler-env or to just bind *compiler* to one set up using the right opts. The attached patch looks much larger than it really is, owing to a lot of whitespace change produced by removing an outermost ensure wrapper. It removes the ensure and simply adds env/*compiler* (env/default-compiler-env opts) to the binding list.

I checked that the patch also works in the case of using cljs.main to compile code using 'fs. A CLI test is added ensuring that you can use native modules in -e forms, which is roughly analogous to what happens when running a script. (I also checked tat this new CLI test fails if you don't include the production code change.)

Comment by David Nolen [ 07/May/18 3:47 PM ]

fixed https://github.com/clojure/clojurescript/commit/78753d376d5bfe9afd1dbb98eea15fd5bd312255





[CLJS-2737] No such file when using fs from ns form Created: 13/Apr/18  Updated: 12/May/18  Resolved: 12/May/18

Status: Closed
Project: ClojureScript
Component/s: None
Affects Version/s: 1.10.238
Fix Version/s: None

Type: Defect Priority: Major
Reporter: Andrea Richiardi Assignee: Unassigned
Resolution: Not Reproducible Votes: 0
Labels: None


 Description   

With a file like this:

(ns cli-repro.core
  (:require fs))

(enable-console-print!)

(println "ls .:\n" (fs/lstatSync "."))

And a cljsc.edn file like:

{:main cli-repro.core
 :verbose true
 :optimizations :simple
 :target :nodejs}

This fails:

clojure -m "cljs.main" -v -co "cljsc.edn" -c cli-repro.core

With:

Caused by: clojure.lang.ExceptionInfo: No such namespace: fs, could not locate fs.cljs, fs.cljc, or JavaScript source providing "fs" in file /home/arichiardi/tmp/cli-repros/src/cli_repro/core.cljs {:tag :cljs/analysis-error}
	at clojure.core$ex_info.invokeStatic(core.clj:4754)
	at clojure.core$ex_info.invoke(core.clj:4754)
	at cljs.analyzer$error.invokeStatic(analyzer.cljc:697)
	at cljs.analyzer$error.invoke(analyzer.cljc:693)
	at cljs.analyzer$error.invokeStatic(analyzer.cljc:695)
	at cljs.analyzer$error.invoke(analyzer.cljc:693)
	at cljs.analyzer$analyze_deps.invokeStatic(analyzer.cljc:2129)
	at cljs.analyzer$analyze_deps.invoke(analyzer.cljc:2103)
	at cljs.analyzer$ns_side_effects.invokeStatic(analyzer.cljc:3476)
	at cljs.analyzer$ns_side_effects.invoke(analyzer.cljc:3471)
	at cljs.analyzer$analyze_STAR_$fn__2510.invoke(analyzer.cljc:3596)
	at clojure.lang.PersistentVector.reduce(PersistentVector.java:341)
	at clojure.core$reduce.invokeStatic(core.clj:6762)
	at clojure.core$reduce.invoke(core.clj:6745)
	at cljs.analyzer$analyze_STAR_.invokeStatic(analyzer.cljc:3596)
	at cljs.analyzer$analyze_STAR_.invoke(analyzer.cljc:3586)
	at cljs.analyzer$analyze.invokeStatic(analyzer.cljc:3616)
	at cljs.analyzer$analyze.invoke(analyzer.cljc:3598)
	at cljs.compiler$emit_source.invokeStatic(compiler.cljc:1386)
	at cljs.compiler$emit_source.invoke(compiler.cljc:1365)
	at cljs.compiler$compile_file_STAR_$fn__3672.invoke(compiler.cljc:1467)
	at cljs.compiler$with_core_cljs.invokeStatic(compiler.cljc:1285)
	at cljs.compiler$with_core_cljs.invoke(compiler.cljc:1274)
	at cljs.compiler$compile_file_STAR_.invokeStatic(compiler.cljc:1451)
	at cljs.compiler$compile_file_STAR_.invoke(compiler.cljc:1444)
	at cljs.compiler$compile_file$fn__3702.invoke(compiler.cljc:1547)
	... 43 more

Note that it works with js/require.



 Comments   
Comment by Thomas Heller [ 14/Apr/18 3:04 AM ]

Probably duplicate: https://dev.clojure.org/jira/browse/CLJS-2724

Comment by Andrea Richiardi [ 17/Apr/18 11:38 AM ]

Data point: Juho reported on Slack that it is working for him with `lein`.

Comment by Mike Fikes [ 12/May/18 8:14 AM ]

No longer reproducible on master.





[CLJS-2752] load-file fails if no output dir specified Created: 18/May/18  Updated: 18/May/18

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: 1.10.238
Fix Version/s: None

Type: Defect Priority: Major
Reporter: Mike Fikes Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Environment:

{:deps {org.clojure/clojurescript {:mvn/version "1.10.238"}}}



 Description   
foo.cljs
(def x 3)

Working with -d:

$ clj -m cljs.main -re node -d out -r
ClojureScript 1.10.238
cljs.user=> (load-file "foo.cljs")
nil
cljs.user=> x
3

Failing without:

$ clj -m cljs.main -re node -r
ClojureScript 1.10.238
cljs.user=> (load-file "foo.cljs")
java.lang.IllegalArgumentException: /var/folders/gx/nymj3l7x4zq3gxb97v2zwzb40000gn/T/out7651413336278138652227528048732117/cljs/user/fooAD3E4B4.js is not a relative path
	at clojure.java.io$as_relative_path.invokeStatic(io.clj:414)
	at clojure.java.io$file.invokeStatic(io.clj:426)
	at clojure.java.io$file.invoke(io.clj:418)
	at cljs.closure$compile_file.invokeStatic(closure.clj:572)
	at cljs.closure$compile_file.invoke(closure.clj:564)
	at cljs.closure$fn__5124.invokeStatic(closure.clj:653)
	at cljs.closure$fn__5124.invoke(closure.clj:647)
	at cljs.closure$fn__5052$G__5045__5059.invoke(closure.clj:521)
	at cljs.closure$compile.invokeStatic(closure.clj:557)
	at cljs.closure$compile.invoke(closure.clj:554)
	at cljs.repl$load_file$fn__6378.invoke(repl.cljc:586)
	at cljs.repl$load_file.invokeStatic(repl.cljc:585)
	at cljs.repl$load_file.invoke(repl.cljc:577)
	at cljs.repl$fn__6429$self__6431.invoke(repl.cljc:740)
	at clojure.lang.AFn.applyToHelper(AFn.java:165)
	at clojure.lang.AFn.applyTo(AFn.java:144)
	at clojure.core$apply.invokeStatic(core.clj:657)
	at clojure.core$apply.invoke(core.clj:652)
	at cljs.repl$wrap_self$g__6408.invoke(repl.cljc:724)
	at cljs.repl$repl_STAR_$read_eval_print__6536.invoke(repl.cljc:955)
	at cljs.repl$repl_STAR_$fn__6542$fn__6551.invoke(repl.cljc:998)
	at cljs.repl$repl_STAR_$fn__6542.invoke(repl.cljc:997)
	at cljs.compiler$with_core_cljs.invokeStatic(compiler.cljc:1285)
	at cljs.compiler$with_core_cljs.invoke(compiler.cljc:1274)
	at cljs.repl$repl_STAR_.invokeStatic(repl.cljc:960)
	at cljs.repl$repl_STAR_.invoke(repl.cljc:839)
	at cljs.cli$repl_opt.invokeStatic(cli.clj:290)
	at cljs.cli$repl_opt.invoke(cli.clj:277)
	at cljs.cli$main.invokeStatic(cli.clj:612)
	at cljs.cli$main.doInvoke(cli.clj:601)
	at clojure.lang.RestFn.applyTo(RestFn.java:139)
	at clojure.core$apply.invokeStatic(core.clj:659)
	at clojure.core$apply.invoke(core.clj:652)
	at cljs.main$_main.invokeStatic(main.clj:61)
	at cljs.main$_main.doInvoke(main.clj:52)
	at clojure.lang.RestFn.applyTo(RestFn.java:137)
	at clojure.lang.Var.applyTo(Var.java:702)
	at clojure.core$apply.invokeStatic(core.clj:657)
	at clojure.main$main_opt.invokeStatic(main.clj:317)
	at clojure.main$main_opt.invoke(main.clj:313)
	at clojure.main$main.invokeStatic(main.clj:424)
	at clojure.main$main.doInvoke(main.clj:387)
	at clojure.lang.RestFn.applyTo(RestFn.java:137)
	at clojure.lang.Var.applyTo(Var.java:702)
	at clojure.main.main(main.java:37)





[CLJS-2755] Can't generate uri instances Created: 21/May/18  Updated: 21/May/18  Resolved: 21/May/18

Status: Closed
Project: ClojureScript
Component/s: None
Affects Version/s: 1.10.238
Fix Version/s: None

Type: Defect Priority: Major
Reporter: Mike Fikes Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: None
Environment:

{:deps {org.clojure/clojurescript {:mvn/version "1.10.238"}
org.clojure/test.check {:mvn/version "0.10.0-alpha2"}}}


Attachments: Text File CLJS-2755.patch    
Patch: Code and Test
Approval: Accepted

 Description   
$ clj -Srepro -m cljs.main -re node -r
ClojureScript 1.10.238
cljs.user=> (require '[clojure.spec.alpha :as s] 'clojure.test.check.generators)
nil
cljs.user=> (s/gen uri?)
repl:13
throw e__6388__auto__;
^

Error: Unable to construct gen at: [] for: function cljs$core$uri_QMARK_(x){
return (x instanceof goog.Uri);
}
    at cljs$spec$alpha$gensub (/private/var/folders/60/ndky5jxj3v3gw_7j1dwq7msw0000gn/T/out213819377331478911568682775483031/cljs/spec/alpha.js:995:8)
    at Function.cljs.spec.alpha.gen.cljs$core$IFn$_invoke$arity$2 (/private/var/folders/60/ndky5jxj3v3gw_7j1dwq7msw0000gn/T/out213819377331478911568682775483031/cljs/spec/alpha.js:1031:31)
    at cljs$spec$alpha$gen (/private/var/folders/60/ndky5jxj3v3gw_7j1dwq7msw0000gn/T/out213819377331478911568682775483031/cljs/spec/alpha.js:1017:28)
    at Function.cljs.spec.alpha.gen.cljs$core$IFn$_invoke$arity$1 (/private/var/folders/60/ndky5jxj3v3gw_7j1dwq7msw0000gn/T/out213819377331478911568682775483031/cljs/spec/alpha.js:1027:28)
    at cljs$spec$alpha$gen (/private/var/folders/60/ndky5jxj3v3gw_7j1dwq7msw0000gn/T/out213819377331478911568682775483031/cljs/spec/alpha.js:1013:28)
    at repl:1:99
    at repl:9:3
    at repl:14:4
    at Script.runInThisContext (vm.js:65:33)
    at Object.runInThisContext (vm.js:197:38)

Relevant: CLJ-1958



 Comments   
Comment by David Nolen [ 21/May/18 4:01 PM ]

fixed https://github.com/clojure/clojurescript/commit/56ea8ee0de17cac909b09e2bdc1281d02e5404c9





[CLJS-2763] cljs.core/resolve fails under :advanced compilation (regression) Created: 01/Jun/18  Updated: 06/Jun/18  Resolved: 06/Jun/18

Status: Resolved
Project: ClojureScript
Component/s: None
Affects Version/s: 1.10.238
Fix Version/s: None

Type: Defect Priority: Major
Reporter: Pieter du Toit Assignee: Unassigned
Resolution: Not Reproducible Votes: 0
Labels: None

Approval: Screened

 Description   

The macro cljs.core/resolve does not produce sufficient information to invoke (when using :advanced compilation) a function across module boundaries under certain conditions.

With :advanced compilation, the attempt of module A to invoke the function in module B after load then fails at runtime. The issue occurs when using 1.10.238, but does not occur when using 1.9.946.

A minimal repro is provided below:

deps.edn
{:deps {org.clojure/clojurescript {:mvn/version "1.10.238"}}}
build.edn
{:output-dir "out"
 :optimizations :none
 :modules
 {:a {:output-to "out/a.js"
      :entries [demo.a]}
  :b {:output-to "out/b.js"
      :entries [demo.foo.b]
      :depends-on #{:a}}}
 :verbose true}
src/demo/a.cljs
(ns demo.a)

(resolve 'demo.foo.b/bar)
src/demo/foo/b.cljs
(ns demo.foo.b)

(defn bar [] :bar)
index.html
<html>
    <body>
        <script src="out/cljs_base.js"></script>
        <script src="out/a.js"></script>
    </body>
</html>

The repro can be compiled by running clj -m cljs.main -co build.edn -c



 Comments   
Comment by David Nolen [ 01/Jun/18 1:24 PM ]

See CLJS-2764, it's now no longer clear what the issue in this ticket is. The above case was simply demonstrating failing exists?.

Comment by Pieter du Toit [ 01/Jun/18 11:57 PM ]

I have narrowed the minimal repro down to React v16 being specified as a foreign lib dependency in the target module. Under :advanced compilation and with React v16, the module's compiled js function definitions are not available after the module is loaded. The attempt by the calling module to then invoke the function in the target module fails with the error "Uncaught TypeError: Cannot read property '$cljs$core$IFn$_invoke$arity$0$' of null" .

A minimal repro that produces the error is provided below:

deps.edn
{:deps {org.clojure/clojurescript {:mvn/version "1.10.238"}
        cljsjs/react {:mvn/version "16.3.2-0"} }}
src/demo/a.cljs
(ns demo.a
  (:require [cljs.loader]))

(cljs.loader/set-loaded! :a)

(cljs.loader/load :b (fn [e]
                       (.log js/console "Invoking b from a")
                       ((resolve 'demo.foo.b/bar))))
src/demo/foo/b.cljs
(ns demo.foo.b
  (:require [cljsjs.react]
            [cljs.loader]))

(defn bar [] (.log js/console "B has been loaded"))

(cljs.loader/set-loaded! :b)
index.html
<html>
    <body>
        <script src="out/cljs_base.js"></script>
        <script src="out/a.js"></script>
    </body>
</html>
build.clj
(require '[cljs.build.api :as cljs]
         '[cljs.repl :as repl]
         '[cljs.repl.browser :as browser])

(cljs/build
  "src"
  '{:output-dir "out"
    :optimizations :advanced
    :pseudo-names true
    :pretty-print true 
    :modules {:a {:output-to "out/a.js"
                  :entries [demo.a]}
              :b {:output-to "out/b.js"
                  :entries [demo.foo.b]
                  :depends-on #{:a}}}
    :verbose true})

(repl/repl (browser/repl-env)
  :output-dir "out")

It can be launched by running clj build.clj , once it is launched, observe the error message in the browser's console.

React v16's use of a global scope "use strict" directive seems to be the cause. The minimal repro can also be narrowed down further by removing the React dependency and prepending "use strict"; to out/b.js after compilation.

Comment by David Nolen [ 06/Jun/18 3:53 PM ]

See CLJS-2768 for the actual issue.





[CLJS-2768] Elide "use strict" from final output Created: 06/Jun/18  Updated: 07/Jun/18  Resolved: 07/Jun/18

Status: Closed
Project: ClojureScript
Component/s: None
Affects Version/s: 1.10.238
Fix Version/s: Next

Type: Defect Priority: Major
Reporter: David Nolen Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: newbie

Approval: Screened

 Description   

When concatenating scripts containing "use strict"; will globally apply. We should elide this in all cases where we concatenate JavaScript files. We should be careful to replace with equal length whitespace to prevent issues around source mapping. This should be default behavior. We could consider a compiler knob as a separate enhancement.



 Comments   
Comment by David Nolen [ 07/Jun/18 6:28 AM ]

fixed https://github.com/clojure/clojurescript/commit/03455b4ba4338ab05ffccefc9ddb41c8fd128cfa





[CLJS-2771] Narrow elide "use strict" match Created: 10/Jun/18  Updated: 11/Jun/18  Resolved: 11/Jun/18

Status: Closed
Project: ClojureScript
Component/s: None
Affects Version/s: 1.10.238
Fix Version/s: Next

Type: Enhancement Priority: Major
Reporter: Pieter du Toit Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: None

Attachments: Text File CLJS-2771.patch    
Patch: Code

 Description   

The match for stripping "use strict" should be narrowed to avoid possible issues as described in the issues linked below:

https://github.com/requirejs/r.js/issues/786
https://github.com/requirejs/r.js/issues/689



 Comments   
Comment by Pieter du Toit [ 10/Jun/18 11:51 PM ]

Patch is attached

Comment by David Nolen [ 11/Jun/18 8:36 AM ]

fixed https://github.com/clojure/clojurescript/commit/0ffe3d8f2aaa592e8d5b92e040e3dbfd62ab8b83





[CLJS-2767] Externs inference warnings for defrecord and deftype Created: 03/Jun/18  Updated: 13/Jun/18  Resolved: 13/Jun/18

Status: Closed
Project: ClojureScript
Component/s: None
Affects Version/s: 1.10.238
Fix Version/s: None

Type: Defect Priority: Major
Reporter: Mike Fikes Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: None
Environment:

{:deps {org.clojure/clojurescript {:mvn/version "1.10.238"}}}



 Description   

If you make use of defrecord with externs inference enabled, you end up with several warnings.

Repro:

src/foo/core.cljs
(ns foo.core)

(set! *warn-on-infer* true)

(defrecord Foo [])
$ clj -m cljs.main -co '{:infer-externs true}' -c foo.core
WARNING: Cannot infer target type in expression (. Foo -prototype) at line 5 /Users/mfikes/Desktop/src/foo/core.cljs
WARNING: Cannot infer target type in expression (. Foo -prototype) at line 5 /Users/mfikes/Desktop/src/foo/core.cljs
WARNING: Cannot infer target type in expression (. Foo -prototype) at line 5 /Users/mfikes/Desktop/src/foo/core.cljs
WARNING: Cannot infer target type in expression (. Foo -prototype) at line 5 /Users/mfikes/Desktop/src/foo/core.cljs
WARNING: Cannot infer target type in expression (. Foo -prototype) at line 5 /Users/mfikes/Desktop/src/foo/core.cljs
WARNING: Cannot infer target type in expression (. Foo -prototype) at line 5 /Users/mfikes/Desktop/src/foo/core.cljs
WARNING: Cannot infer target type in expression (. Foo -prototype) at line 5 /Users/mfikes/Desktop/src/foo/core.cljs
WARNING: Cannot infer target type in expression (. Foo -prototype) at line 5 /Users/mfikes/Desktop/src/foo/core.cljs
WARNING: Cannot infer target type in expression (. Foo -prototype) at line 5 /Users/mfikes/Desktop/src/foo/core.cljs
WARNING: Cannot infer target type in expression (. other533 -constructor) at line 5 /Users/mfikes/Desktop/src/foo/core.cljs
WARNING: Cannot infer target type in expression (. other533 -__extmap) at line 5 /Users/mfikes/Desktop/src/foo/core.cljs
WARNING: Cannot infer target type in expression (. Foo -prototype) at line 5 /Users/mfikes/Desktop/src/foo/core.cljs
WARNING: Cannot infer target type in expression (. Foo -prototype) at line 5 /Users/mfikes/Desktop/src/foo/core.cljs
WARNING: Cannot infer target type in expression (. Foo -prototype) at line 5 /Users/mfikes/Desktop/src/foo/core.cljs
WARNING: Cannot infer target type in expression (. Foo -prototype) at line 5 /Users/mfikes/Desktop/src/foo/core.cljs
WARNING: Cannot infer target type in expression (. Foo -prototype) at line 5 /Users/mfikes/Desktop/src/foo/core.cljs
WARNING: Cannot infer target type in expression (. foo.core/Foo -getBasis) at line 5 /Users/mfikes/Desktop/src/foo/core.cljs

Likewise, making use of deftype results in a warning:

src/bar/core.cljs
(ns bar.core)

(set! *warn-on-infer* true)

(deftype Bar [])
$ clj -m cljs.main -co '{:infer-externs true}' -c bar.core
WARNING: Cannot infer target type in expression (. Bar -getBasis) at line 5 /Users/mfikes/Desktop/CLJS-2767/src/bar/core.c


 Comments   
Comment by David Nolen [ 07/Jun/18 6:35 AM ]

Does this also apply to deftype?

Comment by Mike Fikes [ 07/Jun/18 11:52 AM ]

Updated ticket title / description to cover the warning generated for deftype.

Comment by Thomas Heller [ 07/Jun/18 12:55 PM ]

IIRC case, satisfies?, maybe implements? also produce infer warnings.

(case thing
  :foo :foo)

I fixed a lot of these in shadow-cljs but never got to actually producing a patch for them. At this point I forgot what the changes were though.

Comment by David Nolen [ 13/Jun/18 4:39 PM ]

fixed https://github.com/clojure/clojurescript/commit/1c4eefac5050c8480137d69d3d5b65fd53478cb2





[CLJS-2772] Trying to run `cljs.main` repl with `:modules` results in `brepl_deps.js` being `clojure.lang.LazySeq`. Created: 12/Jun/18  Updated: 15/Jun/18  Resolved: 15/Jun/18

Status: Closed
Project: ClojureScript
Component/s: None
Affects Version/s: 1.10.238
Fix Version/s: None

Type: Defect Priority: Major
Reporter: Garrett Hopper Assignee: Unassigned
Resolution: Completed Votes: 0
Labels: None


 Description   

`clj -A:cljs -co '{:modules {:cljs-base {:output-to "out/base.js"}}}'`



 Comments   
Comment by Garrett Hopper [ 12/Jun/18 10:20 PM ]

It appears the actual issue here is that `cljs.closure/build` returns `(nil)` when `opts` includes any value for `:modules`.

Comment by David Nolen [ 15/Jun/18 3:23 PM ]

fixed https://github.com/clojure/clojurescript/commit/343e6aef57b802975fca3fb5fa0fd85a20330d66





[CLJS-2784] Namespace never provided error Created: 16/Jun/18  Updated: 17/Jun/18  Resolved: 17/Jun/18

Status: Closed
Project: ClojureScript
Component/s: None
Affects Version/s: 1.10.238
Fix Version/s: None

Type: Defect Priority: Major
Reporter: Gal Dolber Assignee: Unassigned
Resolution: Completed Votes: 0
Labels: regression
Environment:

{:deps {org.clojure/clojurescript {:git/url "https://github.com/clojure/clojurescript"
:sha "ec1e416bccf7ad2d63d8e97a156dec989fa1a9d7"}
com.cognitect/transit-cljs {:mvn/version "0.8.256"}}}



 Description   
src/foo/core.cljs
(ns foo.core
 (:require cognitect.transit))
$ clj -m cljs.main -O advanced -c foo.core
Jun 17, 2018 9:09:56 AM com.google.javascript.jscomp.LoggerErrorManager println
SEVERE: /Users/mfikes/Desktop/cljs-2784/out/cognitect/transit.js:5: ERROR - required "com$.cognitect.transit" namespace never provided
goog.require('com$.cognitect.transit');
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Jun 17, 2018 9:09:56 AM com.google.javascript.jscomp.LoggerErrorManager println
SEVERE: /Users/mfikes/Desktop/cljs-2784/out/cognitect/transit.js:6: ERROR - required "com$.cognitect.transit.types" namespace never provided
goog.require('com$.cognitect.transit.types');
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Jun 17, 2018 9:09:56 AM com.google.javascript.jscomp.LoggerErrorManager println
SEVERE: /Users/mfikes/Desktop/cljs-2784/out/cognitect/transit.js:7: ERROR - required "com$.cognitect.transit.eq" namespace never provided
goog.require('com$.cognitect.transit.eq');
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
...

Reverting this commit seems to fix the issue:
https://github.com/clojure/clojurescript/commit/ec1e416bccf7ad2d63d8e97a156dec989fa1a9d7

The root cause is that, even though the intent is to munge com to com$ universally (including munging the goog.provide statements emitted for ClojureScript namespaces that start with com), it doesn't munge non-compiled goog.provide statements that are explicitly authored by hand: https://github.com/cognitect/transit-js/blob/b3cf3d60da339b73d269f14713cced33332d43a7/src/com/cognitect/transit.js#L17



 Comments   
Comment by David Nolen [ 17/Jun/18 9:03 AM ]

Hrm yeah, I'm OK on giving up on Rhino for this particular issue for now. We should reopen and lower the priority on CLJS-2770.

Comment by David Nolen [ 17/Jun/18 9:06 AM ]

fixed https://github.com/clojure/clojurescript/commit/abf4e784364c075b707ff992f6f65fecf29aae39





[CLJS-2758] Improving tracability of cljs.spec.test instrumented function call conform errors Created: 24/May/18  Updated: 19/Jun/18

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: 1.10.238
Fix Version/s: None

Type: Enhancement Priority: Major
Reporter: Christian Johansen Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: bug, enhancement, spec

Attachments: Text File 0001-Change-target-to-default-which-indicates-a-browser.patch     Text File 0002-Use-location.hostname-for-port-less-hostname.patch     Text File 0003-Infer-UA-product-for-error-parsing-from-error-stack-.patch     Text File 0004-Correct-namespace-for-locating-caller-in-spec.test.patch    
Patch: Code

 Description   

Context: Use `cljs.spec.test.alpha/instrument` to instrument `fdef`-ed functions. Call one of said functions with data that fails the argument spec. The thrown exception currently does not provide a lot of context:

1. The exception message contains "missing filename" and "missing line number" - ideally those should contain the file and line number of the offending call
2. The exception data is coded to include information about the caller, but the current implementation always yields `nil` here.

The result is that failure to conform to an fdef argument spec leaves no trace back to the call - it only tells you which function's spec was not satiesfied.

I've started to investigate, and found a few glitches, but I do not have a complete suggestion. I'm offering my patches so far, hoping to get some input on whether or not it would be desirable for me to continue investigating.

Here's what I found so far:

1. `target` was assumed to be `"browser"`, while it is documented to be `"default"` in browsers. Fixed in first patch
2. When attempting to parse the stack trace to find the caller, `host` included the port number. Adressed in the second patch
3. When attempting to parse the stack trace, `goog.userAgent.product` is used to determine the browser, but it is not reliable - for example, `product/IPHONE` is true when Chrome is in responsive design mode. This is both incorrect, and helpeless in the case of `cljs.spec.test.alpha`, which does not recognize iphones at all. Because the user agent is only used to parse stack traces, I fixed this by inferring the user agent from the stack trace instead.
4. The `find-caller` function used the wrong package name to find the `spec_checking_fn`. Additionally, it hard-coded the dots in the package name, while some browsers use `$`. I fixed this in the forth patch. I also moved creating the error outside of the `conform!` anonymous function, as placing it here removes `spec-checking-fn` from the stack trace.

With these patches, the caller is set reliably, although it doesn't seem to reflect the originating call-site. Also, the thrown exception still lacks file name and line number. I'd be happy to continue investigating, and add some tests if you are interested in eventually accepting these patches.

As a side-note: It seems to me that the function that infers user agent from stack trace more appropriately belongs in stacktrace.cljs, and I feel strongly that this should be the default behavior when no `user-agent-product` is provided (instead of the current: returning the stack trace string unmodified). I'll be happy to fix this as well, and add some tests, if the interest is there. Note that the current approach allows Safari to go down the Firefox route, which works like a charm.

Lastly: sorry if I put too many things in one place, I'll be happy to split up as instructed.



 Comments   
Comment by David Nolen [ 15/Jun/18 3:52 PM ]

Thanks! Have you submitted a CA?

Comment by Christian Johansen [ 19/Jun/18 4:21 AM ]

I sure have





[CLJS-2787] Record comparison is broken when instance is constructed from another record instance via map factory Created: 21/Jun/18  Updated: 22/Jun/18  Resolved: 22/Jun/18

Status: Closed
Project: ClojureScript
Component/s: None
Affects Version/s: 1.10.238
Fix Version/s: None

Type: Defect Priority: Major
Reporter: Yuri Govorushchenko Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: None
Environment:

CLJS



 Description   

Steps:

(defrecord A [])
(def x (map->A {1 2}))
(def y (map->A x))
(= x y)

Actual: false.

Expected: true (as in Clojure).



 Comments   
Comment by David Nolen [ 22/Jun/18 3:49 PM ]

fixed https://github.com/clojure/clojurescript/commit/5e4260360d209a50c004cd524317c76e7e0b68e7





[CLJS-2798] ChunkCons -next doesn't handle nil more Created: 01/Jul/18  Updated: 01/Jul/18  Resolved: 01/Jul/18

Status: Closed
Project: ClojureScript
Component/s: None
Affects Version/s: 1.10.238
Fix Version/s: None

Type: Defect Priority: Major
Reporter: Mike Fikes Assignee: Mike Fikes
Resolution: Completed Votes: 0
Labels: None
Environment:

{:deps {org.clojure/clojurescript {:mvn/version "1.10.339"}}


Attachments: Text File CLJS-2798.patch    
Patch: Code and Test
Approval: Accepted

 Description   

Repro:

Evaluate the following in Clojure:

(let [b (chunk-buffer 1)]
 (chunk-append b 0)
 (next (chunk-cons (chunk b) nil)))

and you will get back nil.

In ClojureScript, this will produce an error "No protocol method ISeqable.-seq defined for type null".

The 2nd argument to chunk-cons can be nil, viz: https://github.com/clojure/clojurescript/blob/b1ade48e21f9e7f78d9db74559ce4dd5846d0c94/src/main/clojure/cljs/core.cljc#L2420



 Comments   
Comment by Mike Fikes [ 01/Jul/18 4:06 PM ]

fixed https://github.com/clojure/clojurescript/commit/892ed2029db42cc3728e6e99a37d99b4ec53ecc0





[CLJS-2818] Support `export ... from ...` syntax Created: 12/Jul/18  Updated: 18/Jul/18

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: 1.10.238
Fix Version/s: None

Type: Defect Priority: Major
Reporter: Corin Lawson Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None


 Description   

Affects: 1.9.1033+

I have a minimal repro repo here: https://github.com/au-phiware/cljs-2818

Description of problem

Prior to the update to Closure compiler in CLJS-2389, ES6 modules that used the {{export { x as y } from './x'}} or {{export { default as y } from './x'}} syntax compiled correctly. Other forms of this syntax, such as {{export { default } from './x'}}, did not.

Since 1.9.1033, the compiler no longer emits the goog.require statements nor does it emit a complete set of goog.addDependency statements in cljs_deps.js.

Steps to reproduce the problem

Consider the following source files:

src/foo/core.cljs
(ns foo.core (:require [hello :refer [helloGreet]]))                                 

(def ^:export sayHello
    (helloGreet "World"))

(sayHello)
es6/hello.js
export {
    default as helloGreet
} from "./greet";
es6/greet.js
export default function greet(m) {
    document.write("\nHello, " + m);
};
build.clj
(require 'cljs.build.api)

(cljs.build.api/build
  "src"
  {:main 'foo.core
   :output-to "target/main.js"
   :output-dir "target/main.out"
   :asset-path "main.out"
   :foreign-libs [{:file "es6/hello.js"
                   :provides ['hello]
                   :module-type :es6}]
   :verbose true
   :npm-deps {"@cljs-oss/module-deps" "*"}
   :install-deps true})

Execute cljs:

java -cp cljs.jar:src clojure.main build.clj

Expected outcome

cljs should exit cleanly and write the following files (approximately).

target/main.out/cljs_deps.js
goog.addDependency("base.js", ['goog'], []);
goog.addDependency("../cljs/core.js", ['cljs.core'], ['goog.string', 'goog.Uri', 'goog.object', 'goog.math.Integer', 'goog.string.StringBuffer', 'goog.array', 'goog.math.Long']);
goog.addDependency("../process/env.js", ['process.env'], ['cljs.core']);
goog.addDependency("../es6/greet.js", ['module$usr$src$es6$greet'], []);
goog.addDependency("../es6/hello.js", ['module$usr$src$es6$hello'], ['module$usr$src$es6$greet']);
goog.addDependency("../foo/core.js", ['foo.core'], ['cljs.core', 'module$usr$src$es6$hello']);
target/main.out/es6/hello.js
goog.provide("module$usr$src$es6$hello");
goog.require("module$usr$src$es6$greet");
module$usr$src$es6$hello.helloGreet=module$usr$src$es6$greet["default"]

Actual outcome

The cljs_deps.js is missing the es6/greet.js dependency:

target/main.out/cljs_deps.js
goog.addDependency("base.js", ['goog'], []);
goog.addDependency("../cljs/core.js", ['cljs.core'], ['goog.string', 'goog.Uri', 'goog.object', 'goog.math.Integer', 'goog.string.StringBuffer', 'goog.array', 'goog.math.Long']);
goog.addDependency("../process/env.js", ['process.env'], ['cljs.core']);
goog.addDependency("../es6/hello.js", ['module$usr$src$es6$hello'], []);
goog.addDependency("../foo/core.js", ['foo.core'], ['cljs.core', 'module$usr$src$es6$hello']);

And the es6/hello.js file is missing the goog.requires statement:

target/main.out/es6/hello.js
goog.provide("module$usr$src$es6$hello");
var module$usr$src$es6$hello={get helloGreet(){return module$usr$src$es6$greet["default"]}}

Furthermore, the browser console shows:

>>> module$usr$src$es6$hello.helloGreet
hello.js:2 Uncaught ReferenceError: module$usr$src$es6$greet is not defined
    at Object.get helloGreet [as helloGreet] (hello.js:2)
    at <anonymous>:1:65

Attempted workaround

Explicitly adding the :requires option to es6/hello.js :foreign-libs entry did not remedy the problem (nor did using an entry for the whole es6 directory or using an npm module, e.g. d3-scale). Neither did adding [greet] to foo.core's requires.



 Comments   
Comment by Corin Lawson [ 18/Jul/18 4:59 AM ]

This appears to be an issue upstream in the Google Closure Compiler...

Comment by Corin Lawson [ 18/Jul/18 6:09 AM ]

The sample same es6 code compiles just fine with gcc, using java -jar $JAR -O WHITESPACE_ONLY --js_output_file=/dev/stdout -W VERBOSE --module_resolution NODE greet.js hello.js. But when cljs calls upon gcc to convert the es6 code the resulting source is missing the goog.require statement... could it be the module_resolution?

Comment by Corin Lawson [ 18/Jul/18 6:52 AM ]

I've noticed that gcc with -O BUNDLE --dependency_mode STRICT fails to emit the greet dep... getting a little confused at this point...

Comment by Corin Lawson [ 18/Jul/18 7:32 PM ]

If I apply this patch to gcc, then it will detect the correct requires of hello.js

diff --git a/src/com/google/javascript/jscomp/CompilerInput.java b/src/com/google/javascript/jscomp/CompilerInput.java
index 62609562b..4e4d3e3dc 100644
--- a/src/com/google/javascript/jscomp/CompilerInput.java
+++ b/src/com/google/javascript/jscomp/CompilerInput.java
@@ -285,7 +285,7 @@ public class CompilerInput extends DependencyInfo.Base implements SourceAst {
 
     // If the code is a JsAst, then it was originally JS code, and is compatible with the
     // regex-based parsing of JsFileParser.
-    if (ast instanceof JsAst && JsFileParser.isSupported()) {
+    if (false && ast instanceof JsAst && JsFileParser.isSupported()) {
       // Look at the source code.
       // Note: it's OK to use getName() instead of
       // getPathRelativeToClosureBase() here because we're not using

But now cljs thinks that greet should be named "module$usr$src$greet" instead of "module$usr$src$es6$greet", but this also seems to be a gcc bug.

Comment by Corin Lawson [ 18/Jul/18 9:29 PM ]

See https://github.com/google/closure-compiler/pull/3026





[CLJS-2838] [spec] s/& does not check preds if regex matches empty collection Created: 21/Jul/18  Updated: 03/Aug/18  Resolved: 03/Aug/18

Status: Closed
Project: ClojureScript
Component/s: None
Affects Version/s: 1.10.238
Fix Version/s: None

Type: Defect Priority: Major
Reporter: Mike Fikes Assignee: Mike Fikes
Resolution: Completed Votes: 0
Labels: spec

Attachments: Text File CLJS-2838.patch    
Patch: Code and Test
Approval: Accepted

 Description   

Port CLJ-2182 to ClojureScript.



 Comments   
Comment by Mike Fikes [ 03/Aug/18 2:18 PM ]

fixed https://github.com/clojure/clojurescript/commit/0ec3870d8e301f2d3c99c7dd9714f3fb101ba5c9





[CLJS-2840] [spec] s/keys explain-data :pred problem Created: 21/Jul/18  Updated: 03/Aug/18  Resolved: 03/Aug/18

Status: Closed
Project: ClojureScript
Component/s: None
Affects Version/s: 1.10.238
Fix Version/s: None

Type: Defect Priority: Major
Reporter: Mike Fikes Assignee: Mike Fikes
Resolution: Completed Votes: 0
Labels: spec

Attachments: Text File CLJS-2840.patch    
Patch: Code and Test
Approval: Accepted

 Description   

Port CLJ-2177 to ClojureScript.



 Comments   
Comment by Mike Fikes [ 03/Aug/18 2:27 PM ]

fixed https://github.com/clojure/clojurescript/commit/e58cf89115f7f08354ba09caeb63eff08b142f01





[CLJS-2844] [spec] Add support for undefining a spec Created: 21/Jul/18  Updated: 03/Aug/18  Resolved: 03/Aug/18

Status: Closed
Project: ClojureScript
Component/s: None
Affects Version/s: 1.10.238
Fix Version/s: None

Type: Enhancement Priority: Major
Reporter: Mike Fikes Assignee: Mike Fikes
Resolution: Completed Votes: 0
Labels: spec

Attachments: Text File CLJS-2844.patch    
Patch: Code and Test
Approval: Accepted

 Description   

Port CLJ-2060



 Comments   
Comment by Mike Fikes [ 03/Aug/18 2:33 PM ]

fixed https://github.com/clojure/clojurescript/commit/7187f8f91ee2cc35b41e22899c6103c86674dd2b





[CLJS-2845] [spec] generate random subsets of or'd required keys in map specs Created: 21/Jul/18  Updated: 03/Aug/18  Resolved: 03/Aug/18

Status: Closed
Project: ClojureScript
Component/s: None
Affects Version/s: 1.10.238
Fix Version/s: None

Type: Enhancement Priority: Major
Reporter: Mike Fikes Assignee: Mike Fikes
Resolution: Completed Votes: 0
Labels: spec

Attachments: Text File CLJS-2845.patch    
Patch: Code and Test
Approval: Accepted

 Description   

Port CLJ-2046



 Comments   
Comment by Mike Fikes [ 03/Aug/18 2:39 PM ]

fixed https://github.com/clojure/clojurescript/commit/1261aed07d5e11b38d5deafcf6afa4a7abe4b346





[CLJS-2841] [spec] instrument exception doesn't contain function name in ex-data Created: 21/Jul/18  Updated: 03/Aug/18  Resolved: 03/Aug/18

Status: Closed
Project: ClojureScript
Component/s: None
Affects Version/s: 1.10.238
Fix Version/s: None

Type: Defect Priority: Major
Reporter: Mike Fikes Assignee: Mike Fikes
Resolution: Completed Votes: 0
Labels: spec

Attachments: Text File CLJS-2841.patch    
Patch: Code
Approval: Accepted

 Description   

Port CLJ-2166 to ClojureScript.



 Comments   
Comment by Mike Fikes [ 03/Aug/18 2:42 PM ]

fixed https://github.com/clojure/clojurescript/commit/4d408e1aae6961611200abb9f839838ebf6966a8





[CLJS-2847] s/coll-of and s/every gen is very slow if :kind specified without :into Created: 21/Jul/18  Updated: 03/Aug/18  Resolved: 03/Aug/18

Status: Closed
Project: ClojureScript
Component/s: None
Affects Version/s: 1.10.238
Fix Version/s: None

Type: Defect Priority: Major
Reporter: Mike Fikes Assignee: Mike Fikes
Resolution: Completed Votes: 0
Labels: spec

Attachments: Text File CLJS-2847.patch    
Patch: Code
Approval: Accepted

 Description   

Port CLJ-2103.



 Comments   
Comment by Mike Fikes [ 21/Jul/18 5:18 PM ]

Before:

cljs.user=> (time (dorun (gen/sample (s/gen (s/coll-of int? :kind list?)) 1000)))
"Elapsed time: 18424.869714 msecs"

After:

cljs.user=> (time (dorun (gen/sample (s/gen (s/coll-of int? :kind list?)) 1000)))
"Elapsed time: 943.532827 msecs"
Comment by Mike Fikes [ 03/Aug/18 2:43 PM ]

fixed https://github.com/clojure/clojurescript/commit/a6885a0cb21274fcab180cc82c4b791ee96197c5





[CLJS-2846] [spec] s/tuple explain-data :pred problem Created: 21/Jul/18  Updated: 03/Aug/18  Resolved: 03/Aug/18

Status: Closed
Project: ClojureScript
Component/s: None
Affects Version/s: 1.10.238
Fix Version/s: None

Type: Defect Priority: Major
Reporter: Mike Fikes Assignee: Mike Fikes
Resolution: Completed Votes: 0
Labels: spec

Attachments: Text File CLJS-2846.patch    
Patch: Code and Test
Approval: Accepted

 Description   

Port CLJ-2176



 Comments   
Comment by Mike Fikes [ 03/Aug/18 2:46 PM ]

fixed https://github.com/clojure/clojurescript/commit/6152a3165b3196cc25e0929f6b2367d2761f15ac





[CLJS-2848] Default explain printer prints root val and spec Created: 21/Jul/18  Updated: 03/Aug/18  Resolved: 03/Aug/18

Status: Closed
Project: ClojureScript
Component/s: None
Affects Version/s: 1.10.238
Fix Version/s: None

Type: Defect Priority: Major
Reporter: Mike Fikes Assignee: Mike Fikes
Resolution: Completed Votes: 0
Labels: spec

Attachments: Text File CLJS-2848.patch    
Patch: Code
Approval: Accepted

 Description   

Port CLJ-2171



 Comments   
Comment by Mike Fikes [ 03/Aug/18 2:48 PM ]

fixed https://github.com/clojure/clojurescript/commit/d2cc14af6b26cd06bbd4d871123d4dd82c8ca4e0





[CLJS-2735] Refine doc string for defmulti Created: 11/Apr/18  Updated: 22/Sep/18

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: 1.10.238
Fix Version/s: None

Type: Enhancement Priority: Major
Reporter: Mike Fikes Assignee: David Nolen
Resolution: Unresolved Votes: 0
Labels: docstring, newbie

Attachments: Text File CLJS-2735-2.patch     Text File CLJS-2735-3.patch     Text File CLJS-2735.patch    
Patch: Code

 Description   

CLJ-835 but for ClojureScript.

Perhaps we can copy Clojure's current docstring over en masse, replacing "Clojure" references to "ClojureScript", and ensuring that it is accurate for ClojureScript's defmulti semantics / behavior.



 Comments   
Comment by Pankaj Doharey [ 21/Sep/18 8:12 AM ]

Created a pull request on Github here https://github.com/clojure/clojurescript/pull/79

Comment by Pankaj Doharey [ 21/Sep/18 8:16 AM ]

Attached a CLJS-2735 patch in any case.

Comment by Mike Fikes [ 21/Sep/18 8:27 AM ]

Hey Pankaj, thanks for the contribution. Can you make a patch using the instructions here? https://clojurescript.org/community/patches

Comment by Pankaj Doharey [ 21/Sep/18 8:54 AM ]

Hi Mike, just uploaded a new patch based on the instructions on the given page.

Thanks.

Comment by Pankaj Doharey [ 22/Sep/18 12:37 PM ]

Update on the patch.

Comment by Mike Fikes [ 22/Sep/18 3:12 PM ]

Hey Pankaj, if you look at CLJ-835, you'll see the text to the right of :hierarchy that is in your patch should be removed.

Comment by Pankaj Doharey [ 22/Sep/18 3:22 PM ]

Yes will remove it.

Comment by Pankaj Doharey [ 22/Sep/18 3:29 PM ]

Updates docs string and removes incorrect :hierarchy text.

Comment by Mike Fikes [ 22/Sep/18 4:06 PM ]

CLJS-2735-3.patch LGTM





[CLJS-2915] Tests fail if directory has a period (.) in the path Created: 16/Sep/18  Updated: 28/Sep/18  Resolved: 28/Sep/18

Status: Closed
Project: ClojureScript
Component/s: None
Affects Version/s: 1.10.238
Fix Version/s: None

Type: Defect Priority: Major
Reporter: Ray McDermott Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: None

Attachments: Text File CLJS-2915.patch    
Patch: Code

 Description   

Check out compiler into a cljs.dev directory and run lein test :only cljs.module-processing-tests.

Seems very similar to CLJS-2914.

$ lein test :only cljs.module-processing-tests

lein test cljs.module-processing-tests

lein test :only cljs.module-processing-tests/test-module-name-substitution

FAIL in (test-module-name-substitution) (module_processing_tests.clj:124)
expected: (= (str "goog.provide('my_calculator.core');" crlf "goog.require('cljs.core');" crlf "goog.require('" (absolute-module-path "src/test/cljs/calculator.js" true) "');" crlf) (compile (quote (ns my-calculator.core (:require [calculator :as calc :refer [subtract add] :rename {subtract sub}])))))
  actual: (not (= "goog.provide('my_calculator.core');\ngoog.require('cljs.core');\ngoog.require('module$Users$ray$dev$cljs.dev$clojurescript$src$test$cljs$calculator');\n" "goog.provide('my_calculator.core');\ngoog.require('cljs.core');\ngoog.require('module$Users$ray$dev$cljs_dev$clojurescript$src$test$cljs$calculator');\n"))

lein test :only cljs.module-processing-tests/test-module-name-substitution

FAIL in (test-module-name-substitution) (module_processing_tests.clj:129)
expected: (= output (compile (quote (calc/add 3 4))))
  actual: (not (= "module$Users$ray$dev$cljs.dev$clojurescript$src$test$cljs$calculator[\"default\"].add((3),(4));\n" "module$Users$ray$dev$cljs_dev$clojurescript$src$test$cljs$calculator[\"default\"].add((3),(4));\n"))

lein test :only cljs.module-processing-tests/test-module-name-substitution

FAIL in (test-module-name-substitution) (module_processing_tests.clj:130)
expected: (= output (compile (quote (calculator/add 3 4))))
  actual: (not (= "module$Users$ray$dev$cljs.dev$clojurescript$src$test$cljs$calculator[\"default\"].add((3),(4));\n" "module$Users$ray$dev$cljs_dev$clojurescript$src$test$cljs$calculator[\"default\"].add((3),(4));\n"))

lein test :only cljs.module-processing-tests/test-module-name-substitution

FAIL in (test-module-name-substitution) (module_processing_tests.clj:131)
expected: (= output (compile (quote (add 3 4))))
  actual: (not (= "module$Users$ray$dev$cljs.dev$clojurescript$src$test$cljs$calculator[\"default\"].add((3),(4));\n" "module$Users$ray$dev$cljs_dev$clojurescript$src$test$cljs$calculator[\"default\"].add((3),(4));\n"))

lein test :only cljs.module-processing-tests/test-module-name-substitution

FAIL in (test-module-name-substitution) (module_processing_tests.clj:132)
expected: (= (str (absolute-module-path "src/test/cljs/calculator.js" true) "[\"default\"].subtract((5),(4));" crlf) (compile (quote (sub 5 4))))
  actual: (not (= "module$Users$ray$dev$cljs.dev$clojurescript$src$test$cljs$calculator[\"default\"].subtract((5),(4));\n" "module$Users$ray$dev$cljs_dev$clojurescript$src$test$cljs$calculator[\"default\"].subtract((5),(4));\n"))

lein test :only cljs.module-processing-tests/commonjs-module-processing-preprocess-symbol

FAIL in (commonjs-module-processing-preprocess-symbol) (module_processing_tests.clj:191)
Processed modules are added to :js-module-index
expected: (= {"React" {:name (absolute-module-path "src/test/cljs/reactJS.js"), :module-type :commonjs}, "Circle" {:name (absolute-module-path "src/test/cljs/Circle.js"), :module-type :commonjs}} (:js-module-index (clojure.core/deref cenv)))
  actual: (not (= {"React" {:name "module$Users$ray$dev$cljs.dev$clojurescript$src$test$cljs$reactJS", :module-type :commonjs}, "Circle" {:name "module$Users$ray$dev$cljs.dev$clojurescript$src$test$cljs$Circle", :module-type :commonjs}} {"React" {:name "module$Users$ray$dev$cljs-dev$clojurescript$src$test$cljs$reactJS", :module-type :commonjs}, "Circle" {:name "module$Users$ray$dev$cljs-dev$clojurescript$src$test$cljs$Circle", :module-type :commonjs}}))

lein test :only cljs.module-processing-tests/es6-module-processing

FAIL in (es6-module-processing) (module_processing_tests.clj:97)
Processed modules are added to :js-module-index
expected: (= {"es6-hello" {:name (absolute-module-path "src/test/cljs/es6_hello.js"), :module-type :es6}} (:js-module-index (clojure.core/deref cenv)))
  actual: (not (= {"es6-hello" {:name "module$Users$ray$dev$cljs.dev$clojurescript$src$test$cljs$es6-hello", :module-type :es6}} {"es6-hello" {:name "module$Users$ray$dev$cljs-dev$clojurescript$src$test$cljs$es6-hello", :module-type :es6}}))

lein test :only cljs.module-processing-tests/test-cljs-1822

FAIL in (test-cljs-1822) (module_processing_tests.clj:162)
Processed modules are added to :js-module-index
expected: (= {"React" {:name (absolute-module-path "src/test/cljs/react-min.js"), :module-type :commonjs}, "Circle" {:name (absolute-module-path "src/test/cljs/Circle-min.js"), :module-type :commonjs}} (:js-module-index (clojure.core/deref cenv)))
  actual: (not (= {"React" {:name "module$Users$ray$dev$cljs.dev$clojurescript$src$test$cljs$react-min", :module-type :commonjs}, "Circle" {:name "module$Users$ray$dev$cljs.dev$clojurescript$src$test$cljs$Circle-min", :module-type :commonjs}} {"React" {:name "module$Users$ray$dev$cljs-dev$clojurescript$src$test$cljs$react-min", :module-type :commonjs}, "Circle" {:name "module$Users$ray$dev$cljs-dev$clojurescript$src$test$cljs$Circle-min", :module-type :commonjs}}))

lein test :only cljs.module-processing-tests/commonjs-module-processing

FAIL in (commonjs-module-processing) (module_processing_tests.clj:71)
Processed modules are added to :js-module-index
expected: (= {"React" {:name (absolute-module-path "src/test/cljs/reactJS.js"), :module-type :commonjs}, "Circle" {:name (absolute-module-path "src/test/cljs/Circle.js"), :module-type :commonjs}} (:js-module-index (clojure.core/deref cenv)))
  actual: (not (= {"React" {:name "module$Users$ray$dev$cljs.dev$clojurescript$src$test$cljs$reactJS", :module-type :commonjs}, "Circle" {:name "module$Users$ray$dev$cljs.dev$clojurescript$src$test$cljs$Circle", :module-type :commonjs}} {"React" {:name "module$Users$ray$dev$cljs-dev$clojurescript$src$test$cljs$reactJS", :module-type :commonjs}, "Circle" {:name "module$Users$ray$dev$cljs-dev$clojurescript$src$test$cljs$Circle", :module-type :commonjs}}))

Ran 5 tests containing 14 assertions.
9 failures, 0 errors.
Tests failed.


 Comments   
Comment by Ray McDermott [ 16/Sep/18 8:13 AM ]

It's looking for cljs_dev

Comment by Ray McDermott [ 25/Sep/18 4:51 PM ]

Building on the code fix for CLJS-2782 we can replace the periods with hyphens and then leverage the cond-> to selectively transform to underscores.

Comment by Ray McDermott [ 25/Sep/18 4:59 PM ]

Patch attached

Comment by Mike Fikes [ 25/Sep/18 9:06 PM ]

Hey Ray, this patch doesn't apply on master. Is the intent that this patch depend on the patch in CLJS-2782 being applied first? (Usually patches are independent, but in some cases a patch can depend on changes in another ticket if it needs to.)

Comment by Ray McDermott [ 26/Sep/18 4:25 AM ]

Hi Mike - yes the patch for CLJS-2782 needs to be applied first. If it was done the other way around, that patch would revert this one.

Another option would be to close the other bug with a new patch here that squashes both bugs.

I was concerned about trying to close two bugs with one patch but yes the ordering / dependency is not good either.

How would you prefer to handle it?

Comment by Mike Fikes [ 26/Sep/18 6:30 AM ]

Since one patch revises a line and another patch adds a new line, you could normally make independent patches where either could be applied first. But, the problem with this pair of tickets, though, is that the changes are sufficiently close together that whichever patch is applied second will need to be re-baselined. (I don't know what the threshold is, but anywhere within a few lines will do it.) To avoid that, we might as well have this patch depend on the one in CLJS-2782 being applied first.

Comment by Mike Fikes [ 26/Sep/18 7:08 AM ]

CLJS-2915.patch LGTM. Note that it is designed to be applied after the patch in CLJS-2782.

Tested locally with a checkout in a directory with both dots and hyphens. Also passes in CI.

Comment by David Nolen [ 28/Sep/18 11:50 AM ]

fixed https://github.com/clojure/clojurescript/commit/6eedd0a08c49f7b0d4dcb30977b2fb38c90577bd





[CLJS-2930] logging via goog.log not visible for optimizations other than none Created: 08/Oct/18  Updated: 09/Oct/18

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: 1.10.238
Fix Version/s: None

Type: Defect Priority: Major
Reporter: Gert Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: nodejs
Environment:

node: v10.10.0
clj: 1.9.0.391
cljs: v1.10.338 (and sha "6eedd0a08c49f7b0d4dcb30977b2fb38c90577bd")



 Description   

steps to reproduce

Given

deps.edn
{:paths
 ["."]

 :deps
 {org.clojure/clojurescript {:mvn/version "1.10.339"
                             #_#_:git/url "https://github.com/clojure/clojurescript.git"
                             #_#_:sha "6eedd0a08c49f7b0d4dcb30977b2fb38c90577bd"}}}
foo.cljs
(ns foo
  (:require [goog.log :as glog])
  (:import goog.debug.Console))

(def logger
  (glog/getLogger "app"))

(def console (goog.debug.Console.))

(defn workaround! []
  (.setConsole goog.debug.Console js/console))


(defn -main [& args]
  (.setCapturing console true)
  (.setLevel logger goog.debug.Logger.Level.FINEST)

  (when args
    (workaround!))
  (glog/error logger "some error"))

(set! *main-cli-fn* -main)

When I compile with optimization `none` and run, logging does appear:

$ clj -m cljs.main -v -O none -t node -c foo
$ node out/main.js
 [  0.002s] [app] some error

When I compile with optimization `simple` (or `advanced`) and run, logging does not appear.

Expected: optimization simple should have no effect on appearance of logging on Node (just like when compiling for the browser).

various (FWIW)

With simple, `goog.debug.Console.console_` ends up being nil as `goog.global['console']` is nil (https://github.com/google/closure-library/blob/master/closure/goog/debug/console.js#L169).

`println` works in both none and simple.

When targetting browser both none and simple show logging.

A workaround is to setConsole: `(.setConsole goog.debug.Console js/console)`



 Comments   
Comment by Thomas Heller [ 09/Oct/18 4:07 AM ]

FWIW the problem in node is that goog.global is not assigned correctly.

In goog/base.js it is assigned to goog.global = this; but this in node it the current Module instance and not the usual window. module.console does not exist so is not assigned correctly. This works differently in development since the nodejs bootstrap explicitly loads the code with global as this [1]. This will not be done in production so the "default" this becomes the module and breaks optimizied code.

I think its fine to just always use the workaround! since it doesn't break anything.

[1] https://github.com/clojure/clojurescript/blob/master/src/main/cljs/cljs/bootstrap_nodejs.js#L114





[CLJS-2939] A folders index.js does not provide the parent dir as module Created: 20/Oct/18  Updated: 22/Oct/18

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: 1.10.238
Fix Version/s: None

Type: Defect Priority: Major
Reporter: Abel Varga Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: bug, enhancement


 Description   

In Javascript when a module is required you can omit the extension in the relative path form. If you do and the path is a directory and that directory contains an `index.js`, that file is treated as the main script.

So, this statement:

```javascript
const foo = require('./foo')
```

Can be resolved as `./foo.js` or `./foo/index.js`.

The module resolver should take this into account, and if an `index.js` is resolved in a required directory, it should also provide like both

```
module$Users$user$Documents$project$node_modules$foo$index
module$Users$user$Documents$project$node_modules$foo
```

Actual repr here: [cljs-name-to-path-issue](https://github.com/rangeoshun/cljs-name-to-path-issue)

It produced the following error in browser:

`Undefined nameToPath for module$Users$range$Documents$cljs_name_to_path_issue$node_modules$deat_mui_core$colors`

It is because `node_modules/deat-mui-core/colors/index.js` only provides the following in the compiled version:

```javascript
goog.provide("module$Users$range$Documents$cljs_name_to_path_issue$node_modules$deat_mui_core$colors$index");
```

It should also provide if that makes no confilct:

```javascript
goog.provide("module$Users$range$Documents$cljs_name_to_path_issue$node_modules$deat_mui_core$colors");
```



 Comments   
Comment by Abel Varga [ 20/Oct/18 6:51 AM ]

Sorry for faulty markdown

Comment by Abel Varga [ 22/Oct/18 5:27 AM ]

Please close, as looking through the tests it seems it works, so the `lein-cljsbuild` might be out of date on this dep.





[CLJS-2809] Using `:foreign-libs` along with `:npm-deps` fails depending on order of requires Created: 06/Jul/18  Updated: 06/Jul/18

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: 1.10.238
Fix Version/s: None

Type: Defect Priority: Major
Reporter: Garrett Hopper Assignee: Unassigned
Resolution: Unresolved Votes: 1
Labels: clojurescript
Environment:

Clojure 1.9.0.381
Java 1.8



 Description   
Starting a REPL with both `:npm-deps` and `:foreign-libs`
clj -Sdeps "{:deps {org.clojure/clojurescript {:mvn/version \"1.10.339\"}}}" -m cljs.main -co "{:npm-deps {left-pad \"1.3.0\"} :install-deps true :foreign-libs [{:file \"https://apis.google.com/js/platform.js\" :provides [\"google.api\"] :global-exports {google.api gapi}}]}" -r
Requiring the `:foreign-libs` library after the `:npm-deps` dependency fails
cljs.user=> (require '[left-pad])
cljs.user=> (require '[google.api])
java.io.FileNotFoundException: /home/garrett/https:/apis.google.com/js/platform.js (No such file or directory)
        at java.io.FileInputStream.open0(Native Method)
        at java.io.FileInputStream.open(FileInputStream.java:195)
        at java.io.FileInputStream.<init>(FileInputStream.java:138)
        at java.io.FileInputStream.<init>(FileInputStream.java:93)
        at sun.net.www.protocol.file.FileURLConnection.connect(FileURLConnection.java:90)
        at sun.net.www.protocol.file.FileURLConnection.getInputStream(FileURLConnection.java:188)
        at cljs.util$last_modified.invokeStatic(util.cljc:224)
        at cljs.util$last_modified.invoke(util.cljc:216)
        at cljs.util$changed_QMARK_.invokeStatic(util.cljc:232)
        at cljs.util$changed_QMARK_.invoke(util.cljc:231)
        at cljs.closure$handle_js_modules$fn__5877.invoke(closure.clj:2670)
        at clojure.core$some.invokeStatic(core.clj:2693)
        at clojure.core$some.invoke(core.clj:2684)
        at cljs.closure$handle_js_modules.invokeStatic(closure.clj:2667)
        at cljs.closure$handle_js_modules.invoke(closure.clj:2633)
        at cljs.repl$evaluate_form.invokeStatic(repl.cljc:508)
        at cljs.repl$evaluate_form.invoke(repl.cljc:484)
        at cljs.repl$eval_cljs.invokeStatic(repl.cljc:672)
        at cljs.repl$eval_cljs.invoke(repl.cljc:665)
        at cljs.repl$repl_STAR_$read_eval_print__6536.invoke(repl.cljc:957)
        at cljs.repl$repl_STAR_$fn__6542$fn__6551.invoke(repl.cljc:998)
        at cljs.repl$repl_STAR_$fn__6542.invoke(repl.cljc:997)
        at cljs.compiler$with_core_cljs.invokeStatic(compiler.cljc:1285)
        at cljs.compiler$with_core_cljs.invoke(compiler.cljc:1274)
        at cljs.repl$repl_STAR_.invokeStatic(repl.cljc:960)
        at cljs.repl$repl_STAR_.invoke(repl.cljc:839)
        at cljs.cli$repl_opt.invokeStatic(cli.clj:290)
        at cljs.cli$repl_opt.invoke(cli.clj:277)
        at cljs.cli$main.invokeStatic(cli.clj:612)
        at cljs.cli$main.doInvoke(cli.clj:601)
        at clojure.lang.RestFn.applyTo(RestFn.java:139)
        at clojure.core$apply.invokeStatic(core.clj:659)
        at clojure.core$apply.invoke(core.clj:652)
        at cljs.main$_main.invokeStatic(main.clj:61)
        at cljs.main$_main.doInvoke(main.clj:52)
        at clojure.lang.RestFn.applyTo(RestFn.java:137)
        at clojure.lang.Var.applyTo(Var.java:702)
        at clojure.core$apply.invokeStatic(core.clj:657)
        at clojure.main$main_opt.invokeStatic(main.clj:317)
        at clojure.main$main_opt.invoke(main.clj:313)
        at clojure.main$main.invokeStatic(main.clj:424)
        at clojure.main$main.doInvoke(main.clj:387)
        at clojure.lang.RestFn.applyTo(RestFn.java:137)
        at clojure.lang.Var.applyTo(Var.java:702)
        at clojure.main.main(main.java:37)
Requiring the `:foreign-libs` library before the `:npm-deps` dependency works
cljs.user=> (require '[google.api])
cljs.user=> (require '[left-pad])


 Comments   
Comment by David Nolen [ 06/Jul/18 1:18 PM ]

It seems the issue here might not be one of order but of mishandling `:file` entries that use URLs.





[CLJS-2985] Doc for DOT has example showing incorrect/discouraged use of aget Created: 20/Nov/18  Updated: 20/Nov/18

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: 1.10.238
Fix Version/s: None

Type: Defect Priority: Major
Reporter: Mark Hayes Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None


 Description   

I just finished reading the doc on misuse of aget/aset for js objects and then stumbled on an example showing the wrong use of aget:
http://cljs.github.io/api/cljs.core/DOT


You can get the value at property "foo" with any of the following:

(. o -foo)
;;=> "bar"

(.-foo o)
;;=> "bar"

(aget o "foo")
;;=> "bar"


I assume that last example is a doc bug from the past. I marked the priority as Major because it seems there is a big problem with misuse of aget and this doc error isn't helping.






[CLJS-2802] empty? is broken for transient collections Created: 03/Jul/18  Updated: 24/Nov/18

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: 1.10.238
Fix Version/s: None

Type: Defect Priority: Major
Reporter: Mike Fikes Assignee: David Nolen
Resolution: Unresolved Votes: 0
Labels: None

Attachments: Text File CLJS-2802-2.patch     Text File CLJS-2802.patch    
Patch: Code and Test

 Description   

Like CLJ-1872 but for ClojureScript. (Note that CLJ-1872 is vetted, targeting Clojure 1.10.)

ClojureScript 1.10.339
cljs.user=> (empty? (transient []))
...
Error: [object Object] is not ISeqable
...
cljs.user=> (empty? (transient {}))
...
Error: [object Object] is not ISeqable
...
cljs.user=> (empty? (transient #{}))
...
Error: [object Object] is not ISeqable
...
cljs.user=>


 Comments   
Comment by Mike Fikes [ 03/Jul/18 8:24 PM ]

Adds an additional check for ITransientCollection in empty? implementation and delegates to count, which should be O(1).

It may be worth waiting to see if CLJ-1872 actually ships in Clojure before applying. (This would also afford an opportunity to make the docstring match Clojure's.)

Comment by Mike Fikes [ 24/Nov/18 8:32 PM ]

CLJS-2802-2.patch rebaselines





[CLJS-2972] Terrible error message if I try to use :refer :all Created: 14/Nov/18  Updated: 05/Dec/18

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: 1.10.238
Fix Version/s: None

Type: Enhancement Priority: Major
Reporter: Braden Shepherdson Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None


 Description   

I had .cljc files that worked fine in JVM Clojure, but in ClojureScript I was getting this error:

---- Could not Analyze src/cljc/zm/ops1OP.cljc line:1 column:1 ----

Don't know how to create ISeq from: clojure.lang.Keyword

1 (ns zm.ops1OP
^--- Don't know how to create ISeq from: clojure.lang.Keyword
2 "1OP operations"
3 #?(:cljs (:require-macros [zm.util :refer [v4-5]]))
4 (:require [zm.memory :refer :all]

---- Analysis Error : Please see src/cljc/zm/ops1OP.cljc ----

The problem is the :refer :all, and the error message makes sense in hindsight, but CLJS could do much better at pointing out this mistake.



 Comments   
Comment by Mike Fikes [ 05/Dec/18 6:58 PM ]

Here is how things currently look if you first load the core specs and then use the work from CLJS-2913:

cljs.user=> (require '[cljs.core.specs.alpha])
nil
cljs.user=> (require '[clojure.set :refer :all])
Syntax error macroexpanding cljs.core/require at (<cljs repl>:1:1).
:all - failed: coll? at: [:libspec :spec :lib+opts :options :refer] spec: :cljs.core.specs.alpha/refer
[clojure.set :refer :all] - failed: simple-symbol? at: [:libspec :spec :lib :sym] spec: :cljs.core.specs.alpha/lib
[clojure.set :refer :all] - failed: string? at: [:libspec :spec :lib :str] spec: :cljs.core.specs.alpha/lib
(quote [clojure.set :refer :all]) - failed: #{:verbose :reload :reload-all} at: [:flag]
cljs.user=>




[CLJS-3026] read-string does not read @ as deref Created: 26/Dec/18  Updated: 02/Jan/19  Resolved: 01/Jan/19

Status: Closed
Project: ClojureScript
Component/s: None
Affects Version/s: 1.10.238
Fix Version/s: None

Type: Defect Priority: Major
Reporter: Timothy Pratley Assignee: Unassigned
Resolution: Completed Votes: 0
Labels: None
Environment:

All



 Description   

ClojureScript's read-string rejects the @ character

Given:

(require '[cljs.reader :as r])
(r/read-string "@a")

Expected:

=> (deref a)

Actual:

Throws an exception: "Invalid character: @ found while reading symbol."

Clojure reads @ as deref. Homoiconicity is good.

People currently use tools.reader to avoid this (example: https://github.com/viebel/klipse-clj/commit/10a83a168ff122d6f80a5ba666782ae7610d931c#diff-2b0b7c3627b20951e80fc1d96080b7a9R175).



 Comments   
Comment by Thomas Heller [ 26/Dec/18 12:18 PM ]

@ is not part of the EDN reader and cljs.reader is a pure EDN reader, clojure.edn/read-string also does not support @. If you want to read CLJS source with deref support you need to use cljs.tools.reader directly.

Comment by David Nolen [ 01/Jan/19 11:41 AM ]

As stated, cljs.reader is an EDN reader. And in fact relies on tools.reader

Comment by Timothy Pratley [ 02/Jan/19 10:25 AM ]

Taking a look at the broader situation;

When called in Clojure:
clojure.core/read-string: Dangerous on external strings! Can eval.
clojure.edn/read-string: Data only.

When called in ClojureScript:
clojure.core/read-string: Data only.
clojure.edn/read-string: Does not exist

This is a confusing asymmetry.

One result of this is that when I try to create libraries that work with both Clojure and ClojureScript I need to use reader conditions to cater to these different behaviors. An example of this is the humble value reader, and another is the humble code reader. I certainly read data more than I read code from ClojureScript, though as it happens I do also read code occasionally as I love embedded ClojureScript REPLs for blogging and teaching websites (PowerTurtle). I say this only to explain the contexts in which I run into this asymmetry.

I think it would be a compatibility improvement to follow the existing Clojure API for edn/read-string. I also think core/read-string being compatible makes sense. The edn/read-string case is far more common and I consider to be the more important of the two.

Would you entertain the notion of providing an edn/read-string?

Comment by David Nolen [ 02/Jan/19 3:38 PM ]

Note the asymmetry as far as I can tell was always intentional, since bootstrapping was never a high priority. Also we should be clear that ClojureScript will never have a read-string exactly like Clojure's not only because it's full of things that are specific to Clojure on the JVM, but because advanced compilation munges names.

Providing a `cljs.edn/read-string` which simply delegates to `cljs.reader/read-string` is fine by me. But we should open another minor enhancement ticket for that.





[CLJS-2792] CraftyJS NPM dependency cannot be imported Created: 25/Jun/18  Updated: 22/Jan/19

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: 1.10.238
Fix Version/s: None

Type: Defect Priority: Major
Reporter: Marty Glaubitz Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: clojurescript, npm-deps
Environment:

Operation System: Windows 10
Leiningen Version: Leiningen 2.8.1
Java Version: Java 1.8.0_60 Java HotSpot(TM) 64-Bit Server VM
ClojureScript Version: 1.10.238



 Description   

I'm using ClojureScript with Figwheel and trying to use CraftyJs in ClojureScript.
This is my project.clj

(defproject my_project "0.1.0-SNAPSHOT"
:description "FIXME: write this!"
:url "http://example.com/FIXME"
:license {:name "Eclipse Public License"
:url "http://www.eclipse.org/legal/epl-v10.html"}

:min-lein-version "2.7.1"

:dependencies [[org.clojure/clojure "1.9.0"]
[org.clojure/clojurescript "1.10.238"]
[org.clojure/core.async "0.4.474"]]

:plugins [[lein-figwheel "0.5.16"]
[lein-cljsbuild "1.1.7" :exclusions [[org.clojure/clojure]]]]

:source-paths ["src"]

:cljsbuild {:builds
[{:id "dev"
:source-paths ["src"]

;; The presence of a :figwheel configuration here
;; will cause figwheel to inject the figwheel client
;; into your build
:figwheel {:on-jsload "my_project.core/on-js-reload"
;; :open-urls will pop open your application
;; in the default browser once Figwheel has
;; started and compiled your application.
;; Comment this out once it no longer serves you.
:open-urls ["http://localhost:3449/index.html"]}

:compiler {:main my_project.core
:asset-path "js/compiled/out"
:install-deps true
:npm-deps {:craftyjs "0.8.0"}
:output-to "resources/public/js/compiled/my_project.js"
:output-dir "resources/public/js/compiled/out"
:source-map-timestamp true
;; To console.log CLJS data-structures make sure you enable devtools in Chrome
;; https://github.com/binaryage/cljs-devtools
:preloads [devtools.preload]}}
;; This next build is a compressed minified build for
;; production. You can build this with:
;; lein cljsbuild once min
{:id "min"
:source-paths ["src"]
:compiler {:output-to "resources/public/js/compiled/my_project.js"
:main my_project.core
:optimizations :advanced
:pretty-print false}}]}

:figwheel {;; :http-server-root "public" ;; default and assumes "resources" ;; :server-port 3449 ;; default ;; :server-ip "127.0.0.1" :css-dirs ["resources/public/css"] ;; watch and update CSS ;; Start an nREPL server into the running figwheel process ;; :nrepl-port 7888 ;; Server Ring Handler (optional) ;; if you want to embed a ring handler into the figwheel http-kit ;; server, this is for simple ring servers, if this ;; doesn't work for you just run your own server :) (see lein-ring) ;; :ring-handler hello_world.server/handler ;; To be able to open files in your editor from the heads up display ;; you will need to put a script on your path. ;; that script will have to take a file path and a line number ;; ie. in ~/bin/myfile-opener ;; #! /bin/sh ;; emacsclient -n +$2 $1 ;; ;; :open-file-command "myfile-opener" ;; if you are using emacsclient you can just use ;; :open-file-command "emacsclient" ;; if you want to disable the REPL ;; :repl false ;; to configure a different figwheel logfile path ;; :server-logfile "tmp/logs/figwheel-logfile.log" ;; to pipe all the output to the repl ;; :server-logfile false }

;; Setting up nREPL for Figwheel and ClojureScript dev
;; Please see:
;; https://github.com/bhauman/lein-figwheel/wiki/Using-the-Figwheel-REPL-within-NRepl
:profiles {:dev {:dependencies [[binaryage/devtools "0.9.9"]
[figwheel-sidecar "0.5.16"]
[cider/piggieback "0.3.1"]]
;; need to add dev source path here to get user.clj loaded
:source-paths ["src" "dev"]
;; for CIDER
;; :plugins [[cider/cider-nrepl "0.12.0"]]
:repl-options {:nrepl-middleware [cider.piggieback/wrap-cljs-repl]}
;; need to add the compliled assets to the :clean-targets
:clean-targets ^{:protect false} ["resources/public/js/compiled"
:target-path]}})

However when running lein figwheel i see following in the console:

Compiling build :dev to "resources/public/js/compiled/my_project.js" from ["src"]...
[eval]:85
!id.startsWith(goog;
^^^^

SyntaxError: missing ) after argument list
at createScript (vm.js:74:10)
at Object.runInThisContext (vm.js:116:10)
at Object.<anonymous> ([eval]-wrapper:6:22)
at Module._compile (module.js:624:30)
at evalScript (bootstrap_node.js:480:27)
at startup (bootstrap_node.js:177:9)
at bootstrap_node.js:626:3

Successfully compiled build :dev to "resources/public/js/compiled/my_project.js" in 19.529 seconds.
and i can't import the library from my ClojureScript, i also see this:

Uncaught Error: Undefined nameToPath for craftyjs
at visitNode (base.js:1357)
at Object.goog.writeScripts_ (base.js:1369)
at Object.goog.require [as require_figwheel_backup_] (base.js:706)
at index.html:14
I already tried to manually delete the compiled JS output folder



 Comments   
Comment by Mike Fikes [ 30/Jun/18 7:05 PM ]

Hey Marty,

I think you can't directly use CraftyJS as an NPM dependency with ClojureScript. If you look on the CraftyJS website it shows additionally using Browserify.

Here is what happens if you try to use it as an NPM dep using minimal tooling:

deps.edn
{:deps {org.clojure/clojurescript {:mvn/version "1.10.339"}}}
compiler-opts.edn
{:npm-deps {:craftyjs "0.8.0"}
 :install-deps true}
$ clj -m cljs.main -co compiler-opts.edn -r
ClojureScript 1.10.339
cljs.user=> (require 'craftyjs)
events.js:183
      throw er; // Unhandled 'error' event
      ^

Error: Can't resolve 'fs' in '/Users/mfikes/Desktop/CLJS-2792-npm-deps/node_modules/craftyjs/src/graphics'
    at onError (/Users/mfikes/Desktop/CLJS-2792-npm-deps/node_modules/enhanced-resolve/lib/Resolver.js:61:15)
    at loggingCallbackWrapper (/Users/mfikes/Desktop/CLJS-2792-npm-deps/node_modules/enhanced-resolve/lib/createInnerCallback.js:31:19)
    at runAfter (/Users/mfikes/Desktop/CLJS-2792-npm-deps/node_modules/enhanced-resolve/lib/Resolver.js:158:4)
    at innerCallback (/Users/mfikes/Desktop/CLJS-2792-npm-deps/node_modules/enhanced-resolve/lib/Resolver.js:146:3)
    at loggingCallbackWrapper (/Users/mfikes/Desktop/CLJS-2792-npm-deps/node_modules/enhanced-resolve/lib/createInnerCallback.js:31:19)
    at next (/Users/mfikes/Desktop/CLJS-2792-npm-deps/node_modules/tapable/lib/Tapable.js:252:11)
    at innerCallback (/Users/mfikes/Desktop/CLJS-2792-npm-deps/node_modules/enhanced-resolve/lib/Resolver.js:144:11)
    at loggingCallbackWrapper (/Users/mfikes/Desktop/CLJS-2792-npm-deps/node_modules/enhanced-resolve/lib/createInnerCallback.js:31:19)
    at next (/Users/mfikes/Desktop/CLJS-2792-npm-deps/node_modules/tapable/lib/Tapable.js:249:35)
    at resolver.doResolve.createInnerCallback (/Users/mfikes/Desktop/CLJS-2792-npm-deps/node_modules/enhanced-resolve/lib/DescriptionFilePlugin.js:44:6)

Error: goog.require could not find: craftyjs
	 (goog/base.js:711:20)
	 require (clojure/browser/repl.cljs:226:33)
cljs.user=>

If you look at the CraftyJS code, it has a require('fs') call (which Browserify evidently helps sidestep.)

But, you can easy use CraftyJS as a foreign lib. To do so, set your compiler options instead to be:

compiler-opts.edn
{:foreign-libs [{:file "https://github.com/craftyjs/Crafty/releases/download/0.8.0/crafty.js"
                 :provides ["craftyjs"]}]}

Then, you can drive CraftyJS right from the REPL:

$ clj -m cljs.main -co compiler-opts.edn -r
ClojureScript 1.10.339
cljs.user=> (set! (.-innerHTML (.getElementById js/document "app")) "")
""
cljs.user=> (require 'craftyjs)

cljs.user=> (.init js/Crafty)
#object[Crafty]
cljs.user=> (def player (-> js/Crafty
(.e "2D, Canvas, Color, Fourway")
(.attr #js {:x 100 :y 100 :w 50 :h 50})
(.color "blue")
(.fourway 3)))
#'cljs.user/player
cljs.user=>

After the above, you can control the box using your arrow keys.

Comment by Marty Glaubitz [ 01/Jul/18 9:58 AM ]

Thanks for the tip! But are you sure that

:file "https://github.com/craftyjs/Crafty/releases/download/0.8.0/crafty.js"

is supposed to work? On my windows machine i can only pass a local file path there...

Comment by Mike Fikes [ 01/Jul/18 1:55 PM ]

Hi Marty. Yes :file can be a URL. See https://clojurescript.org/reference/compiler-options#foreign-libs

Comment by Timothy Pratley [ 22/Jan/19 4:45 PM ]

Is this something that could be supported in the future?

Doing `npm install craftyjs --save` creates node_modules/craftyjs/src/crafty.js which is suitable for being used as the foreign-lib (its the same as the file at the end of the url). So it seems in principle that it would be convenient to be able to say "Get me <x> from node, and treat dist/y as a foreign-lib.

Which makes me wonder what :npm-deps currently does... presumably it is using the source of the package rather than the dist. That makes sense to me for things that don't use browserify (or intermediary build tools). But there are useful packages that do use browserify and these leave us to relying on a URL to a file or some manual steps to get the package and build it first. Would it be possible to specify a dependency that should be fetched, built and use a dist file instead of src? The benefit would be that we could use both styles of npm dependencies via the same mechanism.

It might need to have a different name like :npm-libs because I think it would need more than just a version... ie something like :npm-libs {"asciidoctor.js" {:version "1.5.9", :lib "dist/browser/asciidoctor.js"}}

I arrived at this thread trying to use asciidoctor.js which uses Browserify to build node_modules/asciidoctor.js/dist/browser/asciidoctor.js. The asciidoctor.js package is interesting because it targets both NodeJS and the browser, producing two output files [which also interestingly still require other stuff, but the browser doesn't require things like `fs`].





[CLJS-3040] :foreign-libs generates files with empty exports due to namespace var shadowing Created: 25/Jan/19  Updated: 25/Jan/19

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: 1.10.238
Fix Version/s: None

Type: Defect Priority: Major
Reporter: Georgi Danov Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Environment:

OS X



 Description   

having simple file like this

export const simpleString = "abcdefg";

then importing it in :foreign-libs like this

{:file "generated/test.js"
:provides ["testNs"]
:module-type :es6}

produces file that exports nothing and the namespace is empty map. The reason seems to be that the namespace var is declared second time and gets shadowed. The generated file looks like this:

goog.provide("module$Users$gdanov$work$playground$trading_cockpit$generated$test");
var module$Users$gdanov$work$playground$trading_cockpit$generated$test={"default":{}};module$Users$gdanov$work$playground$trading_cockpit$generated$test["default"].simpleString="abcdefg"

the only option that is not vanilla in the clojurescript compiler config is this

:package-json-resolution :nodejs
:target :nodejs

optimizations set to :none






[CLJS-2633] Regression on scoped npm-modules Created: 08/Mar/18  Updated: 17/Sep/18

Status: In Progress
Project: ClojureScript
Component/s: None
Affects Version/s: 1.10.238
Fix Version/s: None

Type: Defect Priority: Major
Reporter: Aleš Roubíček Assignee: Aleš Roubíček
Resolution: Unresolved Votes: 3
Labels: js-modules

Attachments: Zip Archive string-requires-npm-deps.zip    
Approval: Vetted

 Description   

I have regression in npm-deps resolution in 1.10.x for material-components-web. For sub-dependencies it doesn't resolve the module path correctly. When I require eg. @material/snackbar it fails with Uncaught Error: Undefined nameToPath for module$$material$base$component.

Steps to reproduce:

yarn add "@cljs-oss/module-deps" "@material/snackbar"

cat <<EOF > deps.edn
{:deps {org.clojure/clojurescript {:mvn/version "1.10.145"}}}
EOF

clj -m cljs.main -d out -e "(require '[\"@material/snackbar\"])"

Resolution worked in 1.9.946



 Comments   
Comment by David Nolen [ 08/Mar/18 12:31 PM ]

This ticket just needs more information. A good first step in this report would be a git bisect. Then someone needs to determine wether this is because of ClojureScript or Google Closure. If the later there's not much we can do.

Comment by Aleš Roubíček [ 09/Mar/18 12:08 AM ]

I can reproduce the regression even on 1.10.63, to narrow the window. I'll prepare backwards compatible repro and bisect after that.

Comment by Aleš Roubíček [ 09/Mar/18 1:23 AM ]

Bisected it and it was introduced in #CLJS-2389 (GCC update)

Comment by Aleš Roubíček [ 09/Mar/18 6:51 AM ]

Code for reproduction

Comment by Aleš Roubíček [ 09/Mar/18 6:55 AM ]

When head -2 out/node_modules/@material/snackbar/index.js ends with goog.require("module$$material$base$index"); it is the broken case.

Comment by David Nolen [ 11/Mar/18 2:31 PM ]

I can reproduce and see that the dependency index file `cljs_deps.js` does not look right, so not surprised it's not working.

Comment by David Nolen [ 11/Mar/18 3:13 PM ]

Digging in further this may be a Closure issue and we'll have to wait for an upstream fix.

Comment by David Nolen [ 11/Mar/18 5:58 PM ]

This is a Closure Compiler issue. We need to submit a patch and then make the necessary changes for the next Closure release, this change https://github.com/swannodette/closure-compiler/commit/58012d3f1068aa588a47dc34ec6f39413aa59e62 fixes the module name issue for me.

Comment by Aleš Roubíček [ 12/Mar/18 2:09 AM ]

Excellent, thank you David.

Comment by David Nolen [ 12/Mar/18 9:31 AM ]

PR Closure Compiler https://github.com/google/closure-compiler/pull/2847

Comment by David Nolen [ 24/Mar/18 1:12 PM ]

Can we get a non-trivial expression added to this ticket that should work after the require?

Comment by David Nolen [ 25/Mar/18 3:56 AM ]

I figured out how to test this - it does in fact seemed resolved with master + my Closure Compiler PR.

Comment by Aleš Roubíček [ 25/Mar/18 6:32 AM ]

Sorry, I didn't responded earlier, I had Code Retreat yesterday. It is DOM component, so the non-trivial example needs to run in browser REPL with modified index.html. I think, if emitted goog.require is correct, everything else will work fine. Thank you very much for the fix. I hope your GCC PR will be accepted soon. 1.10 looks very solid and fast.

Comment by David Nolen [ 25/Mar/18 6:46 AM ]

The Closure Compiler PR now has a test case. It might need some small tweaks after it gets reviewed but hopefully this fix can make it into the May release at the latest.

Comment by Thomas Mattacchione [ 21/Jul/18 10:47 AM ]

It seems that the PR to google closure has been reviewed https://github.com/google/closure-compiler/pull/2847

Comment by Aleš Roubíček [ 17/Sep/18 10:24 AM ]

It seems that it works in latest cljs (1.10.339).





[CLJS-3052] "Differences-from-Clojure" should mention #queue Created: 16/Feb/19  Updated: 20/Mar/19

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: 1.10.238
Fix Version/s: None

Type: Enhancement Priority: Major
Reporter: Phill Wolf Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: docs, documentation


 Description   

ClojureScript's #queue is described at https://cljs.github.io/api/syntax/queue-literal, but unlike most stuff in ClojureScript it does not work in Clojure:

user> #queue [1]
Syntax error reading source at (REPL:43:17).
No reader function for tag queue

This would be a difference from Clojure, but I do not see #queue on ClojureScript's "Differences-from-Clojure" page (https://clojurescript.org/about/differences). The page has a section on the Reader, where #queue would not be out of place.

P.S. This enhancement was inspired by an exchange on the clojurians Slack in which "alexmiller" answered a message from "john" about #queue.



 Comments   
Comment by Mike Fikes [ 20/Mar/19 6:43 AM ]

Hey Phil, you can add issue to the site repo https://github.com/clojure/clojurescript-site/issues

Or, if a small change is imagined, it could just be submitted directly to the site. See https://clojurescript.org/community/contributing_site#minor





[CLJS-3032] Destructuring with & fails with defn in self-hosted eval Created: 04/Jan/19  Updated: 20/Mar/19  Resolved: 20/Mar/19

Status: Closed
Project: ClojureScript
Component/s: None
Affects Version/s: 1.10.238
Fix Version/s: None

Type: Defect Priority: Major
Reporter: Richard Davies Assignee: Unassigned
Resolution: Declined Votes: 0
Labels: bootstrap, compiler
Environment:

Windows Chrome (71.0.3578.98 - latest)



 Description   
(cljs.js/eval-str
  (cljs.js/empty-state)
  "(ns test.ns) (defn f [& args])"
  nil
  {:eval cljs.js/js-eval :context :expr}
  println)

Prints {:ns test.ns, :value nil}

:value should be the function instead of nil

(Destructuring with & works in fn or let forms)



 Comments   
Comment by Mike Fikes [ 06/Jan/19 9:31 AM ]

Hey Richard. This is actually not specific to self-hosted: Not all def forms return their inits, and this is the case for a variadic fn definition.

You can see this if you, say write some code that looks like

(def x (defn f [& args]))

and then attempt to use x (you will see that it is nil when you compile the code for actual use outside of a REPL).

You can also see this readily at a conventional REPL if you disable :def-emits-var (https://clojurescript.org/reference/repl-options#def-emits-var)

$ clj -Sdeps '{:deps {org.clojure/clojurescript {:mvn/version "1.10.439"}}}' -m cljs.main -co '{:def-emits-var false}' -r
ClojureScript 1.10.439
cljs.user=> (defn f [& args] 7)
nil
cljs.user=> (f 1 2 3)
7

Note that, in the above the defn form returns nil, but still has a side effect in the current namespace.

Alternatively, in the self-hosted example you gave, if you enable :def-emits-var you will get the var back:

cljs.user=> (cljs.js/eval-str
  (cljs.js/empty-state)
  "(ns test.ns) (defn f [& args])"
  nil
  {:eval cljs.js/js-eval :context :expr :def-emits-var true}
  println)
{:ns test.ns, :value #'test.ns/f}
nil
Comment by Mike Fikes [ 20/Mar/19 6:45 AM ]

Closing as not an issue.





[CLJS-3070] Bad error message for deftype with method with no parameters Created: 06/Apr/19  Updated: 06/Apr/19

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: 1.10.238
Fix Version/s: None

Type: Defect Priority: Major
Reporter: Robert Nikander Assignee: Unassigned
Resolution: Unresolved Votes: 1
Labels: None


 Description   

Example:

(deftype Foo [a b]
  Object
  (bar [] 123))

It should give the error pointing to line 3, with a message like "Methods in a deftype require at least one argument". Instead it gives a massive stacktrace, with a NullPointerException, and points to line 1.

It was hard to find the line of the error, but it was buried in the stack trace. Ideally that would also be easier to see.






[CLJS-2641] cljs.spec.alpha/fdef with s/* is broken Created: 09/Mar/18  Updated: 11/Mar/18  Resolved: 11/Mar/18

Status: Closed
Project: ClojureScript
Component/s: None
Affects Version/s: 1.10.238
Fix Version/s: None

Type: Defect Priority: Critical
Reporter: Miikka Koskinen Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: spec
Environment:

1.10.145



 Description   

In ClojureScript 1.10.145, the code below exceeds the call stack on the first call to foo. In ClojureScript 1.9.946 it works as expected (throws a spec exception on the second call to foo).

(ns foo.spec-instrument-test
  (:require [cljs.spec.alpha :as s]
            [cljs.spec.test.alpha :as stest]))

(enable-console-print!)

(defn foo [& args] (prn :got args))
(s/fdef foo :args (s/cat :args (s/* int?)))

(stest/instrument)
(foo 1 2 3)
(foo 1 :hello)
RangeError: Maximum call stack size exceeded
    at cljs.core.next (/Users/miikka/mess/2018-10/foo/out/main.js:526:476)
    at cljs.spec.alpha.deriv (/Users/miikka/mess/2018-10/foo/out/main.js:3698:381)
    at cljs.spec.alpha.re_conform (/Users/miikka/mess/2018-10/foo/out/main.js:3727:23)
    at undefined.cljs.spec.alpha.t_cljs$spec$alpha9065.cljs.spec.alpha.t_cljs$spec$alpha9065.cljs$spec$alpha$Spec$conform_STAR_$arity$2 (/Users/miikka/mess/2018-10/foo/out/main.js:3735:93)
    at cljs.spec.alpha.conform_STAR_ (/Users/miikka/mess/2018-10/foo/out/main.js:3433:117)
    at cljs.spec.alpha.conform (/Users/miikka/mess/2018-10/foo/out/main.js:3457:264)
    at /Users/miikka/mess/2018-10/foo/out/main.js:3806:485
    at Function.e [as cljs$core$IFn$_invoke$arity$variadic] (/Users/miikka/mess/2018-10/foo/out/main.js:3810:355)
    at Function.foo.spec_instrument_test.foo.cljs$lang$applyTo (/Users/miikka/mess/2018-10/foo/out/main.js:3850:316)
    at Function.cljs.core.apply.cljs$core$IFn$_invoke$arity$2 (/Users/miikka/mess/2018-10/foo/out/main.js:899:190)


 Comments   
Comment by Mike Fikes [ 09/Mar/18 6:56 AM ]

I got a stack overflow with the (foo 1 2 3) form.

"deps.edn"
{:deps {org.clojure/clojurescript {:mvn/version "1.10.145"}
        org.clojure/test.check {:mvn/version "0.10.0-alpha2"}}}
$ clj -Srepro -m cljs.main -re node
ClojureScript 1.10.145
cljs.user=> (require '[cljs.spec.alpha :as s]
 '[cljs.spec.test.alpha :as stest])
nil
cljs.user=> (defn foo [& args] (prn :got args))
#'cljs.user/foo
cljs.user=> (s/fdef foo :args (s/cat :args (s/* int?)))
cljs.user/foo
cljs.user=> (stest/instrument)
[cljs.user/foo]
cljs.user=> (foo 1 2 3)
repl:13
throw e__6325__auto__;
^

RangeError: Maximum call stack size exceeded
    at Array.join (native)
    at cljs$core$random_uuid (/private/var/folders/gx/nymj3l7x4zq3gxb97v2zwzb40000gn/T/out8891727756854429156473179676037935/cljs/core.js:36556:1625)
    at cljs$spec$alpha$rep_STAR_ (/private/var/folders/gx/nymj3l7x4zq3gxb97v2zwzb40000gn/T/out8891727756854429156473179676037935/cljs/spec/alpha.js:3707:457)
    at cljs$spec$alpha$deriv (/private/var/folders/gx/nymj3l7x4zq3gxb97v2zwzb40000gn/T/out8891727756854429156473179676037935/cljs/spec/alpha.js:4199:65)
    at cljs$spec$alpha$deriv (/private/var/folders/gx/nymj3l7x4zq3gxb97v2zwzb40000gn/T/out8891727756854429156473179676037935/cljs/spec/alpha.js:4189:214)
    at cljs$spec$alpha$re_conform (/private/var/folders/gx/nymj3l7x4zq3gxb97v2zwzb40000gn/T/out8891727756854429156473179676037935/cljs/spec/alpha.js:4600:48)
    at cljs.spec.alpha.regex_spec_impl.cljs.spec.alpha.t_cljs$spec$alpha3399.cljs$spec$alpha$Spec$conform_STAR_$arity$2 (/private/var/folders/gx/nymj3l7x4zq3gxb97v2zwzb40000gn/T/out8891727756854429156473179676037935/cljs/spec/alpha.js:4729:35)
    at cljs$spec$alpha$conform_STAR_ (/private/var/folders/gx/nymj3l7x4zq3gxb97v2zwzb40000gn/T/out8891727756854429156473179676037935/cljs/spec/alpha.js:36:13)
    at cljs$spec$alpha$conform (/private/var/folders/gx/nymj3l7x4zq3gxb97v2zwzb40000gn/T/out8891727756854429156473179676037935/cljs/spec/alpha.js:455:38)
    at /private/var/folders/gx/nymj3l7x4zq3gxb97v2zwzb40000gn/T/out8891727756854429156473179676037935/cljs/spec/test/alpha.js:129:41
cljs.user=>
Comment by Mike Fikes [ 09/Mar/18 7:34 AM ]

Git bisect result

93a841b6e1a043e4bac0fcae3d82cc0410f7f3fc is the first bad commit
commit 93a841b6e1a043e4bac0fcae3d82cc0410f7f3fc
Author: dnolen <dnolen@cognitect.com>
Date:   Fri Dec 22 15:09:57 2017 -0500

    CLJS-2397: Multi-arity function instrumentation fails with :static-fns true
    CLJS-2197: Calling instrumented var fails to check conformance

    The instrument var wrapper would copy over arity methods from the original
    fn but these would not be wrapped. Instead copy them over from a MetaFn
    that takes a validating fn.

:040000 040000 e29b8fb395420d5e56e608aa167a58ba2d90a032 f8019b280eaf16c2b1766cad2813c497d041ac04 M	src
Comment by Mike Fikes [ 09/Mar/18 2:54 PM ]

If foo is defined simply as (defn foo [a b c] (prn :got a b c)) then the original foo is called here

https://github.com/clojure/clojurescript/blob/92cbedd12cd39d6bc3083a269a10fba9daa7fc40/src/main/cljs/cljs/spec/test/alpha.cljs#L119

Instead with the variadic definition, that line jumps to calling the fn here,

https://github.com/clojure/clojurescript/blob/92cbedd12cd39d6bc3083a269a10fba9daa7fc40/src/main/cljs/cljs/spec/test/alpha.cljs#L107

which, in addition to causing the arguments to be conformed a second time, then the (apply f args) here

https://github.com/clojure/clojurescript/blob/92cbedd12cd39d6bc3083a269a10fba9daa7fc40/src/main/cljs/cljs/spec/test/alpha.cljs#L112

does the same, and we go into infinite recursion and stack overflow.

Comment by Mike Fikes [ 09/Mar/18 4:12 PM ]

As an experiment, inside the MetaFn replacing the (apply f args) with

(if-some [variadic (.-cljs$core$IFn$_invoke$arity$variadic f)]
  (variadic args)
  (apply f args))

works at the REPL for the ticket description but fails in advanced if you try to convert it to a test. This feels like a hack anyway, but it corroborates what is going on.

Comment by David Nolen [ 10/Mar/18 12:32 PM ]

The behavior is very unintuitive it appears to be due to JS dynamic binding.

Comment by A. R [ 11/Mar/18 5:23 AM ]

Just for the Jira records: CLJS-1663 is helpful in understanding this ticket.

Comment by David Nolen [ 11/Mar/18 1:11 PM ]

fixed https://github.com/clojure/clojurescript/commit/9dd4d41174079a568f27dcdf061568c985b2bd12





[CLJS-2740] (cljs.reader/register-tag-parser! ...) fails with version 1.10.x but ok with 1.9.671 Created: 20/Apr/18  Updated: 20/Apr/18  Resolved: 20/Apr/18

Status: Closed
Project: ClojureScript
Component/s: None
Affects Version/s: 1.10.238
Fix Version/s: None

Type: Defect Priority: Critical
Reporter: Denis Johnson Assignee: Unassigned
Resolution: Declined Votes: 0
Labels: bug

Attachments: File core.cljs    

 Description   

An existing project extends protocol IPrintWithWriter and registers tag via cljs.reader/register-tag-parser!
Round trips write to string via pr-str and read-string.

With deps < 1.9.x code as per core.cljs attached works as expected

[org.clojure/clojure "1.8.0"]
[org.clojure/clojurescript "1.9.671"]

With deps 1.10.x code as per core.cljs attached compiles but throws runtime error in our unit test "No reader function for tag utc."

[org.clojure/clojure "1.8.0"]
[org.clojure/clojurescript "1.10.238"]

This is preventing us from upgrading our projects to the 1.10.x series of clojurescript which in turn is blocking us from other dep updates like reagent 0.8.0 so we consider this critical.



 Comments   
Comment by Thomas Heller [ 20/Apr/18 1:46 AM ]

FYI register-tag-parser! expects a symbol, eg. (reader/register-tag-parser! 'utc ...).

Comment by Denis Johnson [ 20/Apr/18 3:00 AM ]

Nice catch Thomas ! it has been working like this for some years and certainly not obvious to me from cljs.reader/register-tag-parser! but my tests pass again with 1.10.238 so I'm happy. Thanks.

Comment by Mike Fikes [ 20/Apr/18 6:34 AM ]

Perhaps this is a consequence of the changes made for CLJS-1800. If so, we'd just need to determine if this constitutes a regression or if the older code in the ticket was simply working accidentally.

Comment by David Nolen [ 20/Apr/18 9:02 AM ]

This intentionally does not work anymore.





[CLJS-2843] [spec] s/explain of evaluated predicate yields :s/unknown Created: 21/Jul/18  Updated: 30/Oct/18  Resolved: 30/Oct/18

Status: Closed
Project: ClojureScript
Component/s: None
Affects Version/s: 1.10.238
Fix Version/s: None

Type: Defect Priority: Blocker
Reporter: Mike Fikes Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: spec


 Description   

Port CLJ-2068



 Comments   
Comment by David Nolen [ 30/Oct/18 2:09 PM ]

fixed https://github.com/clojure/clojurescript/commit/20ba8ef9415b46c18172a59cfe63ad16d2a35a3c





[CLJS-2794] with-meta should return identity when new meta is identical to prior Created: 27/Jun/18  Updated: 02/Dec/18  Resolved: 02/Dec/18

Status: Closed
Project: ClojureScript
Component/s: None
Affects Version/s: 1.10.238
Fix Version/s: None

Type: Enhancement Priority: Blocker
Reporter: Mike Fikes Assignee: Mike Fikes
Resolution: Completed Votes: 0
Labels: None

Attachments: Text File 0001-CLJS-2794-Return-identity-when-with-meta-is-called-w.patch     Text File 0001-CLJS-2794-Return-identity-when-with-meta-is-called-w.patch    
Patch: Code and Test
Approval: Accepted

 Description   

For persistent objects, if meta is identical, with-meta should return the identical object rather than replacing meta and returning a new object.

Like CLJ-2362 but for ClojureScript.

For example,

(let [coll ^:foo [1]] 
  (identical? coll (with-meta coll (meta coll))))

now evaluates to true in Clojure 1.10.0-alpha5.

I suspect this can be achieved by updating all of pertinent IWithMeta implementations in cljs.core to be like the following revision for PersistentVector

IWithMeta
  (-with-meta [coll new-meta]
    (if (identical? meta new-meta)
      coll
      (PersistentVector. new-meta cnt shift root tail __hash)))

while also dealing with the trick that vec and set employ when using with-meta to force a new object to be created (see CLJS-2442).



 Comments   
Comment by Erik Assum [ 24/Sep/18 3:59 PM ]

Following a discussion on clojurians #clojure-dev, the second part of this ticket can be skipped (i.e ensuring that a new vector/set is returned for vec and set, respectively

Comment by Mike Fikes [ 24/Sep/18 4:10 PM ]

In fact, with CLJ-2362 which is in the current Clojure 1.10 alphas, you can see that the concern I raised at the end of the description (the need to force a new object to be created) is no longer one in Clojure. Erik has submitted CLJ-2405, a candidate doc string change.

The nice thing for this ticket is that nothing special need be done to handle the places where vec and set call (with-meta coll nil). And, thus, when using these as coercion functions on meta-less collections of the right type, they effectively act like the identity function.

There are a couple of assertions in test-cljs-2442 regarding identical? that will need to be removed.

Comment by Mike Fikes [ 26/Sep/18 2:58 PM ]

0001-CLJS-2794-Return-identity-when-with-meta-is-called-w.patch patches CI and Canary tests.

Comment by Mike Fikes [ 03/Oct/18 11:11 AM ]

0001-CLJS-2794-Return-identity-when-with-meta-is-called-w.patch LGTM

Comment by Mike Fikes [ 29/Nov/18 7:00 PM ]

0001-CLJS-2794-Return-identity-when-with-meta-is-called-w.patch no longer applies

Comment by Erik Assum [ 30/Nov/18 3:23 PM ]

Rebased

Comment by Mike Fikes [ 30/Nov/18 4:36 PM ]

0001-CLJS-2794-Return-identity-when-with-meta-is-called-w.patch of 30/Nov/18 4:23 PM passes in CI

Comment by Mike Fikes [ 02/Dec/18 8:41 AM ]

fixed https://github.com/clojure/clojurescript/commit/2e5790b781f18a6dba2c92a1e39be07b38cb5209





Generated at Wed Apr 24 00:59:24 CDT 2019 using JIRA 4.4#649-r158309.