This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # announcements (27)
- # beginners (184)
- # boot (4)
- # cider (9)
- # cljdoc (1)
- # cljsrn (2)
- # clojure (208)
- # clojure-austin (1)
- # clojure-conj (4)
- # clojure-dev (20)
- # clojure-europe (15)
- # clojure-italy (66)
- # clojure-losangeles (2)
- # clojure-nl (32)
- # clojure-spec (64)
- # clojure-uk (80)
- # clojurescript (50)
- # cursive (2)
- # data-science (3)
- # datomic (17)
- # emacs (1)
- # events (6)
- # fulcro (3)
- # jobs (15)
- # juxt (5)
- # klipse (2)
- # leiningen (31)
- # nyc (3)
- # off-topic (34)
- # re-frame (2)
- # reagent (9)
- # schema (1)
- # shadow-cljs (52)
- # specter (5)
- # sql (3)
@thheller Hello, I got shadow-cljs repl working with cider after some frustration. I understand now that a node process must be started on the compiled code, before the cljs repl can be used. I am curious why this is necessary, and why cider doesn't do it automatically
This is more of a cider question and it boils down to the different Clojure runtime... historically cider has always assumed the JVM running your process also evals your code. With node this is not really true and therefore you need to add an additional step to the chain. The automatic node process launch, by the way, could be a good feature request against cider.
:node-library targets it is pretty much impossible to "run" them automatically
:node-library you are likely consuming from some other library/framework (eg. webpack, jest, etc)
node-repl is a generic way to run a node process and pretty much the only thing you need if you just want a node repl
Thanks. That's really interesting. Do you know where I can get a basic /top level understanding of the build specific REPL? I read this from the docs "Most :target configurations automatically inject the necessary code for a ClojureScript REPL." So code is injected into the compiled node script or node-library, and that somehow interacts with the nREPL that is run?
that takes your input, generates JS for it, transports it to the JS runtime, evals it there, transports the result back to the JVM and that transports it back to you
the ONLY difference is that
node-repl starts a managed JS runtime (ie. node process) for you
that is just something that you can't do with build specific REPLs since it is impossible to tell which JS runtime you are actually going to use
Are there any handy examples of ClojureScript tests based on clojure.test that read data from a file checked into the project's repository? In Clojure/Java there is http://clojure.java.io/resource commonly used to find a file's full path based upon input of a relative path name, on the classpath, but not sure what common techniques would be for ClojureScript there. It is OK if it only works for Node.js in my particular case.
you can use the nodejs fs API https://nodejs.org/api/fs.html#fs_fs_readfilesync_path_options
OK, Googling around Node.js docs helps. I can run the following in a nodejs interactive session, but not yet finding how to do the JS 'require' in ClojureScript. Any hints on how I can achieve that in cljs?
$ node > var fs = require('fs') undefined > var contents = fs.readFileSync('CONTRIBUTING.md', 'utf8'); undefined
That worked, thx. And the obvious follow-up question is how I can then do that readFileSync call? Sorry, I have actually tried a few variations of guessed interop syntax here, but I don't have the rules in head yet.
if you use regular requite you just
(def fs (js/require "fs")) and then
(.readFileSync fs "foo.edn")
Hmm, at least at a Node-based cljs REPL,
(require fs) gives an error. Not sure if it is expected to work in that context, though.
there's a little bit of nastiness around Node namespaces and
load-file - hoping to get that sorted out for the next release
(require 'fs) gives 'No such namespace: fs', but again, I might be stretching things with the REPL here. Not sure. The
(def fs (js/require "fs")) gets me where I want to go, so no worries for me if other way does not work.
but I've been doing all Node.js ClojureScript development for a month or so now, it works great
Weird. It gives that error when I am connected via a socket REPL, but not when I start Node REPL via
--repl-env node on the
clj command line. I'm not going to shave that particular yak right now.
I have been using Socket REPL with Node for a couple of weeks semi-heavily, but not necessarily stretching all kinds of weird corners -- mainly testing changes to core.rrb-vector library. This is the first time I recall seeing a difference between Node Socket REPL behavior and non-socket-REPL Node behavior.