<< Back to previous view

[CLJS-2244] Orphaned processed JS modules breaks :modules Created: 15/Jul/17  Updated: 15/Jul/17  Resolved: 15/Jul/17

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

Type: Defect Priority: Blocker
Reporter: David Nolen Assignee: Unassigned
Resolution: Completed Votes: 0
Labels: js-modules, modules

Approval: Vetted

 Description   

An orphaned processed JS module when using :modules code splitting will cause a no `:out-file` exception to be thrown.



 Comments   
Comment by David Nolen [ 15/Jul/17 9:15 AM ]

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





[CLJS-2333] module-deps.js doesn't correctly compute `main` if aliased in browser field Created: 21/Aug/17  Updated: 25/Aug/17  Resolved: 25/Aug/17

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

Type: Defect Priority: Major
Reporter: António Nuno Monteiro Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: js-modules

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

 Comments   
Comment by David Nolen [ 25/Aug/17 2:44 PM ]

fixed https://github.com/clojure/clojurescript/commit/88e1f39d5653f154da6b6362bced3c3cb5c15e3b





[CLJS-2373] Bump tools.reader to 1.1.0 Created: 30/Sep/17  Updated: 30/Sep/17  Resolved: 30/Sep/17

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

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

Approval: Accepted

 Comments   
Comment by David Nolen [ 30/Sep/17 3:58 AM ]

fixed https://github.com/clojure/clojurescript/commit/26bf9a5baf30bfbe81ef98b9db300b8c9232939f





[CLJS-2396] Configurable reader features Created: 11/Nov/17  Updated: 17/Nov/17  Resolved: 17/Nov/17

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

Type: Enhancement Priority: Major
Reporter: Thomas Heller Assignee: Unassigned
Resolution: Declined Votes: 0
Labels: None


 Description   

The reader features for .cljc files is currently hard coded to #{:cljs} and Clojure will use :clj. With the intent being that host-specific features can be chosen at read-time. Given that there are a variety of different JS host platforms it would be useful to allow setting build-specific reader features so that builds targeting node can use different code than using the browser.

We can not always rely on the Closure Compiler eliminating all the code for us and we currently have no other way to get conditional requires.

Kevin Lynagh described his use-case here: https://gist.github.com/lynaghk/0608a43f173558b6fcf30c3be53d77dd

I had a very similar use case in mind for conditional requires related to excluding some code from a node.js targeted build for doing SSR that otherwise should use the same code as the browser uses.

My suggestion would be to add :reader-features #{:kw1 kw1} to the compiler options which will be added to the default :cljs at read-time.



 Comments   
Comment by David Nolen [ 17/Nov/17 1:38 PM ]

This is serious language level feature request. Such ideas need to be discussed around Clojure first.

Comment by Thomas Heller [ 17/Nov/17 2:10 PM ]

I was under the impression that JIRA is the place to have these discussions so they don't get lost in Slack Archives.

The Clojure Reader and tools.reader already support everything we need so no changes to either are necessary.

Only the :features option would become configurable, nothing more. Clojure itself does not need this feature since it only runs on the JVM, has its :clj option and already ignores every other option. I do think it is useful to have this for CLJS given the wide variety of host platforms.

https://github.com/clojure/clojurescript/blob/245bdee2c35e19a9685b7a0849f26fce8bdaf7ca/src/main/clojure/cljs/analyzer.cljc#L3652 and very few other places would need to change.





[CLJS-2197] Calling instrumented var fails to check conformance Created: 09/Jul/17  Updated: 22/Dec/17  Resolved: 22/Dec/17

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

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


 Description   

If you spec a fn var and then instrument and call it, an args conformance check is made. If instead you call the var using the actual var in operator position, it will fail to make the conformance check. The same will occur with a HOF, as in applying the fn to an args sequence. These last two variants work in Clojure.

Repro:

$ java -jar cljs.jar -m cljs.repl.node
ClojureScript Node.js REPL server listening on 50246
To quit, type: :cljs/quit
cljs.user=> (require '[clojure.spec.alpha :as s] '[clojure.spec.test.alpha :as st])
true
cljs.user=>   (s/fdef clojure.core/symbol
    :args (s/alt :separate (s/cat :ns string? :n string?)
                 :str string?
                 :sym symbol?)
    :ret symbol?)
cljs.core/symbol
cljs.user=> (st/instrument)
[cljs.core/symbol]
cljs.user=> (symbol 3)
repl:13
throw e__5614__auto__;
^

Error: Call to #'cljs.core/symbol did not conform to spec:
In: [0] val: 3 fails at: [:args :separate :ns] predicate: string?
In: [0] val: 3 fails at: [:args :str] predicate: string?
In: [0] val: 3 fails at: [:args :sym] predicate: symbol?
:cljs.spec.alpha/spec  #object[cljs.spec.alpha.t_cljs$spec$alpha2801]
:cljs.spec.alpha/value  (3)
:cljs.spec.alpha/args  (3)
:cljs.spec.alpha/failure  :instrument

    at new cljs$core$ExceptionInfo (/Users/mfikes/Downloads/.cljs_node_repl/.cljs_node_repl/cljs/core.js:34869:10)
    at Function.cljs.core.ex_info.cljs$core$IFn$_invoke$arity$3 (/Users/mfikes/Downloads/.cljs_node_repl/.cljs_node_repl/cljs/core.js:34930:9)
    at Function.cljs.core.ex_info.cljs$core$IFn$_invoke$arity$2 (/Users/mfikes/Downloads/.cljs_node_repl/.cljs_node_repl/cljs/core.js:34926:26)
    at cljs$core$ex_info (/Users/mfikes/Downloads/.cljs_node_repl/.cljs_node_repl/cljs/core.js:34912:26)
    at /Users/mfikes/Downloads/.cljs_node_repl/cljs/spec/test/alpha.js:133:25
    at G__3555__delegate (/Users/mfikes/Downloads/.cljs_node_repl/cljs/spec/test/alpha.js:164:15)
    at G__3555 (/Users/mfikes/Downloads/.cljs_node_repl/cljs/spec/test/alpha.js:185:26)
    at repl:1:96
    at repl:9:3
    at repl:14:4
cljs.user=> (#'symbol 3)
repl:13
throw e__5614__auto__;
^

TypeError: name.indexOf is not a function
    at Function.cljs.core.symbol.cljs$core$IFn$_invoke$arity$1 (/Users/mfikes/Downloads/.cljs_node_repl/.cljs_node_repl/cljs/core.js:3531:16)
    at cljs.core.Var.G__8901__2 (/Users/mfikes/Downloads/.cljs_node_repl/.cljs_node_repl/cljs/core.js:3627:65)
    at cljs.core.Var.G__8901 [as call] (/Users/mfikes/Downloads/.cljs_node_repl/.cljs_node_repl/cljs/core.js:3773:19)
    at repl:1:2682
    at repl:9:3
    at repl:14:4
    at ContextifyScript.Script.runInThisContext (vm.js:44:33)
    at Object.runInThisContext (vm.js:116:38)
    at Domain.<anonymous> ([stdin]:50:34)
    at Domain.run (domain.js:242:14)
cljs.user=> (apply symbol [3])
repl:13
throw e__5614__auto__;
^

TypeError: name.indexOf is not a function
    at Function.cljs.core.symbol.cljs$core$IFn$_invoke$arity$1 (/Users/mfikes/Downloads/.cljs_node_repl/.cljs_node_repl/cljs/core.js:3531:16)
    at Object.cljs$core$apply_to [as apply_to] (/Users/mfikes/Downloads/.cljs_node_repl/.cljs_node_repl/cljs/core.js:12421:45)
    at Function.cljs.core.apply.cljs$core$IFn$_invoke$arity$2 (/Users/mfikes/Downloads/.cljs_node_repl/.cljs_node_repl/cljs/core.js:12860:18)
    at cljs$core$apply (/Users/mfikes/Downloads/.cljs_node_repl/.cljs_node_repl/cljs/core.js:12818:24)
    at repl:1:95
    at repl:9:3
    at repl:14:4
    at ContextifyScript.Script.runInThisContext (vm.js:44:33)
    at Object.runInThisContext (vm.js:116:38)
    at Domain.<anonymous> ([stdin]:50:34)


 Comments   
Comment by Mike Fikes [ 09/Jul/17 8:04 AM ]

It is worth noting that the second variant, (#'symbol 3) works in Planck (but not the third) (apply symbol [3]).

Comment by David Nolen [ 22/Dec/17 12:05 PM ]

This is a variant of direct invoke getting in the way of instrumentation, see CLJS-2397. This is because Var uses direct invokes in its IFn implementations.

Comment by David Nolen [ 22/Dec/17 2:10 PM ]

fixed https://github.com/clojure/clojurescript/commit/93a841b6e1a043e4bac0fcae3d82cc0410f7f3fc





[CLJS-1620] In JavaScript ES2015 modules default export name is munged to default$ Created: 08/Apr/16  Updated: 01/Aug/17  Resolved: 01/Aug/17

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

Type: Defect Priority: Minor
Reporter: Roman Liutikov Assignee: António Nuno Monteiro
Resolution: Completed Votes: 0
Labels: js-modules

Attachments: Text File CLJS-1620-2.patch     Text File CLJS-1620.patch    
Patch: Code and Test
Approval: Screened

 Description   

When using a foreign lib which is ES2015 module with default export, the value which is being exported is assigned to a property default on a namespace object. In ClojureScript code this means one should call to default var of that namespace. However in complied output of ClojureScript code the name default is getting munged to default$.

export default function inc(v) {
  return v + 1;
}
(ns cljs-example.core
  (:require [lib.inc :as lib]))

(lib/default 0)
goog.provide("module$lib$inc");
function inc$$module$lib$inc(v){return v+1}
module$lib$inc.default=inc$$module$lib$inc
// Compiled by ClojureScript 1.8.40 {}
goog.provide('cljs_example.core');
goog.require('cljs.core');
goog.require('module$lib$inc');
module$lib$inc.default$.call(null,(0));

//# sourceMappingURL=core.js.map


 Comments   
Comment by David Nolen [ 08/Apr/16 2:42 PM ]

One possible path around this is to respect the Closure Compiler language setting when munging instead of blindly munging ECMA-262 keywords. A patch that adopts this approach would be welcome.

Comment by António Nuno Monteiro [ 30/Jul/17 5:09 PM ]

Patch attached following the suggested approach.

Comment by David Nolen [ 01/Aug/17 7:29 AM ]

I reviewed the patch, I'm not sure I really understand the rationale behind the approach. It seems if any JS module exists is :es6 then ES6 keywords rules apply. However what I had in mind was to use Closure Compiler `:language-out` to manage this.

That said, the bits of patch to make `:js-module-index` richer in structure doesn't seem like a bad idea.

Comment by António Nuno Monteiro [ 01/Aug/17 3:11 PM ]

Attached patch with suggested changes.

Comment by David Nolen [ 01/Aug/17 5:40 PM ]

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





[CLJS-2378] Keep the value of ':npm-deps-installed?' in the repeated builds such as "lein cljsbuild auto". Created: 04/Oct/17  Updated: 29/Oct/17  Resolved: 29/Oct/17

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

Type: Defect Priority: Minor
Reporter: Jinseop Kim Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: None
Environment:

Node.js


Attachments: Text File CLJS-2378.patch     Text File CLJS-2378.patch    

 Description   

While using 'lein-cljsbuild',
I found a bug that toggle the ':npm-deps-installed?' whenever compiling.

In the 'build' function, src/main/clojure/cljs/closure.clj:2524:

(swap! compiler-env update-in [:npm-deps-installed?]
       (fn [installed?]
         (when-not installed?
           (maybe-install-node-deps! opts))))

In above, the lambda function will return nil if the ':npm-deps-installed?' is true.
I think that should keep the ':npm-deps-installed?' if it is true.

(swap! compiler-env update-in [:npm-deps-installed?]
       (fn [installed?]
         (if-not installed? ;; <= !!!
           (maybe-install-node-deps! opts)
           true)))          ;; <= !!!


 Comments   
Comment by Jinseop Kim [ 04/Oct/17 9:36 AM ]

I add a patch.

Comment by António Nuno Monteiro [ 11/Oct/17 11:53 AM ]

The attached patch looks good to me.

Comment by David Nolen [ 13/Oct/17 2:38 PM ]

Jinseop have you submitted a Clojure contributor agreement? Thanks.

Comment by Jinseop Kim [ 13/Oct/17 7:05 PM ]

Yes.

Comment by Ulf Ninow [ 28/Oct/17 8:04 AM ]

maybe the same problem will be in
src/main/clojure/cljs/repl.clj:884:

(swap! env/*compiler* update-in [:npm-deps-installed?]
  (fn [installed?]
    (when-not installed?
      (cljsc/maybe-install-node-deps! opts))))
Comment by Jinseop Kim [ 28/Oct/17 9:24 PM ]

updated the patch to include what i missed, as Ulf Ninow mentioned.

Comment by David Nolen [ 29/Oct/17 8:45 AM ]

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





[CLJS-2215] Allow clj->js to preserve namespaces Created: 11/Jul/17  Updated: 01/Dec/17  Resolved: 01/Dec/17

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

Type: Enhancement Priority: Minor
Reporter: Enzzo Cavallo Assignee: David Nolen
Resolution: Completed Votes: 2
Labels: cljs, enhancement, interop

Attachments: Text File clj-to-js.patch    
Patch: Code and Test
Approval: Accepted

 Description   

Original issue
https://dev.clojure.org/jira/browse/CLJS-536

Keypoints from CLJS-536

  • IEncodeJS is powerfull, but for keywords, can break other libreries that expect trim-ns behavior (Le Wang)
  • With the introduction of specs, the namespaced keywords are being used more and more. This issue prevents streamlined edn->json->edn transformation. I think it should be reopened. IMO the 'lossy' method should never be a default one. (Jozef Wagner)
  • Should be possible do this without break existing code and using kwargs (Paulus Esterhazy)

An use example can be `(clj->js {:foo/bar 33} :keyword-fn #(.-fqn %)) ;=> #js {:foo/bar 33}`

PS: key->js should use key>js method, but I keep it with clj>js to avoid break things (it should be another bug?!).



 Comments   
Comment by Mike Fikes [ 30/Nov/17 7:53 AM ]

Looks like we are already set up for the opposite direction:

cljs.user=> (js->clj #js {"cljs.user/bar" 33 "cljs.user/baz" 12} :keywordize-keys true)
#:cljs.user{:bar 33, :baz 12}

Docstring should be updated for :keyword-fn.

Given that this might slow down clj->js, perhaps benchmarks should be added to cljs.benchmark-runner to show that there aren't huge perf regressions.

Comment by David Nolen [ 01/Dec/17 3:14 PM ]

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





[CLJS-2427] docstring for clojure.string/split-lines needs escaping Created: 02/Dec/17  Updated: 22/Dec/17  Resolved: 22/Dec/17

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

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

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

 Description   
cljs.user=> (doc clojure.string/split-lines)
-------------------------
clojure.string/split-lines
([s])
  Splits s on
 or
.

nil


 Comments   
Comment by Mike Fikes [ 02/Dec/17 1:26 PM ]

With patch:

cljs.user=> (doc clojure.string/split-lines)
-------------------------
clojure.string/split-lines
([s])
  Splits s on \n or \r\n.

nil
Comment by David Nolen [ 22/Dec/17 2:20 PM ]

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





[CLJS-2447] Ignore non-js (css) JS modules Created: 20/Dec/17  Updated: 22/Dec/17  Resolved: 22/Dec/17

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

Type: Enhancement Priority: Minor
Reporter: Juho Teperi Assignee: Juho Teperi
Resolution: Completed Votes: 0
Labels: None

Attachments: Text File CLJS-2447-2.patch     Text File CLJS-2447.patch    

 Description   

Some Node packages (like firebase-web-react: https://github.com/firebase/firebaseui-web-react/blob/master/dist/FirebaseAuth.js#L35) try to require css files. Webpack can bundle the css files. Closure doesn't support this.

I think this could be solved by ignoring these, by just passing empty string as source for these files, so Closure doesn't fail when it tries to parse the file as JS.



 Comments   
Comment by Juho Teperi [ 20/Dec/17 1:38 PM ]

Patch to ignore contents of non .js/.json files in module processing. Existing tests pass, but I didn't have time to test this with real case.

Comment by David Nolen [ 22/Dec/17 2:15 PM ]

Patch has a typo

Comment by Juho Teperi [ 22/Dec/17 2:34 PM ]

Oh, sorry. Renamed that to url.

Comment by David Nolen [ 22/Dec/17 5:22 PM ]

fixed https://github.com/clojure/clojurescript/commit/123e8f9aa59899c6886bbe392128b22ae9a0def3





[CLJS-2131] Calling empty on a ChunkedSeq returns a vector not an empty list Created: 27/Jun/17  Updated: 29/Dec/17  Resolved: 29/Dec/17

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

Type: Defect Priority: Minor
Reporter: Thomas Mulvaney Assignee: Unassigned
Resolution: Completed Votes: 1
Labels: None

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

 Description   

Calling empty on a ChunkedSeq returns an empty vector rather than an empty list.



 Comments   
Comment by Thomas Mulvaney [ 27/Jun/17 3:56 AM ]

Metadata was also being carried on to the empty seq which is not expected behaviour for seqs.

Comment by Mike Fikes [ 19/Nov/17 7:28 PM ]

The attached patch no longer applies. Needs to be re-baselined.

Comment by Thomas Mulvaney [ 28/Dec/17 12:56 AM ]

Attached rebased patch. Test case was moved into seq-test namespace.

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

fixed https://github.com/clojure/clojurescript/commit/8de3e8acaff526bd05a6d3f52a9f1582b53d0f80





[CLJS-2339] Significant code reload slowdown with :npm-deps Created: 29/Aug/17  Updated: 31/Dec/17  Resolved: 24/Sep/17

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

Type: Enhancement Priority: Minor
Reporter: Petter Eriksson Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: performance

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

 Description   

After migrating our dependencies from cljsjs to node_modules we noticed that figwheel took a lot longer to reload our code.

I asked in #clojurescript if anyone had an idea of what could be done and @anmonteiro wrote:
@petterik might just be because we're processing all your node dependencies through Closure on every reload feel free to open a JIRA ticket, we could probably employ a caching strategy somewhere

Versions used:
clojurescript "1.9.908"
lein-figwheel "0.5.13"

npm-depm deps:
:react-helmet "5.1.3"
:react "15.6.1"
:react-dom "15.6.1"
as well as some devDependencies in package.json.



 Comments   
Comment by Petter Eriksson [ 29/Aug/17 1:23 PM ]

If needed to repro, here are the additional devDependencies:
"phantomjs": "1.9.19",
"foundation-cli": "2.2.3",
"bower": "1.8.0"

Comment by David Nolen [ 15/Sep/17 3:32 PM ]

This ticket will need more information. It might just be a Figwheel issue.

Comment by Tony Kay [ 17/Sep/17 9:58 PM ]

OK, so I have some additional interesting facts. It does compile and work (where "work" is defined as "renders a thing from the npm module").

cljs: 1.9.908
cljsbuild: 1.1.7 via lein
Heap size: 2g
npm-deps: react, react-dom, and @blueprintjs/core
cljs deps: Om Next
verbose: true

Project is an om-next app, so cljsjs.react is in the classpath

Building the application without the npm deps and no code that refers to them: 46 seconds (CPU time)
Adding the NPM deps (with install true, but no code that uses them) increases this just be the amount of the install: 59 seconds
using the npm deps increases compile time to: 3 minutes 50 seconds

Critically: with verbose on, I can see that om/next.cljs takes about 15s in the first two cases, and 3 minutes in the final one. In other words: the thing that is slow is compiling next.cljc. Nothing else gets slower.

I'm not sure if this is even going to work "right" when it does compile, since I'm not sure how the cljsjs.react and npm react can co-exist (this is where I assume Om Next probably just needs to be made to use npm instead of cljsjs?)

But, since I saw that Petter was pulling in similar deps, he might be hitting a similar problem with cljsjs.react and npm react both being "in scope" so to speak.

When I use it from figwheel, the time between reloads becomes unusable. I assume it is related, but I have no data to back that up.

EDIT: I had missed the new doc on :global-exports. I'm going to try that and add my results.

Comment by Tony Kay [ 17/Sep/17 10:51 PM ]

So, I fixed the build to be "correct" with `:global-exports so that I only have the NPM version of react and react-dom around (excluded cljsjs/react and react-dom from Om Next). The compile time for next.cljc is still about 3 minutes (compared to the "normal" 15s)

BUT, I then removed blueprint from my `:npm-deps` (and usage), but kept react, react-dom, and a use of react (the NPM one) The time to compile next.cljc dropped to about a minute! Still 4x slower than "normal", but 4x faster than with blueprint in the npm deps. It seems that a file using an npm dep see a significant slowdown that is somehow proportional to the amount of total npm deps code "in view".

Obviously, Om Next uses React, but not blueprint. Yet, it's compile time is significantly affected.

What Antonio said about processing them all through Closure certainly sounds relevant. Kind of a let down to go from recent speed-ups in compiler speed to this sudden jolt of a performance hit when we finally get a better interface to libraries

Comment by António Nuno Monteiro [ 17/Sep/17 11:35 PM ]

Patch attached.

Comment by Tony Kay [ 17/Sep/17 11:48 PM ]

That patch fixes the build issue on plain cljsbuild.

Figwheel now starts quickly (first complete compile), but a simple file change on a small project takes 12s to hot code reload, making it pretty unusable.

Comment by António Nuno Monteiro [ 18/Sep/17 12:01 AM ]

So it looks like this is a 2-part problem.

The first one, which my patch solved, is related to CLJS compilation (where we were performing unnecessary computations on every symbol analysis – which slowed down proportionally to the number of JS modules processed).

The second problem is that we process every JS module on every code reload: the solution for this one is implementing a strategy for figuring out if we need to process JS modules again (e.g. based on last modified timestamps of source files, just like `cljs.compiler/requires-compilation?`).

Comment by António Nuno Monteiro [ 18/Sep/17 10:42 PM ]

The attached CLJS-2339-2.patch contains the changes in the previous patch and also solves the issues around reloading, only running the foreign libraries that are modules through Closure if any of the source files in the dependency graph have changed.

I'd appreciate if people who are seeing the issue can try out the patch and report back.

Comment by Tony Kay [ 19/Sep/17 11:01 PM ]

So, I did some profiling with visualvm, and gave the results to Antonio. They were showing the vast majority of the time being consumed by `pipe`, under the direction of the node module discovery functions. His new version of the second patch definitely improves reload speed considerably. My hot code reload went from about 14 seconds (via patch 1) to 2 seconds with the new version of patch 2. This is on a project with Om Next, and some largish node libraries.

Comment by David Nolen [ 24/Sep/17 4:36 AM ]

fixed https://github.com/clojure/clojurescript/commit/245bdee2c35e19a9685b7a0849f26fce8bdaf7ca

Comment by Alexis Vincent [ 31/Dec/17 4:42 PM ]

I'm still getting this with 1.9.946. Oddly enough it happens every other reload/eval. On a toy project, including react, with an empty file I get alternating reload/eval times of +-0.8 seconds and +-9 seconds. Removing react from npm-deps brings all reloads to +-0.8s.





[CLJS-2096] Avoid re-declaring deref Created: 16/Jun/17  Updated: 14/Dec/17  Resolved: 14/Dec/17

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

Type: Enhancement Priority: Trivial
Reporter: A. R Assignee: David Nolen
Resolution: Not Reproducible Votes: 0
Labels: None

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

 Description   

Currently every single @ or deref creates code like this:

$cljs$core$deref$$.$cljs$core$IFn$_invoke$arity$1$ ? $cljs$core$deref$$.$cljs$core$IFn$_invoke$arity$1$($G__11312_arr$jscomp$92_init__$2$$) : $cljs$core$deref$$.call(null, $G__11312_arr$jscomp$92_init__$2$$);

because it is declared after already defined. See CLJS-1992 .



 Comments   
Comment by A. R [ 14/Dec/17 10:31 AM ]

Fixed otherwise. Not reproducible.





[CLJS-2436] Print compiler options when running with :verbose true Created: 06/Dec/17  Updated: 22/Dec/17  Resolved: 22/Dec/17

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

Type: Enhancement Priority: Trivial
Reporter: Martin Klepsch Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: newbie

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

 Description   

For the purpose of comparing different build tools it would be useful to easily see what compiler options are used.

David suggested in Slack that these could be printed when `:verbose true` has been supplied.



 Comments   
Comment by David Nolen [ 22/Dec/17 5:56 PM ]

fixed https://github.com/clojure/clojurescript/commit/980639aced9771b846b759ae5d89e6ca4a06887a





Generated at Tue Jan 16 23:26:29 CST 2018 using JIRA 4.4#649-r158309.