CIDER 2.0: The Plan

[bbatsov]

I'm thinking of cutting one final CIDER 1.x release soon, before #3352 is finished, and then prepare for a CIDER 2.0 release. Why so?

• it feels like a good time to drop Clojure 1.8 support, given that almost no one uses it
  • we'll also be able to simplify the code related to clojure.spec
• a new major version will allows to tweak some defaults, like the ones we've recently discussed with @yuhan0
• might be a good opportunity to make bigger changes to the connection management

Ideas/concerns are welcome!

[vemv]

A breaking-ish 2.0 release sgtm and would be a good coincidence with the work I plan to do the next couple months.

If enrich-classpath gets the finishing touches it needs, it could become enabled by default.

And also I've been pondering on "merging" (literally or functionally) cider and clj-refactor. Things like cljr-slash are taken for granted in other IDEs, so users shouldn't resort to a non-core package to have it.

Same for a few other key features. Other features are more "nice to haves", but anyway, for all serious usage, developing Clojure code does involve refactoring, so "refactoring" shouldn't be some sort of second-class concern.

I'd try to do this bundling in a non-invasive way e.g. we can try to detect if clojure-lsp is in use, and not enable conflicting stuff.

And/or document more thoroughly where cider/clj-refactor and clojure-lsp clash, so that users can declare their preferences clearly.

[yuhan0]

Strongly agree about cljr-slash, in fact it's practically the only feature that I use at all from clj-refactor, after all its "dumber" refactorings were migrated over to clojure-mode.

Another nice thing I'd like to see merged into Cider would be the cljr-add-ns-to-blank-clj-files functionality and a simpler file-renaming functionality - no global AST parsing across the entire project needed, just compare the actual ns name against the inferred one and offer to fix it up in the current buffer.

Most of cljr's other features feel a bit too idiosyncratic and dependency-heavy to me - eg. pulling in the entirety of yasnippet, hydra and multiple-cursors, and I don't think it would be a good idea to merge those parts into Cider as-is.

[jmckitrick]

I've always had issues getting clj-refactor to work correctly. I'm sure I could push through it, but never had the patience. I'd love to see it work 'out of the box'.

[jmckitrick]

Take that to mean I'm willing to help test, document, and otherwise help with this feature.

[vemv]

Glad to see the positive sentiment.

after all its "dumber" refactorings were migrated over to clojure-mode.

This is a good call, and as part of the consolidation we could leave thing in just one place (I don't mind which).

simpler file-renaming functionality - no global AST parsing across the entire project needed, just compare the actual ns name against the inferred one and offer to fix it up in the current buffer.

That could easily break a project (since a ns can be referred in many places). But I agree that the AST doesn't feel scalable to most users (nowadays it's less common to have weeks-long JVM/Emacs sessions, so the fixed initial cost will be repeated once per session - very often!).

I believe a nice approach would be to create a protocol and have ~3 impls: AST, clojure-lsp (which nowadays also is a lib!), and "sed" i.e. a mechanical replacement.

Most of cljr's other features feel a bit too idiosyncratic and dependency-heavy to me - eg. pulling in the entirety of yasnippet, hydra and multiple-cursors, and I don't think it would be a good idea to merge those parts into Cider as-is.

That's a legitimate concern. Maybe the idiosyncratic parts can be left there, and the other ones migrated to CIDER. Anyway things like Hydra seem abstractable... there's no reason why ido etc couldn't serve the same purpose if the user wanted.

Let's see how refactor-nrepl goes. Yesterday I created clojure-emacs/refactor-nrepl#392 which makes useful a string of clj-refactor.el work that had been done in previous months.

---

Edit

As a quick idea, it seems sensible to:

• start bundling the refactor-nrepl middleware
• copy from clj-refactor.el the functions that don't require third-party packages, prefix them with cider-
• make clj-refactor.el's next version deprecated the copied versions, and not inject any backend middleware

[vemv]

Other "2.0", possibly-breaking features are:

• Adopt more error reporting features available in Clojure 1.10+ #3338
• Leave clojurescript in a truly working/robust state, nowadays it's a mixed bag that commonly frustrates users
  • And also, more featureful - it might be a good chance to review clojure-lsp's offering as a modular lib.

[rrudakov]

Maybe it would be nice to make CIDER work with clojure-ts-mode?

[bbatsov]

@rrudakov I think it's a bit too early for this, given that clojure-ts-mode requires some more work before we can consider it feature-complete.

[rrudakov]

@rrudakov I think it's a bit too early for this, given that clojure-ts-mode requires some more work before we can consider it feature-complete.

I think it could help to bring more contributors to improve tree sitter support for Clojure. Now it's problematic to use clojure-ts-mode for daily work, because of lack of CIDER support.

[alexander-yakushev]

FWIW, if you plan to drop 1.8, it makes sense to move straight to 1.10 as the minimum. 1.10 contains several important fixes related to Java9+ compatibility[1], so I doubt many people who use Java9+ would stay on 1.9. Besides, nothing controversial was introduced between 1.9 and 1.10 that would prevent people from upgrading.

[1] https://github.com/clojure/clojure/blob/master/changes.md#1-compatibility-and-dependencies

[bbatsov]

@alexander-yakushev Yeah, I was thinking the same thing - less than 5% of State of Clojure 2023 respondents are using Clojure 1.9 anyways. And there's nothing preventing them to upgrade, given that CIDER has required JDK 8+ for a very long time. I think we'll target Clojure 1.10 directly.

[bbatsov]

Funny enough we've done many of things discussed above without getting to CIDER 2.0. 😆 Oh, well...

I plan to think more about the roadmap for it after we have some final State of CIDER 2024 survey results. (see #3765)