FAQ

My IDE/editor doesn't automatically pick up formatting-stack's changes, giving me an annoying prompt

Fix on Emacs: (global-auto-revert-mode t)

formatting-stack.core/format! is not formatting files I expected to be formatted

• By default, format! will only process files that are in your Git staging area. This is for safety, and other reasons hinted at the README.

As a tip, generally it can be good practice to carefully pay attention to what is in the staging area, and what not. Else it's unlikely that the Git commits we deliver will be atomic, and meaningful.

Of course, you are free to build your own 'stack' of defaults, supplying strategies that will format more files per invocation.

I'm seeing No implementation of method: errors in my application code

Eastwood and refactor-nrepl achieve their accuracy via tools.analyzer, which works by performing evaluation of code.

It is a known problem that evaluating protocols and defrecords in an unlucky order can cause No implementation of method: errors.

However this problem can be addressed!

There are various approaches that work:

• move protocols to a different source path, that is seldom reloaded
  • if you use tools.namespace.repl, exclude this source path from your refresh-dirs
• move protocols to a different project/repo, that is never reloaded at all
• Don't use defrecord, favoring reify and metadata-based protocols extension instead
  • utils.modular abstracts over the latter.

In our experience, reify / utils.modular are rock-solid approaches. Internally, formatting-stack uses utils.modular, and developing formatting-stack itself is 100% free of this nuisance, even when we use protocols extensively.

I don't like this indentation

Genereally, formatting-stack doesn't introduce any creative formatting: it merely applies cljfmt, which in turn follows quite closely the Clojure Style Guide.

It's obviously a good goal to adhere to standards and majorities.

If you're unfamiliar with the traditional Lisp indentation, as standardized by cljfmt/clojure-style-guide, you'll likely end up finding that having fine-grained rules which distinguish macro and function indentation in fact makes code more readable

It is frequently useful to be able to distinguish between functions and macro at a glance, particularly when performing code reviews.

I disagree with a certain linter

You are free to configure them (e.g. change max column count from 130 to 80) or completely remove them.