This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2015-08-30
Channels
- # admin-announcements (10)
- # beginners (7)
- # boot (216)
- # cider (10)
- # cljs-dev (3)
- # clojure (71)
- # clojure-denmark (2)
- # clojure-italy (3)
- # clojure-seattle (1)
- # clojurescript (124)
- # cloxp (1)
- # code-reviews (5)
- # core-matrix (2)
- # cursive (34)
- # datomic (3)
- # editors (1)
- # hoplon (201)
- # immutant (2)
- # jobs (3)
- # ldnclj (7)
- # off-topic (3)
- # re-frame (19)
- # reagent (76)
While using figwheel, I’m seeing this error with piggieback dependencies. Does anyone have a set of exclusions that work with figwheel?
I'm writing a clojurescript lib, and I'm trying to figure out what the current state of testing cljs is
cljs.test has been around for a while now, but it seems cemerick/clojurescript.test is still very popular
I would love to see a working setup with phantomjs or slimerjs, been looking at repos but haven't seen good examples
@plexus: check bensu/doo
might also reconsider the testing setup for chestnut. Right now it generates a .html and .js file just to have a "runner" for phantomjs. I was never really happy about that
Into my second hour of fighting library dependency hell. Weird error messages, missing classes in libraries I didn't even know I was using… This is something that is becoming more and more of a problem as the number of libraries grows and as we use more and more of them in our projects.
And the breakage is completely unexpected. As in "upgrade ClojureScript to a newer version" -> "observe how timbre (used by sente) breaks with "Could not initialize class clojure.tools.reader.edn__init", but only if you run in dev env. Remove leiningen from dependencies and this particular breakage goes away.
@plexus: I think including leiningen as a project dependency in chestnut is a risky idea. I can trace most of my problems to leiningen and its deps.
@martinklepsch: @dnolen: loving the PR
I am failing to compile clojurescript and i'm getting at cljs.util$topo_sort.invoke(util.cljc:168)
repeated a lot of times in my stack trace. Should I look for a cyclic dependency? Are there known causes of this?
@escherize: cyclic dependencies aren’t supported, it should be able to catch cases like that but there may be edge cases stilll
@escherize: do not
how do you properly use a static method like this one: http://google.github.io/closure-library/api/source/closure/goog/date/date.js.src.html#l1315 — I got it working with (:import [goog.date Date])
and (Date/compare …)
but this still causes warnings
@martinklepsch: there’s no such thing as static fields in JS so it just isn’t supported
ah yeah, static as in Closure’s “static”. that .
makes sense, thanks!
(http://google.github.io/closure-library/api/class_goog_date_Date.html#Date.compare)
@dnolen: err, actually that Date.compare
call isn’t working. That was meant to be used with :import [goog.date Date]
right?
oh wait a sec
ignore me
@plexus: Hmm. I wouldn't know, because leiningen templates aren't updateable… I guess I'll check the source, then (even lein new stopped working for me recently). But I'm glad to hear that — leiningen has a ton of dependencies, often using older versions.
@jrychter: What do you mean they aren't updateable? You once the template has been used? Because you can just push up a new version of the template.
@dominicm: I think he’s referring to the fact that once you created your project with lein new
you cannot easily upgrade to upstream improvements
@martinklepsch: Ah right. Yeah, that's true, nothing stops you from doing a new project, and migrating your changes.
Well once your project has reached some size its definitely not straightforward anymore
No, not at all. Depending on the template size you could just manually apply the changes to the template.
@martinklepsch, @dominicm: that is exactly what I meant. I have a fairly large project, and the template has been heavily modified (to start with, I don't use Om, but Rum). There is no way to keep in sync, and starting with a fresh project is not an option.
What I'm doing now is looking at what newer versions of chestnut do (specifically the way figwheel is started) and porting the changes back into my application.
A general observation: I came back to a project after 3 weeks and tried to update some dependencies. It broke in so many ways I can't even count. I'm spending hours bisecting dependency versions, adding :exclusions and staring at dependency trees. And most of the breakage is not even in the app itself, it's in the build system. It's worrying how brittle it is.
I guess this shouldn't be in the ClojureScript channel, as it isn't something ClojureScript-specific. But ClojureScript makes building significantly more complex, especially with figwheel.
@jrychter: I understand your frustration but you aren't using figwheel as prescribed in the readme or quick start
@jrychter: Last week I got rid of leiningen cljsbuild and am just calling clojurescript's API + fighweel in a .clj
script file. I can highly recommend it. You'll understand what's going on and see a ton more output which helps if something goes wrong.
@bhauman: oh, certainly not. And my frustration isn't directed at any single thing — I mentioned figwheel as a complicating factor, because your app needs to start something in addition to lein-cljsbuild, but I didn't mean to blame it.
I still use leinigen for getting dependencies and setting the classpath properly. So still have all the convenience of that.
BTW, the main culprit in my case was that leiningen was included as a dependency (older chestnut templates used to do that, in order to be able to launch figwheel). Removing that solves most of the weird problems.
Well, that was my observation: a larger ClojureScript+Clojure application will have a lot of moving pieces, and our build systems are becoming complex and brittle.
As another example, I still haven't managed to figure out why adding refactor-nrepl to :plugins
causes problems in Transit (https://github.com/clojure-emacs/refactor-nrepl/issues/93) — it's weird, unexpected, and really difficult to nail down. The issue has been closed, but it isn't really fixed, I just haven't had time to dig into it yet.
@jrychter: yep that stuff is real and complicated. Nrepl scares the crap out of me. I don't use it and I stick with inf-clojure and keep the moving parts small. Keeping the moving pieces small has been a big help and David keeps saying so. This doesn't help your immediate needs but ...
@bhauman: well, it certainly isn't your fault (you should be thanked for the excellent piece of software that figwheel is!). But it worries me actually that some of the main developers use hand-crafted build systems. This means that popular solutions (like lein-cljsbuild) do not get the attention they deserve. It's also kind of a vote of no confidence.
What's really frustrating is that we would all like to spend zero time on build systems, but we sometimes have to. Even worse, if a problem happens, it gets in the way badly (your app doesn't build anymore). And since things like leiningen are so complex, it's very difficult to even report problems properly.
Then again, I've seen plenty of issues regarding the jvm params passed by leiningen. So maybe we should just blame the jvm! 😛
This is why in the meantime the way forward is probably custom build scripts where you understand every line. Because in reality we are not doing anything that complex. Starting a server, Building on change, staring a repl, etc. writing a script for this is about as much code as the project.clj
@jrychter: boot worth checking out — especially for clojurescript work — if you haven’t already. There is a #C053K90BR channel with quick responses to questions and issues.
@donmullen: I've been meaning to check out & try boot, is it significantly better than leiningen? Or just a different approach?
@donmullen: This seems like a real downer https://twitter.com/nikitonsky/status/636192947168485376
@donmullen: I'll make sure to check it out after this project is done.
@bhauman @jrychter: fwiw I really the think the value of Leiningen primarily the development of libraries. It simplifies contribution and distribution. It’s also good for newbies.
but for serious projects I just wouldn’t bother with anything other Maven (now very mature very well maintained) and some scripts - the pain of XML is nothing compared to pain of debugging an opaque build system.
@bhauman: There should not be significant difference between boot-cljs and cljsbuild times. Thought there is one workaround which might cause long compiler times in one case...
My results are here: https://github.com/adzerk-oss/boot-cljs/issues/93#issuecomment-136192044
@bhauman: ha, I think people want to believe all this stuff is going to help them build large applications. But large applications benefit most from something that's transparent and unsophisticated IMO.
@zentrope: that’s what I would do and recommend. But I’m also pretty much all in with Cursive which automates a lot of stuff for me.
dnolen: I like the idea of simple scripts, but library deps starts to add back in complexity. Perhaps maven could just be a command invoked by scripts, eh?
I just mean if you wanted to pull in Om, say, what do you do if you don't want to just store the libs in your repo?
If I want to write a script to build a project (bash or even clojure), I still have to account for pulling in dependencies. So, there has to be a file to list them. Or I check them into ./lib.
@zentrope: ok, yes, I said “Maven + scripts” is what I would do for applications above
Making maven as just another "system utility" to be scripted is the innovation over using maven as the main scripting engine?
right and the tradeoff is that building your thing is now less portable (Windows, shell differences)
for applications, so what, you should be in control of the machines you’re deploying to
I tend to like separating "project management" and "building the source" into separate issues, but I suspect I'm a minority of 1 in that. I'd rather lein be good at building artifacts, and something else do deployment, etc.
@zentrope: I'll gist my scripts/setup that I just did last week (nothing fancy) to move away from leiningen/cljsbuild and go with a script setup. It still uses leiningen to get dependencies.
rauh: That'll be nice to see. Yes, going "full script" is appealing to me, but snagging deps is the harder part.
I remember lein 1 used to actually pull deps locally so you could see them, which has its virtues, I suppose.
@dnolen: :check-types :warn
as a compile option with :optimizations :simple
gives me a NPE. I'm not sure if it's Closure's fault
@rauh: the compile time checking stuff is under development. As usual patches welcome.
rauh: I wonder if it's possible to use the underlying pomegranate lib to avoid lein completely.
Are there other large publicly available cljs projects besides circleci’s frontend?