I’m happy to report, that after an almost entire year of development
clj-refactor.el 3.0 is finally
out! Without a doubt that’s the most significant release the project has had in years, even if you probably
won’t be able to tell this by reading the modest release notes.
Somewhat ironically, we also failed to achieve the main objective we had for this release - namely restoring the dependency hot-loading functionality, which has been broken ever since JDK 9 was released and the new module system wreaked havoc in our
old implementation of the functionality. So, why the major release then?
Well, those of you who monitor the project closely know that it wasn’t getting a lot of love in the past several years.
Even though I’m one of the maintainers of the project, I never really used it much and I wasn’t particularly invested in it.
I just had way too much work with nREPL, CIDER and Orchard to be able to dedicate a lot of time to another relatively big project.
Still, I’d be reviewing PRs, cutting new releases occasionally and making sure that
clj-refactor.el mostly works.
This year, however, there was a surge of contributions to the project that finally pushed it forward in significant ways.
Most of those contributions, however, happened in the underlying nREPL middleware - namely
refactor-nrepl 3.0 is also out and you’ll notice that the changes there
are significantly more and much deeper. It’s safe to say that’s the biggest release since version 2.3, which was released somewhere in 2017 if memory
serves. The codebase is now much cleaner, leaner and faster. The test suite got a lot of improvements. While there’s no new functionality
in this release, a lot of things are significant better than they used to be and that’s a big deal.
Note that the 3.0 version number doesn’t really imply any breaking API changes
at the nREPL level this time around. It mostly reflects the massive internal
changes to the codebase (e.g. the code dealing with namespace cleanup was
completely reorgnized and slimmed down significantly). We are well aware of the
refactor-nrepl is used by many nREPL-powered programming
environments today and we’re very careful when it comes to breaking changes
there. I’m hoping that most users will experience a very smooth upgrade the
I won’t be going over any of the technicalities of what was improved in
refactor-nrepl, as the release notes for both
releases are quite detailed. I’ll just mention that I’m very excited that the projects are finally gaining some traction and I hope that it will
last. I find these two releases to be a great example of the power of open-source - anyone can push a project forward if he has the will and the energy to do so.
These particular releases were largely carried out by vemv, who has been helping a lot recently with all sorts of CIDER-related projects.
vemv receives a big “Thank you!” from me!
So, what does the future has in store for the both projects? Well, we still have to bring back hot-loading, but there’s no shortage of
ideas for what we can improve. Probably down the road we’ll decouple
clj-refactor.el releases from
refactor-nrepl releases, as it was
done in CIDER a couple of years ago. More importantly, though, we’d like to show that we haven’t reached the limit of what one can do with
a purely (mostly?) REPL-powered approach to refactoring. We see that with the rise of
clojure-lsp and tools like
clj-kondo some people
are starting to question the tradional Lisp ways, but we remain convinced that they are just as powerful and as relevant as they have always been.
And as simple and elegant as Lisp.
That’s all from me for now. In the REPL we trust!