Replies: 2 comments 8 replies
-
|
Thinking while typing... can we guarantee a clava REPL we design will work in every environment? Said another way: evaluating code seems inherently coupled with the JS runtime & build tools in use for a given project. Perhaps we should start with a few specific targets... Vite REPL, node.js REPL, deno or bun REPL? I think that continuing to explore how we could make modules mutable is worthwhile, as I'm not sure anyone has gone deep on that solution in practice. As a second option, we could explore more intimately coupled solutions to the specific environments that we are targeting. For instance, in the browser using a build tool like Vite, we could potentially use their hot module reloading API. Most build tools have their own HMR API, so building a plugin for Vite probably won't work for webpack or others. Curious what you think @borkdude @corasaurus-hex |
Beta Was this translation helpful? Give feedback.
-
|
Is there any news on nREPL support in the browser? I agree with #195 (reply in thread), having a decent REPL in the browser is for me on of the biggest selling points of CLJS. I've dabbled in Squint a bit and I think it's a really nice experiment, but I'm waiting for the REPL support to be mature enough so that I could |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
We need to support a REPL with clavascript and the concept of a development mode.
During development, namespaces need to be fully mutable, so vars can be redefined.
We could focus on a console REPL first, then add nREPL support.
Beta Was this translation helpful? Give feedback.
All reactions