cider 2022-09-13 | Slack Archive

jrychter06:09:27

Hmm. I've just (painfully) migrated my app to figwheel-main and I'm trying to figure out if I can start using a ClojureScript REPL after all these years with CIDER. But the standard connect- functions complain about being unable to find build-id.cljs.edn files, which is correct, because I don't have any. My figwheel-main is started manually from Clojure code. I start the Clojure REPL using leiningen (launched from a Makefile), then connect using cider-connect, then run init code which does a bunch of things and starts figwheel at the end. Any suggestions/directions as to where to look next to connect?

jkxyz06:09:33

I think you could use cider-connect-clj and then call figwheel.main.api/cljs-repl

magnars07:09:54

That would still look for build-id.cljs.edn

magnars07:09:40

No, maybe I'm mistaken.

jkxyz07:09:53

As long as you're running it from the same process which has started the build, it should find it in the registry

magnars07:09:17

(figwheel.main.api/start build)

would certainly look for it, but

(figwheel.main.api/cljs-repl build)

connects to an existing build, so that might circumvent the problem.

magnars07:09:36

Another solution would of course be to add the .cljs.edn-file, but I guess you have your reasons to stray from the defaults.

jkxyz07:09:44

It should, yes. You can also configure CIDER with a custom REPL type for your project so that you can just run cider-connect-cljs and it will initialize the CLJS REPL for you

jkxyz07:09:56

I would probably go with the approach of setting up the build EDN files and launching Figwheel as a separate process from your main Clojure app. It seems like a nice idea to have everything in the same process but you have to add a lot of CIDER-specific configuration to get it to "just work"

jrychter08:09:00

It's a complex app and there are a number of init steps that need to happen (things like database connection, mount initialization, migrations, etc), and I'd much rather start figwheel from inside the init function. I am using figwheel.main.api/start to start the build and configuration is supplied to that function. If I have to, I can move this configuration to a file, but… well, it seems rather strange to rely so heavily on things being stored in a single file with a "magic" name.

jrychter08:09:55

Also, I'm guessing CIDER needs that file just to parse it and get the port number?

jkxyz08:09:17

It seems like CIDER doesn't have a specific REPL type for connecting to a running figwheel-main build. It expects to call figwheel.main/start and uses the build files to find the build name to pass to that function. Since you're calling start already, to get a CLJS REPL you need to call figwheel.main.api/cljs-repl inside of a Clojure REPL to "upgrade" it. Then you can run cider-set-repl-type to mark it as a CLJS REPL (so that eval works correctly in CLJS buffers). To simplify things, you can configure something like the following in .dir-locals.el:

((nil
  (cider-custom-cljs-repl-init-form . "(do (require 'figwheel.main.api) ((resolve figwheel.main.api/cljs-repl) "build-id"))"
  (cider-default-cljs-repl . custom)))

https://docs.cider.mx/cider/cljs/configuration.html#defining-custom-clojurescript-repl-types That lets you start your regular Clojure REPL, and then run cider-connect-cljs to launch the CLJS REPL. The benefit of magic file names is that it's a convention that makes it work more easily with tooling without manual configuration 😄

jrychter08:09:06

Hmm. Very confusing. I might just postpone this — ClojureScript REPL have been so problematic that I've never used them for the last 7 years or so, which means I can get around without them for a while longer 🙂

jkxyz08:09:28

There are infinite ways to setup your REPL and tooling so I've found it helps me work faster if I just stick to the default approach 🙂 FWIW I've had no problems with ClojureScript REPLs for a long time. But I've used the above approach before with success

🎯 1

2022-09-13

Channels