<< Back to previous view

[CLJS-1226] Add on-testing-complete hook Created: 27/Apr/15  Updated: 13/May/15  Resolved: 12/May/15

Status: Closed
Project: ClojureScript
Component/s: None
Affects Version/s: 0.0-3269
Fix Version/s: 0.0-3308

Type: Enhancement Priority: Minor
Reporter: Sebastian Bensusan Assignee: Unassigned
Resolution: Completed Votes: 0
Labels: cljs, enhancement, test

Attachments: Text File cljs_1226.patch     Text File cls_1226_v2.patch    
Patch: Code

 Description   

When a test runner runs async tests created with cljs.test/async there is no reliable way to return the control from the async code in the test suite to the test runner. This is problematic since the test script might need the tests results to proceed or terminate.

A function to be called after all tests are done is proposed: cljs.test/*on-testing-complete-fn* and it would take the test summary as its only argument

It can be set by the user by calling cljs.test/set-on-testing-complete! which should be callable from JS (^:export)

Notes:
In the patch, the function cljs.test/successful? also has the ^:export metadata to be called from JS test runners.
The code was tested manually with V8, Spidermonkey, Nashorn, SlimerJs, and PhantomJS but not with JavaScript Core.



 Comments   
Comment by Jenan Wise [ 01/May/15 2:40 PM ]

Rather than relying on a global, what about if run-tests took a callback? It would differentiate the API from clojure.test but they are already different due to the env arg and nil return value.

Comment by Sebastian Bensusan [ 01/May/15 2:59 PM ]

It is currently in a global to allow easy access from outside cljs (js runners). By having it to pass it to run-tests it would be harder to make reusable test runners from outside cljs/ Said runners would have to know both the ns to run (TBD in each project) and the callback (what we want to reuse, i.e. phantom.exit(0))

Comment by David Nolen [ 05/May/15 7:02 AM ]

Is there any particular reason to not invoke do-report with a suitable dispatch value instead of adding a new function here?

Comment by Sebastian Bensusan [ 05/May/15 7:29 AM ]

I'm not sure that I understand. I thought do-report and report were meant for printing out the summary as a report. This on-testing-complete hook should allow the caller to do whatever he/she wants after all tests are done. Do you want to allow the caller to specify how report works for some new dispatch value by adding:

(defmethod report [::default :on-testing-complete] [m]
..custom-code)

Comment by David Nolen [ 05/May/15 7:32 AM ]

The purpose of report is just side effects, printing is only one possibility. Note there are several testing events that aren't even really used by the standard reporter.

Comment by Leon Grapenthin [ 05/May/15 12:37 PM ]

IMHO if you want to run anything synchronously before after or between tests, you should use fixtures or if necessary compose the desired blocks yourself.

At least making the latter possible is why I made run-block and the block builder fns public.

You can easily run

(run-block (concat (run-tests-block 'a-ns-to-be-tested 'another-ns-to-be-test )
[(fn []
;; your continuation code here
)]))

This is a reliable way to pick up control after testing.

This patch only affects testing done via run-tests. E. g. on-testing-complete-fn won't be invoked if a user invoked test-ns and testing is complete. You could hack it into the block composer in test-ns, but still users composing blocks in the way mentioned above couldn't rely on it being invoked.

Comment by Sebastian Bensusan [ 11/May/15 10:25 AM ]

I followed Leon's suggestions and used run-block to make my own test-block. The only problem is that my continuation function doesn't get the summary/env as an argument. From what I understood I could pass env as an argument to run-tests but it would get cleared right before my continuation function. I don't know how to work around this yet.

If you think my solution is a correct use of the cljs.test API then this patch isn't needed. If you believe that run-tests should report on-testing-done I'd be happy to submit a new patch adding a new event to the report event system. Then I could get the summary/env from a custom report method as David suggested.

Comment by David Nolen [ 11/May/15 10:37 AM ]

I would not consider anything at the level of run-block part of the public API nor anything that anyone should be looking into. This stuff may change.

Please add a real reporting hook thanks.

Comment by Sebastian Bensusan [ 12/May/15 5:39 AM ]

Added :end-run-test event to cljs.test and a dummy event handler for it.

Comment by David Nolen [ 12/May/15 3:04 PM ]

fixed https://github.com/clojure/clojurescript/commit/31736450c6ca951c63bb685d744c11074fbfe323

Comment by Leon Grapenthin [ 12/May/15 4:09 PM ]

For API consistency this should also be in the blocks of `test-all-vars` in `test-ns`, `test-var` and `test-vars`.

Comment by David Nolen [ 12/May/15 4:24 PM ]

Happy to see a new ticket + patch that addresses the consistency issue.

Comment by Sebastian Bensusan [ 13/May/15 2:51 AM ]

Leon, I filled CLJS-1267 to address your point. Feel free to add any other API inconsistencies that :end-run-tests introduced.





[CLJS-1222] Sequence of a stateful transducer is producing the wrong answer Created: 24/Apr/15  Updated: 01/Jun/15

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: 0.0-3211
Fix Version/s: Next

Type: Defect Priority: Minor
Reporter: Lucas Cavalcanti Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: bug, cljs, collections
Environment:

OSX 10.10.3, java 1.8.0-ea-b124



 Description   

I'm producing more than one element on the 1-arity of the transducer, and sequence is only considering the last one.

Here is the transducer and the tests that fail for sequence:

(defn sliding-window [n]
  (fn [rf]
    (let [a #js []]
      (fn
        ([] (rf))
        ([result]
         (loop [] ;; Here I'm emitting more than one element
           (when (not-empty a)
             (rf result (vec (js->clj a)))
             (.shift a)
             (recur))))
        ([result input]
         (.push a input)
         (if (== n (.-length a))
           (let [v (vec (js->clj a))]
             (.shift a)
             (rf result v))
           result))))))

;;This test fails! =(
(deftest sliding-window-in-a-sequence
  (is (= [[5 4 3]
          [4 3 2]
          [3 2 1]
          [2 1]
          [1]]
         (sequence (sliding-window 3) [5 4 3 2 1])))

  (is (= [[2 1]
          [1]]
         (sequence (sliding-window 3) [2 1]))))


 Comments   
Comment by Lucas Cavalcanti [ 24/Apr/15 11:18 AM ]

I could make it work by recurring on the result.

([result]
  (loop [res result]
    (if (not-empty a)
      (let [v (vec (js->clj a))]
        (.shift a)
        (recur (rf res v)))
      res)))

even so it's weird that the previous version behaves differently on core.async and sequences in cljs and clj

Comment by David Nolen [ 26/Apr/15 4:04 AM ]

Please demonstrate the problem without core.async. Thanks.

Comment by Lucas Cavalcanti [ 26/Apr/15 7:32 PM ]

Hi,

the last test I posted on the ticket, fails in cljs, but not in clj:

;;This test fails! =(
(deftest sliding-window-in-a-sequence
  (is (= [[5 4 3]
          [4 3 2]
          [3 2 1]
          [2 1]
          [1]]
         (sequence (sliding-window 3) [5 4 3 2 1])))

  (is (= [[2 1]
          [1]]
         (sequence (sliding-window 3) [2 1]))))
Comment by David Nolen [ 27/Apr/15 7:43 AM ]

I've removed the core.async bits from the description to clarify the issue.

Comment by David Nolen [ 10/May/15 2:40 PM ]

The implementation of sliding-window above does not appear to be correct, it doesn't return the result. This ticket needs more information.

Comment by Lucas Cavalcanti [ 10/May/15 3:51 PM ]

As I said on http://dev.clojure.org/jira/browse/CLJS-1222?focusedCommentId=38620&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-38620

changing the 1-arity of the sliding-window to that fixes the transducer.

The point of this ticket now is that the behavior of the same (wrong) transducer in clj (both core.async and sequence) and cljs (core.async) is different than cljs sequence.





[CLJS-1186] add :postamble option to compiler Created: 02/Apr/15  Updated: 02/Apr/15

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

Type: Enhancement Priority: Minor
Reporter: Michael Bradley Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: cljs

Attachments: Text File cljs_1186.patch    

 Description   

Similar to CLJS-723:

1) :postamble's value will be a vector of paths
2) the compiled output is appended with the contents of the files at those paths
3) the generated source map points to the correct/adjusted line numbers






[CLJS-1073] :dynamic is misspelled as :dyanmic for *target* in core.cljs Created: 02/Mar/15  Updated: 02/Mar/15  Resolved: 02/Mar/15

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

Type: Defect Priority: Trivial
Reporter: Matthew Davidson Assignee: Unassigned
Resolution: Completed Votes: 0
Labels: cljs, dynamic, target
Environment:

N/A



 Description   

At the top of core.cljs, line 20:

(def ^{:dyanmic true
:jsdoc ["@define {string}"]}
target "default")

I'm not sure there are any consequences so far, since a search doesn't show target being rebound anywhere.



 Comments   
Comment by David Nolen [ 02/Mar/15 2:37 PM ]

thanks https://github.com/clojure/clojurescript/commit/8785fa9c9ff38c0fcebc32757c077070397018b7





[CLJS-1072] Calling .hasOwnProperty("source") in Clojurescript's string/replace will break with ES6 Created: 01/Mar/15  Updated: 02/Mar/15  Resolved: 02/Mar/15

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

Type: Defect Priority: Major
Reporter: Matthew Davidson Assignee: Unassigned
Resolution: Completed Votes: 1
Labels: bug, cljs, es6, replace, string
Environment:

Firefox Developer Edition
Mac OS X 10.10.1
Clojurescript 0.0-2913 (but I checked, and it's still present in current master branch)



 Description   

The "replace" function in string.cljs identifies RegExp objects by calling .hasOwnProperty to check for the "source" property. If true, then it's a regex. However, in ES6, the "source" property will become part of the RegExp prototype and not the actual object, so .hasOwnProperty("source") will return false instead.

Documentation on the RegExp change is at http://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/RegExp/source under the "Specifications" section. The change hit Firefox two weeks ago, according to this bug report, https://bugzilla.mozilla.org/show_bug.cgi?id=1120169, so it will still be 2-3 months before it appears in the main release channel. But given that ES6 is aiming for a June release date, we should expect other browsers to show this error soon enough.

To fix the issue, the Javascript "in" operator would work, if there's a way to compile cljs to use it. Otherwise, the next best thing might be to check to see if the "source" property is non-nil. Basically, the test:

(.hasOwnProperty match "source")

could become:

(.-source match)

It's not a major code change at all, but I'm happy to provide a patch and verify tests if you prefer.



 Comments   
Comment by Elliot Block [ 02/Mar/15 12:54 AM ]

Just to slightly summarize/reiterate, this bug means that `string/replace` is always broken if you pass it a RegExp as the `match` (under the new ES6 rules, already live in FF Dev Ed.)

This further breaks plenty of applications, like it immediately breaks the `secretary` router found in many Om apps.

Comment by David Nolen [ 02/Mar/15 7:46 AM ]

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





[CLJS-1036] cljs.closure/build does not find upstream dependencies when called from worker thread Created: 13/Feb/15  Updated: 20/Feb/15  Resolved: 20/Feb/15

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

Type: Defect Priority: Major
Reporter: Michael Griffiths Assignee: Unassigned
Resolution: Completed Votes: 1
Labels: cljs, closure, compiler

Attachments: Text File CLJS-1036--001.patch    

 Description   

Example stacktrace: https://www.refheap.com/97198 (context is using figwheel in a clojure REPL from CIDER)

Because cljs.closure/build calls the 0-arity form of get-upstream-deps, it is implicitly using the current thread's classloader to find the deps.cljs resources. It is then assoc'ing the result into opts, so the caller has no way of gathering the dependencies themselves and passing them in.



 Comments   
Comment by Michael Griffiths [ 13/Feb/15 1:40 PM ]

Patch CLJS-1036--001.patch, attached, uses merge instead of assoc to allow passing of the upstream dependency data via opts.

Comment by Michael Griffiths [ 13/Feb/15 1:45 PM ]

We could also allow passing of a :resources-classloader opt so callers don't have to gather the dependencies themselves, if you'd prefer a patch that does that.

Comment by Bruce Hauman [ 15/Feb/15 2:17 PM ]

This is a problem with calling cljs.closure/build inside nREPL in general when upstream deps are involved.

Comment by David Nolen [ 15/Feb/15 2:34 PM ]

I would like Chas Emerick to chime in on this thread before considering it.

Comment by Chas Emerick [ 16/Feb/15 9:02 AM ]

Could someone point me to a simple (sample?) project that uses upstream dependencies? I haven't used them yet, and don't have such a thing handy.

The proposed patch is confusing to me; if the problem is in resolving dependencies due to classloader state/configuration, how does it help to give opts the opportunity to clobber what get-upstream-deps returns? That is, doesn't this just move the problem downstream to who/whatever is calling build?

Comment by Michael Griffiths [ 16/Feb/15 10:10 AM ]

Chas: yes, the proposed patch simply moves the responsibility to the caller. I was under the assumption that changing how get-upstream-deps/build resolves the classloader by default would be too-breaking of a change, and had not even considered the fact that this might be a broader issue with nREPL itself.

Example usage of get-upstream-deps in the wild (that even mentions classloader issues): https://github.com/immutant/immutant-release/blob/ea538feb548bde86ebce20ec679da7a19b639259/integration-tests/apps/ring/basic-ring/src/basic_ring/core.clj#L51

Note that Weasel (at least) is currently gathering the upstream deps itself too: https://github.com/tomjakubowski/weasel/commit/5cd7009f584100f0d89fc7f00079458bb1f2c016

I'll set up an example project tonight if you like, but I think all you need is to add [cljsjs/react "0.12.2-5"] as a dependency to an existing cljs project and then require [cljsjs.react] in one of its namespaces.

Comment by Bruce Hauman [ 16/Feb/15 1:04 PM ]

Chas, David here is a very quick example:

If you do a

lein new om-mies hello-world
cd hello-world
lein repl
user> (require '[cljs.closure :as cc])
user> (cc/build "src" {})

Assuming lein repl started an nREPL repl. This will produce the error mentioned above. The problem is that om is utilizing the new deps.js facility to autmatically import cljsjs.react. get-upstream-deps depends on being run on the main thread.

https://github.com/clojure/clojurescript/blob/master/src/clj/cljs/closure.clj#L1116

A solution that fixes this in get-upstream-deps* would be preferable.

Is this simple solution to use the system classloader when not on the main thread:

(if (not= (.getName (Thread/currentThread)) "main")
  (java.lang.ClassLoader/getSystemClassLoader)
  (. (Thread/currentThread) (getContextClassLoader)))

To naive? My experience with Java threads and classloaders is minimal.

Or should we always use the (java.lang.ClassLoader/getSystemClassLoader) in this case?

Comment by Chas Emerick [ 17/Feb/15 3:35 PM ]

Using the system classloader isn't necessary. get-upstream-deps is currently using .findResources, not .getResources; the difference is that the former looks only for matching resources in the target classloader, while the latter first delegates to the parent classloader, and only looks locally if nothing is found there. So, just using .getResources instead will make all current usage work as expected, I think. e.g.

;; `lein repl` nREPL here
user=> (enumeration-seq (.getResources (. (Thread/currentThread) (getContextClassLoader))  "deps.cljs"))
(#<URL jar:file:/home/chas/.m2/repository/cljsjs/react/0.12.2-5/react-0.12.2-5.jar!/deps.cljs>)
user=> (enumeration-seq (.findResources (. (Thread/currentThread) (getContextClassLoader))  "deps.cljs"))
nil

There are some classloader edge cases that might motivate making get-upstream-deps perform a more comprehensive search, explicitly pinging all classloaders for matching resources. This is sometimes necessary for these sorts of scanning scenarios if e.g. a deps.cljs file is available via a parent classloader, which will therefore "shadow" other deps.cljs files in child classloaders. In that case, you need something like cemerick.pomegranate/resources.

Hope that helps.

Comment by David Nolen [ 17/Feb/15 3:46 PM ]

Chas's suggested fix has been committed to master. It works on the simple tests I've run but I'd like to hear more confirmation. Thanks everyone.

https://github.com/clojure/clojurescript/commit/79208f5bf15825a2ba2d0ce95aae6d2b71966494

Comment by David Nolen [ 20/Feb/15 4:36 PM ]

Closing this one. Chas's solution is the correct one.





[CLJS-996] .indexOf method(in javascript) returns wrong result when called with keyword array Created: 02/Feb/15  Updated: 02/Feb/15  Resolved: 02/Feb/15

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

Type: Defect Priority: Major
Reporter: sorrow17 Assignee: Unassigned
Resolution: Declined Votes: 0
Labels: bug, cljs
Environment:

Windows, clojurescript-2755



 Description   

The following expression should return "1":

(.indexOf (to-array [:a :b :c]) :b)

but actually the result is -1.
Note that this method call behaves normally with other type of array:

>(.indexOf (to-array ["a" "b" "c"]) "b")
>1

So I guess there might something wrong with the type Keyword.
Anyone have a look at this?



 Comments   
Comment by Francis Avila [ 02/Feb/15 8:18 AM ]

Array.prototype.indexOf uses strict equality (js === operator) to compare search item with array items. Keywords are Objects, and the same keyword-equal object may not be the same identical object. Non identical objects never compare strictly equal in js and there is nothing that can be done to change this.

Use something other than indexOf to find your item. You need to compare items with the cljs = function or with keyword-equal?

Comment by David Nolen [ 02/Feb/15 9:40 AM ]

This is not a bug.





[CLJS-994] print a warning when :externs file paths can't be found. Created: 30/Jan/15  Updated: 01/Jun/15

Status: Reopened
Project: ClojureScript
Component/s: None
Affects Version/s: 0.0-3269
Fix Version/s: Next

Type: Enhancement Priority: Major
Reporter: Crispin Wellington Assignee: David Nolen
Resolution: Unresolved Votes: 0
Labels: cljs, enhancement, errormsgs, patch,
Environment:

Linux 64bit

java version "1.7.0_65"
OpenJDK Runtime Environment (IcedTea 2.5.3) (7u71-2.5.3-0ubuntu0.14.04.1)
OpenJDK 64-Bit Server VM (build 24.65-b04, mixed mode)


Attachments: Text File clojurescript-extern-missing-warning.patch    
Patch: Code

 Description   

clojurescript silently ignores missing externs files possibly leading a developer to chase their tail.

Presently it can be very confusing using advanced compilation if you have made a mistake in the path name of one of your :externs files. This patch makes the compiler print a warning on stderr so you can quickly determine the cause of the broken advanced compilation output.

As a side effect, when doing a basic lein-cljsbuild a warning is always printed:

```
WARNING: js resource path closure-js/externs does not exist
```

This is because lein-cljsbuild quietly adds this extra path to your :externs listing without you knowing.



 Comments   
Comment by David Nolen [ 31/Jan/15 1:59 PM ]

You need to bind *out* to *err*, or just print to it directly a la cljs.util/debug-prn.

Comment by Crispin Wellington [ 31/Jan/15 7:30 PM ]

I did bind out to err. Check the patch.

Comment by David Nolen [ 01/Feb/15 12:30 PM ]

Crispin, oops sorry you are correct. Thanks.

Comment by David Nolen [ 13/Mar/15 7:33 AM ]

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

Comment by David Nolen [ 14/Mar/15 5:55 AM ]

The solution does not work for cljsbuild. It's unclear why there so much machinery in place over the approach taken for deps.clj.

Comment by David Nolen [ 15/Mar/15 10:37 AM ]

Stalled on this cljsbuild issue https://github.com/emezeske/lein-cljsbuild/issues/383

Comment by Crispin Wellington [ 23/Mar/15 2:50 AM ]

This lein-cljsbuild issue is what made me make it just a warning initially, and not a hard error like raising IllegalArgumentException does. Though I agree it should be a hard error. If we start with a warning, it enables the immediate problem for the developer to be resolved, and leaves a wart that the cljs-build project can then see that need fixing on their end. Then when that end is fixed it could be made a hard error. If cljsbuild is fixed fairly soon then all is well, but if it takes a long time, a warning might be a good first step.





[CLJS-974] Clean compile/build fails to resolve namespaces for cljs.test Created: 12/Jan/15  Updated: 13/Jan/15  Resolved: 13/Jan/15

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

Type: Defect Priority: Major
Reporter: Denis Johnson Assignee: Unassigned
Resolution: Declined Votes: 0
Labels: cljs, test
Environment:

Linux Ubuntu 14.04
Java 1.7.0_17 Java HotSpot(TM) 64-Bit Server VM
leiningen 2.5.1
Intellij 13.1.6 with latest cursive 0.1.43 plugin

:dependencies
[[org.clojure/clojure "1.6.0"]
[org.clojure/clojurescript "0.0-2665"]
[reagent "0.5.0-alpha"]
[alandipert/storage-atom "1.2.3"]
[com.andrewmcveigh/cljs-time "0.3.0"]]
:plugins [[lein-cljsbuild "1.0.3"]]


Attachments: File test_suite.cljs    

 Description   

Clean compile gives the following error for a valid namespace for runner/suite (see attachment).
Same namespace works fine using cemerick/clojurescript.test
NOTE 1: if compiled using "cljsbuild auto test" after giving failure, if you delete the test/test-suite.cljs the compile completes successfully, if then you revert the file it also recompiles successfully and tests run as expected.
NOTE 2: Happens all the time on my machine but other devs on Windows platform don't seem to get this issue. The only difference I can see is I use leiningen checkouts feature to point at our other local repos and these are project dependencies. I have tested with removing the checkouts folder with change in behaviour so I doubt it is related.

Deleting files generated by lein-cljsbuild.
Compiling ClojureScript.
Compiling "compiled/test.js" from ["src" "test"]...
Compiling "compiled/test.js" failed.
clojure.lang.ExceptionInfo: failed compiling file:test/test_suite.cljs
core.clj:4403 clojure.core/ex-info
compiler.clj:1039 cljs.compiler/compile-file
compiler.clj:1069 cljs.compiler/compile-root
closure.clj:358 cljs.closure/compile-dir
closure.clj:398 cljs.closure/eval3160[fn]
closure.clj:306 cljs.closure/eval3096[fn]
closure.clj:412 cljs.closure/eval3147[fn]
closure.clj:306 cljs.closure/eval3096[fn]
compiler.clj:44 cljsbuild.compiler.SourcePaths/fn
core.clj:2557 clojure.core/map[fn]
LazySeq.java:40 clojure.lang.LazySeq.sval
LazySeq.java:49 clojure.lang.LazySeq.seq
RT.java:484 clojure.lang.RT.seq
core.clj:133 clojure.core/seq
core.clj:624 clojure.core/apply
core.clj:2586 clojure.core/mapcat
RestFn.java:423 clojure.lang.RestFn.invoke
compiler.clj:44 cljsbuild.compiler/cljsbuild.compiler.SourcePaths
closure.clj:1018 cljs.closure/build
closure.clj:972 cljs.closure/build
compiler.clj:58 cljsbuild.compiler/compile-cljs[fn]
compiler.clj:57 cljsbuild.compiler/compile-cljs
compiler.clj:159 cljsbuild.compiler/run-compiler
form-init1706317005734214457.clj:1 user/eval3512[fn]
form-init1706317005734214457.clj:1 user/eval3512[fn]
LazySeq.java:40 clojure.lang.LazySeq.sval
LazySeq.java:49 clojure.lang.LazySeq.seq
RT.java:484 clojure.lang.RT.seq
core.clj:133 clojure.core/seq
core.clj:2855 clojure.core/dorun
core.clj:2871 clojure.core/doall
form-init1706317005734214457.clj:1 user/eval3512
Compiler.java:6703 clojure.lang.Compiler.eval
Compiler.java:6693 clojure.lang.Compiler.eval
Compiler.java:7130 clojure.lang.Compiler.load
Compiler.java:7086 clojure.lang.Compiler.loadFile
main.clj:274 clojure.main/load-script
main.clj:279 clojure.main/init-opt
main.clj:307 clojure.main/initialize
main.clj:342 clojure.main/null-opt
main.clj:420 clojure.main/main
RestFn.java:421 clojure.lang.RestFn.invoke
Var.java:383 clojure.lang.Var.invoke
AFn.java:156 clojure.lang.AFn.applyToHelper
Var.java:700 clojure.lang.Var.applyTo
main.java:37 clojure.main.main
Caused by: clojure.lang.ExceptionInfo: No such namespace: test.model.dimension-glossary-test at line 1 test/test_suite.cljs
core.clj:4403 clojure.core/ex-info
analyzer.clj:297 cljs.analyzer/error
analyzer.clj:294 cljs.analyzer/error
analyzer.clj:1095 cljs.analyzer/analyze-deps
analyzer.clj:1280 cljs.analyzer/eval1561[fn]
MultiFn.java:249 clojure.lang.MultiFn.invoke
analyzer.clj:1609 cljs.analyzer/analyze-seq
analyzer.clj:1696 cljs.analyzer/analyze[fn]
analyzer.clj:1689 cljs.analyzer/analyze
compiler.clj:948 cljs.compiler/compile-file*[fn]
compiler.clj:906 cljs.compiler/with-core-cljs
compiler.clj:927 cljs.compiler/compile-file*
compiler.clj:1033 cljs.compiler/compile-file



 Comments   
Comment by David Nolen [ 13/Jan/15 7:31 AM ]

Please report cljsbuild bugs with the cljsbuild project thanks.





[CLJS-973] cljs.test ignores some deftest names Created: 12/Jan/15  Updated: 15/Jan/15  Resolved: 15/Jan/15

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

Type: Defect Priority: Minor
Reporter: Denis Johnson Assignee: Unassigned
Resolution: Not Reproducible Votes: 0
Labels: cljs, test
Environment:

Linux Ubuntu 14.04
Java 1.7.0_17 Java HotSpot(TM) 64-Bit Server VM
leiningen 2.5.1

:dependencies
[[org.clojure/clojure "1.6.0"]
[org.clojure/clojurescript "0.0-2665"]
[reagent "0.5.0-alpha"]
[alandipert/storage-atom "1.2.3"]
[com.andrewmcveigh/cljs-time "0.3.0"]]
:plugins [[lein-cljsbuild "1.0.3"]]



 Description   

examples:

  • ignores: (deftest test:change-step-contiguous-forward> ....)
  • works: (deftest test:change-current-step ...) ignores: (deftest test-change-current-step ...)


 Comments   
Comment by David Nolen [ 15/Jan/15 1:26 AM ]
(deftest test:change-current-step: ...)
(deftest test:change-current-step@ ...)

Removed these two from ticket description these are not valid Clojure symbols see http://clojure.org/reader

Comment by David Nolen [ 15/Jan/15 1:37 AM ]

I tested the remaining names could not reproduce. Please only reopen this ticket if a full minimal case is provided.





[CLJS-967] "java.net.ConnectException: Connection refused" when running node repl Created: 07/Jan/15  Updated: 12/Feb/15  Resolved: 12/Feb/15

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

Type: Defect Priority: Major
Reporter: Brian Muhia Assignee: Unassigned
Resolution: Completed Votes: 0
Labels: cljs, errormsgs
Environment:

Processor: 1.33GHz Intel Atom, Ubuntu 12.04, OpenJDK 1.7, Clojure 1.6.0, ClojureScript 0.0-2665, nodejs v0.10.26


Attachments: Text File backtrace.txt    

 Description   

I used trampoline like so:

rlwrap lein trampoline run -m clojure.main scripts/repl.clj

run the script repl.clj with contents:

(require
  '[cljs.repl :as repl]
  '[cljs.repl.node :as node])

(repl/repl* (node/repl-env)
  {:output-dir "out"
   :optimizations :none
   :cache-analysis true                
   :source-map true})

Instead of getting a repl, I got the exception: Exception in thread "main" java.net.ConnectException: Connection refused, compiling/home/brian/projects/essence-cljs-redux/scripts/repl.clj:3:30)

The full stack trace is attached in backtrace.txt.



 Comments   
Comment by David Nolen [ 08/Jan/15 7:21 AM ]

The issue is that we use a 300ms timeout to connect to the Node.js process, we need to instead redirect the process out and wait for the Node.js REPL server start string.

Comment by David Nolen [ 12/Feb/15 7:22 AM ]

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





[CLJS-922] Warning message for non-dynamic vars is incomplete Created: 23/Dec/14  Updated: 06/Jan/15  Resolved: 06/Jan/15

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

Type: Defect Priority: Trivial
Reporter: Michael Griffiths Assignee: Unassigned
Resolution: Completed Votes: 0
Labels: analyzer, cljs

Attachments: Text File CLJS-922-001.patch     Text File CLJS-922-002.patch     PDF File Michael Griffiths Clojure CA.pdf    

 Description   

e.g.

user> (do 
        (cljs.analyzer/analyze nil '((ns dynamic-warning-test-ns)
                                     (def a nil)
                                     (binding [a nil] nil)))
        nil)
WARNING:  not declared ^:dynamic at line 4 
;; => nil

The name of the var is missing at the start of the warning message.



 Comments   
Comment by Michael Griffiths [ 23/Dec/14 3:58 PM ]

Patch attached. Evaluating the above form with patch applied now results in:

WARNING: dynamic-warning-test-ns/a not declared ^:dynamic at line 4

Maybe it would be fine to just use the name of the var rather than the namespace-qualified name - let me know if you want the patch updated.

Comment by David Nolen [ 24/Dec/14 7:52 AM ]

Patch looks good, have you submitted a CA? Thanks.

Comment by Mike Fikes [ 24/Dec/14 8:09 AM ]

I wonder if the fix for CLJS-921 will affect this patch. (I'm thinking that the patch relied on the :name meta containing the fully qualified name, but that with CLJS-921 the :ns would also need to be consulted—as is done in the doc printing impl.)

Comment by David Nolen [ 24/Dec/14 8:16 AM ]

The patch is at the level of the compiler not the runtime so it should be unaffected by CLJS-921.

Comment by Michael Griffiths [ 24/Dec/14 11:29 AM ]

Yeah, I signed an electronic CA the same day I submitted the patch - I'm not sure how often the list of contributors is updated on clojure.org but should be on there soon. Find attached regardless.

Thanks!

Comment by Michael Griffiths [ 05/Jan/15 5:17 AM ]

I'm now listed on http://clojure.org/contributing.

Comment by David Nolen [ 05/Jan/15 9:32 AM ]

The patch needs to be rebased to master.

Comment by Michael Griffiths [ 06/Jan/15 9:54 AM ]

Of course. Rebased patch attached.

Comment by David Nolen [ 06/Jan/15 1:41 PM ]

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





[CLJS-878] Missing preamble file causes unhelpful stack trace Created: 30/Oct/14  Updated: 02/Dec/14  Resolved: 31/Oct/14

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

Type: Defect Priority: Trivial
Reporter: Darrick Wiebe Assignee: Unassigned
Resolution: Duplicate Votes: 0
Labels: cljs, errormsgs


 Description   

I think it would be helpful to throw an exception with the missing file path rather than the current

java.lang.IllegalArgumentException: No implementation of method: :make-reader of protocol: #'clojure.java.io/IOFactory found for class: nil
.

Right now you need to work your way down about 10 lines into the stacktrace to find

cljs.closure$preamble_from_paths$fn__3097.invoke(closure.clj:526)
which is the only hint as to what has happened.



 Comments   
Comment by David Nolen [ 31/Oct/14 2:42 AM ]

This is a simple enhancement, a patch is welcome. Thanks.

Comment by David Nolen [ 31/Oct/14 2:44 AM ]

Actually this already appears fixed in master https://github.com/clojure/clojurescript/commit/9fd6bf5bd55421c3d5becacc5230ed661d6fb3c3

Comment by David Nolen [ 31/Oct/14 2:45 AM ]

See CLJS-869





[CLJS-819] cljs.reader cannot handle character classes beginning with slashes in regex literals Created: 20/Jun/14  Updated: 01/Jul/14  Resolved: 01/Jul/14

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

Type: Defect Priority: Critical
Reporter: Ziyang Hu Assignee: Unassigned
Resolution: Completed Votes: 0
Labels: bug, cljs, reader

Attachments: Text File cljs-819.patch    

 Description   

cljs.user> (cljs.reader/read-string "#\"\\s\"")
Compilation error: Error: Unexpected unicode escape \s



 Comments   
Comment by Ziyang Hu [ 20/Jun/14 10:03 AM ]

This in particular means that (cljs.reader/read-string (str [#"\s"])) won't work

Comment by Francis Avila [ 25/Jun/14 11:46 AM ]

Patch and test.

Comment by David Nolen [ 01/Jul/14 9:25 PM ]

fixed https://github.com/clojure/clojurescript/commit/32259c5ff3f86ea086ae3949403df80c2f518c7e





[CLJS-723] add :preamble option to compiler Created: 10/Dec/13  Updated: 17/Dec/13  Resolved: 17/Dec/13

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

Type: Enhancement Priority: Minor
Reporter: Travis Vachon Assignee: Unassigned
Resolution: Completed Votes: 0
Labels: cljs

Attachments: Text File cljs_723.patch    

 Description   

Per this thread:

https://groups.google.com/forum/#!searchin/clojurescript/preamble/clojurescript/rUIlLfcYZvE/Yskfh4znL_0J

1) :preamble 's value will be a vector of paths
2) the compiled output is prepended with the contents of the files at those paths
3) the generated source map points to the correct/adjusted line numbers

Additionally, when compiling for the :nodejs target the preamble contents will default to the hashbang we currently write in that situation.



 Comments   
Comment by Travis Vachon [ 11/Dec/13 4:59 PM ]

patch to add :preamble

I'm not confident this is the best way to do the source map stuff - any thoughts/suggestions would be very welcome

Comment by Michael Bradley [ 13/Dec/13 5:55 PM ]

Could the issue (and patch) be expanded to also support a :postamble option?

With both :preamble and :postamble options available, it would be easy to implement more sophisticated compiler-output wrappers, such as the one used by David Nolen's mori library (which I helped adapt from the Q javascript library).

See: https://github.com/swannodette/mori/blob/master/support/wrapper.js

Comment by David Nolen [ 14/Dec/13 2:37 PM ]

I'm fine with extending this to {:postamble}.

Comment by David Nolen [ 14/Dec/13 2:39 PM ]

fixed https://github.com/clojure/clojurescript/commit/454bcb70fbbd9e9feb20ada7b4043eab70dafea2

Comment by David Nolen [ 14/Dec/13 2:40 PM ]

Oops resolved wrong ticket

Comment by David Nolen [ 17/Dec/13 4:26 PM ]

fixed, https://github.com/clojure/clojurescript/commit/136bf46c656265a93dd15c40925f11edb34bd127.

If someone wants to open a postamble ticket and attach a patch go for it.





[CLJS-722] Support parse.com's Cloud Code environment in :nodejs builds Created: 09/Dec/13  Updated: 23/Jan/14  Resolved: 23/Jan/14

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

Type: Enhancement Priority: Minor
Reporter: Travis Vachon Assignee: Unassigned
Resolution: Completed Votes: 0
Labels: cljs

Attachments: Text File cljs_722.patch     Text File cljs_722v2.patch     Text File cljs_722v3.patch     Text File parse.patch    
Patch: Code

 Description   

parse.com's Cloud Code is very similar to node.js but expects no hashbang and doesn't provide util.js, so provide a compiler argument to elide the header and wrap the util.js require in a try...catch



 Comments   
Comment by David Nolen [ 10/Dec/13 9:21 AM ]

Please format the patch so it can be applied with git am. See http://github.com/clojure/clojurescript/wiki/Patches

Comment by Travis Vachon [ 10/Dec/13 9:47 AM ]

git am-able patch

Comment by Travis Vachon [ 10/Dec/13 9:47 AM ]

sorry about that! will update all the tickets I've filed recently as well

Comment by Travis Vachon [ 10/Dec/13 1:22 PM ]

so actually, I think a better solution to this will be to add support for :preamble as proposed here:

https://groups.google.com/forum/#!searchin/clojurescript/preamble/clojurescript/rUIlLfcYZvE/Yskfh4znL_0J

I'm imagining that the default preamble for the :nodejs target will be the hashbang

that will let us a) redefine the require function in our compiled output to squelch the util import and b) avoid writing the hashbang

Comment by David Nolen [ 11/Dec/13 10:52 AM ]

so is this ticket superseded by CLJS-723?

Comment by Travis Vachon [ 11/Dec/13 12:02 PM ]

yeah - if I can write arbitrary js at the beginning of my compiled file I don't need this patch. Can close.

Comment by Travis Vachon [ 12/Dec/13 8:22 AM ]

arg, it looks like I spoke too soon - redefining require in the cloud code env appears to be impossible. I spent a couple hours trying every scoping trick I could find - it looks like the only way to redefine require is by defining a function (assignment just doesn't seem to take) and that function is always hoisted to the very top, so there's no way to get a handle on the original require function. Parse's sandbox doesn't seem to have another way to reference require, either.

How would you feel about moving {{ (set! cljs.core/string-print (.-print (require "util"))) }} into a function node.js people can call rather than doing it when the module is loaded?

Comment by David Nolen [ 12/Dec/13 8:38 AM ]

Honestly I'd be happy to remove it altogether and let people just handle this themselves. Or allow people to disable it if they are using the nodejs target option.

Comment by Travis Vachon [ 12/Dec/13 10:07 AM ]

ok great. I'm inclined to leave it in a function because it feels sort of non-obvious to me - would be nice to help people avoid reinventing in every codebase. I'll attach a new patch.

Comment by Travis Vachon [ 12/Dec/13 10:53 AM ]

add new patch that just moves the problematic require into a function. the hashbang issue the original patch addressed is better fixed with the preamble work in http://dev.clojure.org/jira/browse/CLJS-723

Comment by David Nolen [ 16/Jan/14 5:33 PM ]

Isn't this a breaking change for existing Node.js users?

Comment by Travis Vachon [ 22/Jan/14 2:00 PM ]

it is yeah, I assumed that was ok because you said you'd be happy to remove it altogether - I'm ok with removing it if you think that's a preferable breaking change.

Comment by David Nolen [ 22/Jan/14 2:11 PM ]

Lets rename it to enable-util-print! to match enable-console-print!.

Comment by Travis Vachon [ 22/Jan/14 2:13 PM ]

cool! will do. I'll update the patch today.

Comment by Travis Vachon [ 22/Jan/14 7:22 PM ]

rename function to enable-util-print!

Comment by David Nolen [ 23/Jan/14 7:52 AM ]

fixed, https://github.com/clojure/clojurescript/commit/b299a6b1e9a522de0b1c3345f54f164bc3524f8f





[CLJS-636] ClojureScript Analyzer/Compiler should have extensible hooks to handle warnings Created: 24/Oct/13  Updated: 04/Nov/13  Resolved: 04/Nov/13

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

Type: Enhancement Priority: Minor
Reporter: Sean Grove Assignee: Unassigned
Resolution: Completed Votes: 0
Labels: cljs, cljsbuild

Attachments: Text File cljs-warning-middleware.patch    
Patch: Code

 Description   

To make the build process more configurable and stricter/less strict as needed by various projects, the cljs compiler should provide hooks that're invoked whenever a warning is emitted. Eventually these should be exposed through something like cljsbuild.

The attached patch changes the analyzer to emit warnings and emit dynamic warning handlers.

Note sure where the test for this could go though, it doesn't look like there's any infrastructure for the clj side.



 Comments   
Comment by Chas Emerick [ 25/Oct/13 11:24 AM ]

Couple of things:

1. You don't need when-not; if the handlers var is empty or nil, doseq will handle it just fine.
2. The default value of the handlers var should probably be a function that mimics current functionality?
3. I'd like to suggest that all of the relevant data for each warning be passed in addition to the type of warning. i.e. instead of just :dynamic, {:type :dynamic :name (:name ev)}, etc.

Comment by David Nolen [ 25/Oct/13 12:14 PM ]

I agree that the default value of the handler should do what we currently do and that we should pass all information about the warning we have.

Comment by Sean Grove [ 26/Oct/13 12:14 AM ]

Updated to remove (when-not (nil?..., and moves the current behavior into cljs-warning-handlers as the default handler.

It also changes the warning types to introduce more nuanced differences, allowing the default-warning-handler to be entirely self-contained. It relies on different keys being in the map for any given error type when producing the warning message, but it's probably manageable.

It also means there's a neat place to to addition error-type-specific information for handlers to pull out as needed. Right now just enough goes into each type to reproduce the current default behavior, but more could be passed along as needed - it's not always a standard set of data for each type, so maybe this is a good way to go about it.

Comment by Sean Grove [ 26/Oct/13 12:32 AM ]

A few fixes, tests pass, make sure (warning ... is passed the correct warning type, fix no-warn macro.

Comment by David Nolen [ 26/Oct/13 9:58 AM ]

Can we please get a squashed patch? Thanks!

Comment by Sean Grove [ 26/Oct/13 12:28 PM ]

Squashed patched

Comment by David Nolen [ 26/Oct/13 2:22 PM ]

Chas this looks pretty good to me, good enough for lein cljsbuild to use?

Comment by Sean Grove [ 27/Oct/13 11:10 AM ]

Fix default-warning-handler to respect cljs-warnings. Tests still pass, but would like having some clj-side tests to assert behavior around this stuff. Should I open another issue about getting clojure.test setup and tied into the build, or is that uninteresting right now?

Comment by David Nolen [ 27/Oct/13 8:07 PM ]

We already have placeholder test files for the analyzer, compiler, and closure. Feel free to add tests!

Comment by Chas Emerick [ 27/Oct/13 9:50 PM ]

Will review ASAP. Thanks for working on this!

Comment by Chas Emerick [ 28/Oct/13 8:02 AM ]

The patch looks good. I think people are going to want to delegate to default-warning-handler as a fall-through (e.g. to emit the message corresponding to a warning, even if a particular tool is going to choose to treat it as an error), but we can address that later. Once this lands, we'll be able to tie up https://github.com/emezeske/lein-cljsbuild/issues/225. Thanks!

Comment by David Nolen [ 28/Oct/13 8:35 AM ]

Sean, when I run (fn [] (+ a b)) at the REPL (script/repljs) prior to this patch I get warnings about undeclared vars. After applying the patch I no longer get warnings.

Comment by Sean Grove [ 28/Oct/13 9:50 AM ]

Will take a look and add some clj tests to confirm the behavior.

Comment by Sean Grove [ 02/Nov/13 2:46 PM ]

Made sure all references to cljs-warnings were updated appropriately with the new warning types, added some basic tests, changed confirm-var-exists behavior to only call warning if a warning case has been triggered.

Comment by Sean Grove [ 02/Nov/13 2:53 PM ]

There are some bigger-than-expected changes in here, and it'd be nice to get some extra eyes on it to make sure warnings are triggered where expected. I tested a lot of it out in the repl and added some tests, but don't have enough code to exercise all of the paths.

Comment by David Nolen [ 04/Nov/13 8:02 AM ]

Patch looks good to me and it appears to work as advertised

Comment by David Nolen [ 04/Nov/13 8:05 AM ]

fixed, http://github.com/clojure/clojurescript/commit/abd44502079425f76f31c5432e7366ecd33d866a





[CLJS-630] Old-style property accessor raises warning on compile Created: 19/Oct/13  Updated: 24/Oct/13  Resolved: 24/Oct/13

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

Type: Defect Priority: Minor
Reporter: Sean Grove Assignee: Sean Grove
Resolution: Completed Votes: 0
Labels: cljs
Environment:

cljs


Attachments: Text File fix-clojure-browser-repl-property-accessor.patch     Text File fix-various-property-accessor.patch    
Patch: Code

 Description   

clojure.browser.repl is accessing the property of an event via the / syntax, which seems to have been deprecated:
https://github.com/clojure/clojurescript/blob/f74b50967ef4041db585bd6c6f2f490285f61961/src/cljs/clojure/browser/repl.cljs#L71

It causes warnings on compile:

WARNING: No such namespace: e at line 71 resources/public/js/bin-debug/clojure/browser/repl.cljs

Attached is a fix



 Comments   
Comment by Greg Chapman [ 19/Oct/13 3:25 PM ]

e/currentTarget also appears inside the clojure.reflect module (reflect.cljs, line 19 - where e is again an event object). Presumably this should also be changed if this style of property access has been deprecated.

Comment by Sean Grove [ 20/Oct/13 5:27 PM ]

Updates another e/currentTarget instance as pointed out by Greg Chapman.

Comment by David Nolen [ 24/Oct/13 9:01 AM ]

fixed, https://github.com/clojure/clojurescript/commit/2ce425abccd83887001c056e962aadb89683a86b https://github.com/clojure/clojurescript/commit/d31b5365bef4423e59f8112657a0c2402e254195





[CLJS-576] Implement Reified Keywords Created: 26/Aug/13  Updated: 08/Sep/13  Resolved: 08/Sep/13

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

Type: Enhancement Priority: Major
Reporter: Sean Grove Assignee: Unassigned
Resolution: Completed Votes: 0
Labels: cljs, keywords

Attachments: Text File real_keywords.patch    

 Description   

Implement real/reified keywords in ClojureScript so we can stop modifying the String.prototype for strings-as-keywords. Attached patch does that.

One potential notice for the community is that `("a" {"a" 10})` previously worked in ClojureScript before this patch (though not on the jvm).



 Comments   
Comment by David Nolen [ 08/Sep/13 6:26 PM ]

fixed, http://github.com/clojure/clojurescript/commit/2cef52840fcd9d88f077d374cc81e50c7e645b9f
http://github.com/clojure/clojurescript/commit/2e8b32aa28399c69500e511377b1841a6679c9f2





[CLJS-540] Switch to tools.reader for cljs.analyzer/forms-seq Created: 15/Jul/13  Updated: 29/Jul/13  Resolved: 29/Jul/13

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

Type: Enhancement Priority: Major
Reporter: Sean Grove Assignee: Unassigned
Resolution: Completed Votes: 0
Labels: analyzer, cljs, reader, sourcemap
Environment:

CLJS master


Attachments: Text File tools_reader_with_passing_tests.patch    
Patch: Code

 Description   

Switches cljs.analyzer to use tools.reader, so we can get more accurate column location for symbols, prepping for more fleshed-out source maps.



 Comments   
Comment by David Nolen [ 15/Jul/13 10:43 AM ]

Excellent, we need two more things in this patch, can you update bootstrap.sh and the POM file? Thanks.

Comment by Sean Grove [ 15/Jul/13 11:00 AM ]

Updated with POM information and bootstrap update

Comment by Sean Grove [ 22/Jul/13 2:20 PM ]

CA's been processed and I'm listed on the contributing page, so shouldn't be blocked by that any longer.

Comment by David Nolen [ 27/Jul/13 2:09 PM ]

I tried applying this patch and rerunning the bootstrap script. This works but when I try to run script/test I get an error about the tools.reader not being on the classpath. Even trying to require tools.reader at via the repl doesn't work for me.

Comment by David Nolen [ 29/Jul/13 11:14 AM ]

fixed http://github.com/clojure/clojurescript/commit/9f010ff5d4a122b0f1dc93905647f309cc45c699





[CLJS-487] Make cljsc copy js sources to public directory Created: 16/Mar/13  Updated: 29/Jul/13  Resolved: 29/Jul/13

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

Type: Enhancement Priority: Minor
Reporter: John Chijioke Assignee: Unassigned
Resolution: Declined Votes: 0
Labels: cljs, cljsc, js
Environment:

Linux jetty web server



 Description   

I'll like cljsc to copy my js sources to the public directory as it does when compiling the cljs sources and make the correct entry in the generated deps.js so that the source can be retrievable with GET without extra configuration.



 Comments   
Comment by David Nolen [ 29/Jul/13 11:23 PM ]

enhancements to the build process at this point are unlikely outside of source maps and enabling external tools that can implement enhancements like this themselves.





Generated at Wed Jul 29 15:15:17 CDT 2015 using JIRA 4.4#649-r158309.