This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # beginners (229)
- # cider (54)
- # cljs-dev (187)
- # cljsrn (1)
- # clojure (187)
- # clojure-dev (5)
- # clojure-italy (31)
- # clojure-losangeles (1)
- # clojure-russia (3)
- # clojure-spec (76)
- # clojure-uk (29)
- # clojurescript (94)
- # cursive (18)
- # datascript (8)
- # datomic (26)
- # docker (6)
- # emacs (19)
- # figwheel (6)
- # fulcro (41)
- # garden (1)
- # graphql (1)
- # hoplon (33)
- # jobs (1)
- # jobs-discuss (1)
- # lein-figwheel (14)
- # leiningen (7)
- # nrepl (10)
- # nyc (1)
- # off-topic (2)
- # onyx (2)
- # parinfer (25)
- # portkey (6)
- # powderkeg (1)
- # protorepl (1)
- # re-frame (14)
- # reagent (14)
- # shadow-cljs (31)
- # spacemacs (3)
- # test-check (33)
- # uncomplicate (1)
- # unrepl (40)
- # vim (5)
- # yada (16)
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)
goog.date.Date 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
Although I guess in the case of
goog.date.*, https://github.com/andrewmcveigh/cljs-time/blob/master/src/cljs_time/extend.cljs 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?
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.)
@frankie You can also mess re-bind this map, I suspect to squelch https://github.com/clojure/clojurescript/blob/master/src/main/clojure/cljs/analyzer.cljc#L122
@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
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
@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.
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.
Ah, thought I could share a query view. Anyways, just search for recent “mapentry” cljs Jiras
@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.
no idea what the problem is, just saying we take core names when we see fit, we don’t coordinate 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
Anyway, for anyone interested, I don't have the time to write an issue right now, but this would fix the problem with Schema. https://github.com/miikka/clojurescript/commit/d1292babf870040a0470cd2916c71a2e492fd437 With that patch applied, our production 10k-line ClojureScript application builds without warnings and seems to work fine.
@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: https://dev.clojure.org/jira/browse/CLJS-2621
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. https://gist.github.com/leontalbot/cc1ee6ddf57e840b335d700f38f02a72 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!
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.
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"?
enlive doesn't use hiccup by default, but it's the one I've used the most, it's good
@dnolen Asking because I am seeing an issue caused by custom
:preload relying on
process which in turn comes into play too late.
@dnolen Got it. Any reason for not allowing user to specify order of preloads or at least make
process come first when using
there’s really not a good way to do what you want, just supply
:preloads yourself manually
Other than that, it seems
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?