Clojurians Log v2

in fact, since they are just being used for side effects, the files they are in don't need ns forms, and you could use load instead of require

(that's not really a great design choice, but it would emphasize the role of that file)

Its also important to remember that the standard library has a policy of "if you give the wrong thing, who knows what will happen?"

If you use the map as a function, you get an error as well. That's what I do when I want it to fail if not a map

Granted, there's an off chance a different type also can be used as a function of one argument, but that's rare.

Good morning Clojurians, have a question, if I had aliases with the same name in the global and project deps.edn, do the extra-deps get merged or replaced? For example: ~/.clojure/deps.edn:

{:deps {org.clojure/clojure {:mvn/version "1.10.1"}}
         :aliases {:dev {:extra-deps iced-nrepl/iced-nrepl {:mvn/version "1.1.1"}}}}

{:deps {org.clojure/clojure {:mvn/version "1.10.1"}}
         :aliases {:dev {:extra-deps com.wsscode/pathom {:mvn/version "2.3.0-alpha17"}}}}

My understanding that the project level is more specific, so it will replace the "root" level.

Ok, that makes sense. Wish there was a way to merge, or globally include deps for :dev alias.

I believe these things (and more!) are being discussed in #tools-deps 🙂

Things akin to merging etc...you can always ask there if you want to query something 🙂

For the record, (indeed) it seems like it does a shallow merge: https://github.com/clojure/tools.deps.alpha/blob/85d24dfbd6ef7221bc5a8cc63c1b0b16da828c52/src/main/clojure/clojure/tools/deps/alpha.clj#L135

@pavlos, thats interesting, I did not know about tools.deps.alpha. I am assuming that it will be part of the clojure once it is released?

You're already using it, it's what drives deps.edn files 😉

Not sure if it's a recommended approach but, as a workaround, you might be able to "simulate" the behaviour you want by using qualified keywords as alias names, e.g. https://github.com/practicalli/clojure-deps-edn/blob/65a48e1547d289a3d647d9f32bf3d2cc7fe8d5d3/deps.edn#L117 uses :env/dev In which case you could load the equivalent of clj -M:env/dev:dev in your REPL and have the dependencies of both aliases (I haven't tested it but I think it should work)

I agree, it would work, but the challenge is with shadow-cljs. Although there may be command line arguments that I can use when starting shadow-cljs.

I really should rename some of the aliases in my dot-clojure deps.edn file so they don't collide with common names used in projects. @jr0cket’s approach is better there since he uses qualified alias names in his dot-clojure deps.edn file so they are less likely to collide. :dev is probably my worst offender.

As mentioned, I use :env/dev and :env/test for the user wide alias. I find qualified aliases also provide more context, so it's easier to remember what the alias does.

I just updated my dot-clojure file to have :dev/repl to avoid conflicts (`:dev` still exists and is the same code, because it'll take a while for my muscle memory to catch up!).

(and my :dev/repl alias now works with Figwheel Main and can be used in combination with Reveal!)

@seancorfield, do you use Figwheel? What about shadow-cljs?

I have used Shadow a bit, when I was hacking on Chlorine (the Clojure package for Atom). I'm very allergic to JavaScript so I want something less node-adjacent than Shadow.

This week I started using Figwheel and I really like it. And re-frame.

It seems like shadow-cljs is closer to deps.edn, I thought it was simpler? But I do see what you mean, most of figwheel is in clojure.

Although shadow-cljs can be used as a Java library, that's not the primary supported approach and folks are just like "Embrace Node.js! It's fine that Shadow uses npx/npm!" but I really don't want to go into the JS swamp if I can avoid it and Figwheel seems to keep me further away from that swamp 🙂

FWIW going with shadow-cljs does not mean that you have to use NPM in your projects. It just means that you can use NPM to install shadow-cljs itself, that's it.

Has anyone used travisCI with with the clojure command line tools instead of leiningen? It keeps trying to run lein deps on my builds

@p-himik It means I have to have node etc installed -- which I don't want.

I don't know how much more clearly I can say "I do not want node.js on my machine!" 🙂

@ggfpc12495 Any reason to use TravisCI rather than CircleCI?

Well, I chose shadow-cljs, because it was so active and popular (not the best way to make a choice) but looking at figwheel, it is a bit newer (first commit in April, 2018) and it looks like Shadow first commit was in October 2015!

I just use it because it's really easy to configure with github, would you recommend switching?

And it's free for private repos for students, at least it was when I first started

Figwheel commits are more Clojure like, it seems more stable.

CircleCI is much more Clojure-friendly (the company uses Clojure). Don't know about the private repo integration tho'. There's also GitHub Actions -- which is what most of my project use now...

@seancorfield It wasn't an attempt to persuade you - it was an attempt to convey to others that Node won't "pollute" your projects (your statements above can be read as implying the opposite).

For example: https://github.com/seancorfield/next-jdbc/blob/develop/.github/workflows/test.yml

@p-himik Fair enough. Every time I mention anywhere that I'm using Figwheel, everyone immediately suggests Shadow and then seems to want me to justify why I'm not using Shadow. It's a bit annoying.

@seancorfield did you notice reduction in start up time?

Start up time of what?

I'll take a look, thanks!

For figwheel to startup. For shadow, from the time I type in shadow-cljs watch main to the time it all compiles it takes about a minute. When I am exploring projects, waiting a minute is annoying, I wish it was faster.

@timofey.sitnikov Just in case, if you switch between the projects often, you can use the server mode to reduce the startup time: https://shadow-cljs.github.io/docs/UsersGuide.html#_server_mode

@timofey.sitnikov I tend to start a REPL and leave it running for days (or even weeks) so the startup time of the REPL doesn't matter to me. I've had clojure -M:reveal:fig:build:dev (a combination of the Figwheel aliases and my own dot-clojure stuff) running since Tuesday on my laptop 🙂

Figwheel-main works for me, its simple to use and I dont need the features or added complexity of shadow-cljs, especially configuring the projects. Figwheel-main has a nice template to get started and as Sean mentioned, startup time is almost irrelevant during development. Figwheel-main recently added bundles for npm packages, so I'd probably look at that first before changing to shadow-cljs. Nothing wrong with shadow-cljs, its just not what I am familar with and I dont see the need to adopt it as yet. I might try shadow-cljs one day, but dont have any motivation to do so soon. Much more likely to spend time learning re-frame a bit more, as I have tooling that works already.

@seancorfield, Understand, that makes sense.

@jr0cket, the words simpler resonate with me, I am a neovim/tmux/terminal type of a guy, love to keep things simple and minimize the abstraction layers. I will have to give figwheel a try.