squint-cljs nrepl eval file failing

[diegobfernandez]

Hello there. I've been experimenting with squint-cljs and everything is working well expect the evaluation of the whole file.

Here is the output when pressing <localleader>ef

; eval (file): /project/src/project/main.cljs
; (err) undefined is not an object (evaluating 'globalThis.project.main.cljs.core')

If I understand correctly this is the code that will eventually send the nrepl message to the server

conjure/fnl/conjure/client/clojure/nrepl/action.fnl

Lines 241 to 243 in 6d2bc7f

	(a.assoc opts :code (.. "(#?(:cljs cljs.core/load-file"
	" :default clojure.core/load-file)"
	" \"" (escape-backslashes opts.file-path) "\")"))

The problem is that squint-cljs is not ClojureScript 😅 and does not ship with cljs/clojure namespaces.

The solution could be another client, but since all other evaluation methods are working, I wonder if using nREPL's load-file could be a solution that works for all nREPL clojure-like languages.

[Olical]

Thanks for the report! If squint has it's own reader conditional key then we could use that but if not maybe we need to make the :cljs branch a little more delicate so it detects if we're in a squint environment or not and behaves differently.

I'll try to look at this soon!

[Olical]

Looking into this some more now and squint doesn't seem to have any sort of equivalent for load-file, so I don't think Conjure's file loading mapping can be used with it at all really. Unless you make some assumptions about the runtime you're executing your compiled Squint JS in, like if it's nodejs maybe we can access the filesystem.

I think you'll need to use <prefix>eb which sends the current buffer contents directly instead of relying on the REPL having access to the file system.

[diegobfernandez]

Thank @Olical, for the time being I've been using <prefix>eb indeed. I'll probably override my eval file key mappings for squint projects to aleviate the muscle memory effect.

I still wonder if the load-file op could be a good fit as it seems that the code is sent as part of the message, so no assumptions about runtime as the client will be responsible for reading from disk.

[Olical]

Hmm does squits REPL support that op too? 🤔 if so, we could use that. Not sure about changing the underlying op in Conjure though. This fees like it'll actually be useful for eval buffer.

Right now we ask the REPL to load the file from disk, that way if you're working on a remote machine you get the file from that remote host. You don't need it on your local host where Neovim lives.

If we went down the load-file route for Conjure for eval buffer and file we could do the same op for both but eval file reads the contents from disk and eval buffer reads from the currently loaded buffer inside Neovim.

If both work very well, in more scenarios and don't break anyone's workflow / environment it could be a nice change.

[Olical]

I think I also designed ,ef so that if your file was say 100k lines of data you could have the REPL read it directly rather than Neovim read it and cram it into an nREPL message. So it might make sense to keep ,ef with that "Neovim never sends the full contents directly" behaviour, I'm not too sure. Although that situation will be extremely rare and there's other ways around that...

[Olical]

Here's the docs on it for future me or anyone who wants to implement it on the main branch https://nrepl.org/nrepl/ops.html#load-file