Fork me on GitHub

Setting :parallel-build to true is giving me non-deterministic :advanced artifacts, with small differences in ordering and names within the generated js. This is understandable, but is it an expected/known behavior?


@aisamu :parallel-build builds using multiple threads while honoring the dependency partial order. That would theoretically cause gensyms or other stuff that depends on compilation state to vary non-deterministically.


Makes perfect sense, thanks! We now have empirical confirmation ๐Ÿ™‚


any recommendation for clojurescript/clojure project template in leiningen?


I believe I have found a bug in the ClojureScript compiler integration with npm; what would be the best way to confirm and report?


what was that talk about immediate feedback where the speaker moved a slider and changed a tree animation?


@urbanslug Sounds like something from Bret Victor


Here's my finding. I'm using the semantic-ui-react library ( imported through NPM. The package gets downloaded fine and it looks like everything works well on the server-side rendering of my application. However, the client-side dies at load-time with the following error:

Error: Undefined nameToPath for module$Users$gary$sparrho$seshat$_gecko$node_modules$semantic_ui_react$dist$es$addons$Confirm
I have cleaned everything multiple times etc. I have dug a little bit in the generated files, and on the server-side it looks like we're using the node_modules folder directly (which makes sense as the target is :nodejs). The file structure is a bit weird to me for this particular module as we have:
$ tree                 
โ”œโ”€โ”€ addons           
โ”‚   โ”œโ”€โ”€ Confirm          
โ”‚   โ”‚   โ”œโ”€โ”€ Confirm.js
โ”‚   โ”‚   โ””โ”€โ”€ index.js
Looking into Confirm.js there is a bunch of code that ends with export default Confirm;. The index.js file however is more interesting:
$ cat Confirm/index.js
import _default from './Confirm';
export { _default as default };
I'm not familiar at all enough with JS packaging methods to know how widespread this pattern is, but the intent seems clear: the index.js file is there to provide the name Confirm as an alias of the Confirm.Confirm provided by the Confirm.js file. Why they have that directory at all rather than just addons/Confirm.js (which seems to be the pattern in sibling directories of addons) is beyond me. After a bit of grepping through the generated code on the client side I have found some confirmation that this is a supported pattern, to some extent. The "closurified" version of index.js looks like:
cat compiled/out/node_modules/semantic-ui-react/dist/es/addons/Confirm/index.js
var module$Users$gary$sparrho$seshat$_gecko$node_modules$semantic_ui_react$dist$es$addons$Confirm$index={get default(){return module$Users$gary$sparrho$seshat$_gecko$node_modules$semantic_ui_react$dist$es$addons$Confirm$Confirm["default"]}}
Looking around in the generated files it looks like, generally speaking, whenever there is a file that says export ... as mod, the CLJS compiler (I assume?) adds two goog.provide to calls: one with the full path on my hard drive, and one with the relative path from the node_modules folder. In this case there are three entries, which makes me believe there may be some special handling for this pattern (`export ... as default`?) which is missing the "also do the full path" thing. This is all happening with :optimizations :none. I have not tried with more advanced optimizations yet. Does that look like a bug in CLJS ? If so I'll get to work on a minimal repro case.


@gaverhae Why not just use soda-ash?


I've used it and been able to move really fast


We're not using reagent. We're currently using the cljsjs version of semantic-ui-react and it works fine, but I'm trying to add other npm deps that are not in cljsjs and it looks like they can't find each other (e.g. react-responsive-carousel from npm can't find React from cljsjs), so I'm trying to move all node deps from cljsjs to npm-deps.


My problem seems directly related to and that seems to be the one adding what I see as half of the solution.


What are you using to manage your deps, compile etc?


too bad I can't help


with shadow-cljs these things are quite simple


Yes, leiningen with cljsbuild

Garrett Hopper17:08:04

Is there a way I can force the CLJS compiler to load react before react-dom from :npm-deps?


I'm inspecting my cljs final bundle and there is a lot of clojure.test.check on it. How to remove it from my bundle? I'm not using it anywhere (maybe it's loaded on the classpath when I call the cljs.main build command)


@ghopper it should figure that out from react-dom using goog.require and react using goog.provide, I think. How is your project set up?

Garrett Hopper19:08:53

react-dom doesn't actually depend on react, though an error is thown if it's loaded before react.

Garrett Hopper19:08:07

I just have both in my :npm-deps, and they're used by reagent.

Garrett Hopper19:08:31

I have :exclusions for cljsjs/react and cljsjs/react-dom for reagent.


I've had a pretty terrible time trying to mix cljsjs with npm-deps so far. I'm actually in the middle of trying to move away from that and move everything to npm-deps. I'm not using reagent though; not sure how you can get it to see the npm-deps versions.

Garrett Hopper19:08:36

That's what I'm doing as well. ๐Ÿ™‚ I'm trying to replace reagent's react with :npm-deps.


I'd suggest explicitly requiring react then react-dom in your entrypoint namespace

Garrett Hopper19:08:55

It doesn't have a problem seeing the :npm-deps version, there's just a load order problem.

Garrett Hopper19:08:18

Manually requiring it in my namespace has no effect.


I blame dead code elimination


You'd have to actually use them in a way that the compiler can't figure out is useless? ๐Ÿ˜•

Garrett Hopper19:08:46

There's no DCE going on. This is all in development.


What does your import statement look like?


If you go (:require react) it will require it as the react cljs var, but given the set-up in cljsjs ( I suspect reagent will expect React to be available as js/React?

Garrett Hopper20:08:16

Yeah, reagent shouldn't have an issue with it.


I am trying to use the expound printer with clojure.spec.test.alpha/summarize-results


but it seems like it does not kick in


anybody noticing the same?


@richiardiandrea What code are you using?


@richiardiandrea Keep in mind summarize-results does not utilize s/*explain-out*


(binding [s/*explain-out* (expound/custom-printer
                                           (merge {:print-specs? true}
                                                  (when *gen-test-colors*
                                                    {:theme :figwheel-theme})))]
                  (-> (tcs/run-spec-checks! `api/ok-response opts)


that explains everything


let me make it clear in the README


summarize-results is for printing the results from check, which contains more data than just the explain-data that is returned from explain-data, used in explain etc


I will use expound/explain-results then


Excellent, that should work ๐Ÿ™‚


Right now, summarize-results isnโ€™t extensible, but I wonder if thatโ€™s something that could change. Itโ€™d be nice to โ€œinstallโ€ expound once and get the behavior you were expecting


It is odd because the check results do not seems to take into consideration explain-out


at least here, the js/Error message I see is always starting by: Specification-based check failed no matter the content of it


Yep, the whole check system doesnโ€™t connect with the way printing works for explain


I can understand why itโ€™s different, but itโ€™d be nice to have a parallel system for check so users can register a s/*check-printer* or something.


Might be something to mention in #clojure-spec