dot-clojure: a personal deps.edn with the REPL aliases you would otherwise assemble yourself

This is one person's deps.edn, published to be a worked example

dot-clojure is a personal .config/clojure/deps.edn file, also usable as .clojure/deps.edn, providing clj aliases drawn from a variety of projects. The author explains the reason for publishing it in two parts. The first is practical: it is published to GitHub so all his computers stay synchronised. The second is the reason a reader cares. The file is published as a range of examples that folks new to the Clojure CLI might find helpful. That framing matters, because it tells you what kind of artefact you are looking at. This is not a library, a plugin, or a supported configuration format. It is one working machine's configuration, published with examples in the comments of the file itself. The repository layout backs this up. The root holds deps.edn, a deps-clr.edn, a bin/ directory, a tools/ directory and a .cljconf/ directory, and the README notes there are additional examples in the comments in the deps.edn file itself. The licence is Apache-2.0, the default branch is develop, and the last push was on 2026-10-19, with releases v1.5.0 on 2026-10-05 and v1.4.2 on 2026-05-07.

The version pin targets a Clojure alpha, and the README says so twice

Two statements near the top of the README set expectations before you copy anything. The first is that the default Clojure version in use here is 1.13.0-alpha9, and the second is a strong recommendation to ensure you have the latest Clojure CLI installed, with a note that the latest Clojure CLI was 1.12.6.1673 on September 7th, 2026 when the file was last updated. The distinction between a Clojure language version and a Clojure CLI version is the thing to hold onto. The CLI is the tool that reads deps.edn and resolves dependencies, and it is what determines whether the aliases in the file work at all. An alpha language version is a different question, and one the author has made a deliberate choice about. For a reader who wants to learn the CLI, this is a positive, because the file exercises a real configuration rather than a minimal one. For someone wiring this into a production build, it is a red flag, and the author says as much in the caveat that follows. The README also records that the file has been cleaned up and that a lot of aliases no longer used were removed.

The :repl alias and bin/repl wire up Portal, CIDER and rephrase

The main alias is :repl, which starts various combinations of REPL tooling through the Clojure CLI REPL. A REPL is started with clojure -M:repl, with additional aliases bringing in tooling such as Portal, rephrase and CIDER nREPL middleware. There is also a bin/repl bash script that runs `clojure "$@" -M:1.13:allow-attach-self:portal:test:cider-nrepl:rephrase:repl` to start an nREPL server with CIDER middleware and then a client to that server.

Portal is available through it, and if clojure.tools.logging is present it is patched to tap> all log messages for Portal, along with logging4j2, the author's log4j2 wrapper. One alias in that chain has a specific purpose worth knowing about. The :allow-attach-self alias sets the JVM property -Djdk.attach.allowAttachSelf for JDK 21 and later, so that nREPL can stop evaluation threads. That is a JDK version interaction, not a Clojure one, and it is the kind of detail that silently breaks a REPL workflow when you upgrade your JDK without reading the alias list. The REPL configuration also comes with its own folder of personal settings: the .cljconf/org.clojure directory holds personal configuration based on the examples that ship with the Clojure CLI REPL project, including logic to wire logging into Portal if it is on the classpath. The README notes this replaced the author's former custom REPL startup code.

Global tools are being migrated out of aliases and into the tools directory

The .config/clojure/tools folder, also usable as .clojure/tools, holds the tools installed globally via the Clojure CLI, and the README explains the policy behind it: as global tools are added, the corresponding aliases are removed. This is a deliberate architectural direction rather than an accident of organisation. The older README section described tools as installed with clojure -Ttools install and usable via clojure -T with the tool name, and the author's note in that section says he removed antq from it because he switched to installing antq directly via bbin as he adopts more Babashka-based tooling. There is a second global tool directory, .cljconf/org.corfield, which holds the author's deps-new.edn defaults and selects Babashka for builds and LazyTest for the test runner. Two different Babashka-adjacent tools are in play, and the distinction is worth holding on to: Babashka is selected as the build tool inside deps-new.edn, while bbin is the mechanism for installing command-line binaries. The author also says he has started using in-1 to install command-line tooling since it makes binaries easy to manage locally, and that this is how he installed bbin.

The tooling sections are shrinking because the author is moving to Babashka

The Basic Tools section of the README lists project generators and scanners, and it carries an honest note about its own future. The author says he thought he might continue to add more tools to that section over time, but he is switching more to Babashka-based scripts and using bbin to install them, so he is no longer sure that is true. The entries themselves show two generations of project generation. The newer `new` tool is the latest version of deps-new, which creates new CLI and deps.edn projects, and it uses a different and simpler templating system to clj-new, which is why it does not recognise Leiningen or Boot templates. The older `clj-new` tool creates projects from Leiningen and other templates and can produce either a deps.edn-based or a lein-based project depending on the template. A software composition analysis scanner based on the National Vulnerability Database also appears in the list, clj-watson. The practical consequence for a reader is that this file documents a moving target. The Basic Tools section may not look the same in six months, which is exactly the point the author makes in the caveat about not making an effort at backward compatibility.

The testing aliases cover test.check, LazyTest, a forked runner and Splint

The alias section covers deployment and testing. For deployment, :deploy pulls in and runs a recent stable release of Borkdude's deps-deploy, deploying the specified JAR file to Clojars based on your pom.xml and the CLOJARS_USERNAME and CLOJARS_PASSWORD environment variables. It is meant for the case where you do not have a build.clj file. The testing aliases are the more interesting part, and they show a preference for expressive tests over the standard library. The :test alias adds both test and src/test/clojure to your classpath and pulls in the latest stable version of test.check. The :lazy alias adds a recent stable release of Lazytest, and it can be used as clojure -M:test:lazy to run just LazyTest tests, or clojure -X:test:lazy:runner to run both LazyTest and clojure.test tests, the latter through the author's fork of Cognitect's test-runner project. The :runner alias on its own pulls in that same fork of test-runner and runs any tests it can find. The :splint alias pulls in and runs a recent stable release of Splint on your project or on specific files. The pattern across all of them is the same: an alias that resolves a dependency and runs a tool in one step, so a developer never has to remember a coordinate.

The caveat and the recommendation against using it as a shared config

The README states the limitation plainly and it should be read before any copy and paste. Since this is a personal file, it may make assumptions about the author's own environment, and no effort is made at backward compatibility, and aliases may be added, deleted or changed as they benefit the author personally. The README closes that thought with the phrase Caveat Programmer. It then does something most personal configuration repositories do not do. It points you somewhere else for the real thing: if you want a well documented, well maintained alternative that actually tracks versions of tools, the author recommends the Practicalli Clojure deps.edn project instead. That recommendation is the single most useful line in the file for an adopter. The difference in approach is about maintenance guarantees rather than about content. dot-clojure optimises for one person's workflow and changes freely, while the alternative is positioned as version-tracking and documentation-oriented. The project also publishes tagged releases, v1.5.0 and v1.4.2 among them, and the last push was on 2026-10-19, so the personal file itself is kept current even though its contents are unstable.

Editorial conclusion

dot-clojure suits a developer setting up a new Clojure CLI environment who wants to see a real, working deps.edn with aliases, global tools and REPL configuration, and it suits people who like to read how someone else has solved their own editor and logging setup. It is the wrong choice as a shared team configuration, because the author states plainly that there is no effort at backward compatibility and that aliases may be added, deleted or changed for his own benefit, and the README itself recommends the Practicalli Clojure deps.edn project instead. Verify first that your Clojure CLI is new enough for the Clojure version the file defaults to, that you read the REPL section rather than copying the aliases blindly, and that you accept that adopting it means adopting another person's tool choices.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. README
4. Releases
5. seancorfield/dot-clojure on GitHub