Make nREPL server persist over resets

[martinklepsch]

fixes #91

Mostly inspired by how this is done in other components, tested it in the REPL with integrant.repl/reset with something like this:

 (require '[integrant.repl :as igr])
 (igr/set-prep! #(ig/prep {:nrepl/server {:port 4004}}))
 (igr/reset)

---

I also added another commit (happy to open a separate PR or remove it) but just wanted to check in about the idea: I usually start my development system via something like bb dev this will launch an nREPL server that I then connect to. I think with kit it could make sense to do something similar and only inject that component in development?

[yogthos]

I find nREPL can be useful in a deployed app as well. I often keep nREPL open when I deploy the app to dev environment in a jar for example, and then use ssh reverse tunnel to forward it locally.

[martinklepsch]

I find nREPL can be useful in a deployed app as well. I often keep nREPL open when I deploy the app to dev environment in a jar for example, and then use ssh reverse tunnel to forward it locally.

Absolutely, I didn't mean to limit this to development usage but thinking of kit as a wholistic framework it could be nice if it just started an nREPL server during development — which would be easy with this module and the .nrepl-port addition.

[yogthos]

Ah ok, yeah that makes sense. I think keeping it consistent is reasonable. From what I've seen, people tend to be split between running the app and then starting the REPL from it for the editor to connect to, and running the REPL from editor and then starting up the system in the REPL. I think controlling whether nREPL component starts up based on a flag would such as :enabled? might be the way to go here?

[martinklepsch]

I was wondering a similar thing recently: how to conditionally load components? That said I think this should be handled in the realm of system.edn rather than adding no-op flags to individual components.

I think with aero #merge, #include or similar switching on the profile.

[yogthos]

I agree, handling it in system.edn would be a reasonable way to go.