Fork me on GitHub
Garrett Hopper01:03:58

Is there a way I can use extern inference to prevent closure from munging the name of a node.js required module? (Instead of using externs)


use strings ... [ :as bar] ["var/car.js" :as x]...


Is it bad practice to use a JavaScript object as a map key? For example, if I'd like to use a date as a map key, is it totally OK to use a instance or is it better to serialize it into a string, for example?


the thing to watch out for is that js objects are typically mutable (Date included) and if anyone mutates the key bad things happen


That's a good point. Shouldn't happen in this case, but definitely good to keep in mind — thanks!


@flowthing it’s fine, just keep in mind that you have to maintain a reference to such an object if you want to access the value in a map


Yeah, that's a good point. Thanks!


Although I guess in the case of*, might also do the trick.


Does anyone know offhand how figwheel launches the browser when it starts it's repl? I'm wondering if I can make it launch chrome by default so that I can use the cljs dev tools, while still having firefox as my default browser for everything else.


Ok, I'm now certain the :parallel-build option has race conditions. I suspected it for a while, as some of my builds were failing with bizarre messages, but now I caught it red-handed: if I have :parallel-build enabled, instead of catching a circular dependency the build will just hang indefinitely.


Hello there. Is there a way to turn off warnings for self-hosted clojurescript compilation?


cljs.js/eval automatically logs warnings but I want to disable them


Actually it's probably reported as error as the only way I have to stop that is (set! js/console.reportErrorsAsExceptions false)


@mfikes: indeed. I get this also with :optimizations :none. And it's just one of the issues I'm seeing with :parallel-build — the others are outright weird, such as errors in cljc compilation that disappear on the next build (I do clean things up between builds). I'm suspicious of this option.


@frankie Yes, you can bind cljs.analyzer/*cljs-warning-handlers* to a vector of whatever handlers you like or nil to turn them off altogether. (This is, for example, how Lumo and Planck provide markers pointing at the form causing the warning.) I suspect you can even squelch certain warnings but leave others.


@frankie In self-hosted, the analyzer is directly available to your self-hosted ClojureScript code. (Whereas in JVM-based ClojureScript, you need to adjust warnings at the Clojure level.)


@mfikes perfect that was exactly what I needed!


@jrychter it’s certainly possible though I think a lot of people use this option and we don’t get tons of reports


currently using it for the last 6 months on a project with at least a hundred source files, >20,000 LOC (not including deps) - and I haven’t had issues - but again - doesn’t mean much 🙂


@jrychter If you ever get it to hang again, be sure to use jstack or kill -3 on the compiler process so we can see where it is stuck (and perhaps drop the stack trace into CLJS-2055)


@jrychter Actually, I could be wrong about CLJS-2055; you may have no circular deps, and if you catch it hanging perhaps a new JIRA ticket is in order


Well, race conditions are racey and tricky. This is a large project (>30k LOC in 205 files). Problem is that if the compiler doesn't hang, I don't know how to get more information.


@mfikes: in my case I definitely did have circular deps. Once I removed the :parallel-build option I finally got the error message, removed the circular deps, and enabled the :parallel-build again, which didn't hang anymore.


Ahh, cool @jrychter. Well, a stack trace might help, as it is difficult to produce a minimal repro.


that's bitten us as well. have to turn the parallel build option off to get the report of where the circularity is


yeah we need a circular dep check before we start - what we have for :none is insufficient


@jrychter you changed your report here though - did you or didn’t you get a error under :none?


@joelsanchez yeah, we need to do something like that


@dnolen: when using :parallel-build, the compiler hangs for me with :none. I've added this info to the JIRA issue in case it helps.


@jrychter sorry I got confused, I really meant didn’t you get an error when you turned it off, but anyhow, this should be petty easy to fix by reusing some stuff I wrote for module splitting, will be in the next release


General help request: Try the ClojureScript 1.10.126 pre-release with your project to see if it at least compiles without warnings. Better: Try a little smoke testing or run your unit tests.


I get a zillion warnings about schema.core/MapEntry (both undeclared var and wrong number of args) in our app that uses prismatic/schema and also a runtime error "Maximum call stack size exceeded" with stack trace mentioning schema.core.MapEntry. Hmh!


The undefined warnings come from lines of schema.core using defrecord and schema.core excludes cljs.core MapEntry. I bet that after CLJS-2482, defining your own type/record called MapEntry is broken.


Yeah, it looks like Schema has an issue. It came up for Clara rules yesterday


I don’t see any issue logged for Schema


I don’t understand the problem yet enough to log one. I think they may want a PR to fix it though. Not sure they’d fix it quickly otherwise (not sure on the level of support it has right now).


Well, I'd say it's a bug in ClojureScript. MapEntry used to be perfectly fine name for a record.


Yeah, that was what I was thinking may be the case. I just dig through the error enough to know that was the issue.


There are actually quite a lot of recent cljs changes concerning map entries


That link didn't go anywhere useful, but yeah, I noticed


Ah, thought I could share a query view. Anyways, just search for recent “mapentry” cljs Jiras


not a bug, we own core names - downstream projects must adjust


trying to coordinate around new core name is not something we intend to ever do


@dnolen Hmm, so shadowing of core vars and/or class names isn’t allowed (even with different namespaces)?


@dnolen Schema does use :refer-clojure :exclude to exclude MapEntry, though! I'd expect this to work.


I find that surprising given refer exclusions and namespaces


no idea what the problem is, just saying we take core names when we see fit, we don’t coordinate here


Yeah, that's reasonable, but also that's not the problem here


Core defining whatever name it wants sounds typical and expected. I think the surprise is an issue occurring with a :refer-clojure :exclude plus a defrecord by the name of MapEntry in a different namespace than cljs.core .


Obviously, we need more details to describe the problem precisely though.


Anyway, for anyone interested, I don't have the time to write an issue right now, but this would fix the problem with Schema. With that patch applied, our production 10k-line ClojureScript application builds without warnings and seems to work fine.


Ah I didn’t realize syntax quote wouldn’t do the qualifying automatically there.


@mfikes, should I create a JIRA issue about this or what's the way to proceed?


@U1NDXLDUG Yeah, I was wondering about that. It sounds to me like something an issue would be logged for.


I was wanting to try to do a small reproduction case, but haven’t gotten around to it


Well, for whatever it's worth, I posted it here:


Thanks for logging it


@U1NDXLDUG actually that’s what I needed, thanks, easy to fix


I put together thoughts from @noisesmith @dchristianbell @jonpither and @mccraigmccraig on deciding between separating a clojure server/api codebase from a clojurescript client/ui or keeping them both together. Any more thoughts around the subject?


Another vote for multiple modules in single repo from me. It really is the "best of the both worlds" solution: you can develop the frontend and the backend separately, but you don't have to face the friction of having multiple repos.


@U1NDXLDUG Been discussing around… Would you mind describing a bit more the friction issues of having multiple repos? Thanks a lot!

Garrett Hopper17:03:59

Is there a way I can run a cljs repl in the background? I want to run a dev server with automatic reloading, but I don't want it taking over my current repl.


@ghopper the simplest way is component (or something like that) + socket REPL


Short question: Shouldn't the process shim (if we request it) always come first? First preload that is?


is there like a library that lets you query hiccup structure (vector) using selectors like syntax? basically "jquery for hiccup"?


@ag yes, hickory and enlive can both do this


enlive doesn't use hiccup by default, but it's the one I've used the most, it's good


(I used it for web scraping)


@deas there’s no such guarantee no


@dnolen Asking because I am seeing an issue caused by custom :preload relying on process which in turn comes into play too late.


like I said doing that is not really supported


@dnolen Got it. Any reason for not allowing user to specify order of preloads or at least make process come first when using :process-shim?


order of preloads is respected far as I know, but dependencies between is not


there’s really not a good way to do what you want, just supply :preloads yourself manually


Other than that, it seems 1.10.126 miscompiles react-dom (16) from node modules for me. (DCE issue). 1.9.946 does not expose this behaviour and does it correctly - at least wrt react-dom/index.js. Should I bother coming up with a bare bones repro?


@deas first you have to determine we can do anything about that


if it’s truly DCE then it’s not our problem


maybe, or for us as a community to look at the problem first 🙂


as I said in the very beginning :npm-deps ain’t going to fix itself - it’s going to take lot of work from everyone