IIRC, you should be able to do npm install on the folder where joyride script is and use libs.

https://clojurians.slack.com/archives/C03DPCLCV9N/p1665506255005339

@UC1DTFY1G what about clojure dependencies? I’m trying to use js-interop

js-interop should be fine. AFAIK, clojure deps aren't supported (except the ones bundled with sci) @U0ETXRFEW

What exactly are you asking for? Joyride already has the same JS interop as ClojureScript. You can require the VS Code API, Node APIs, and Node modules installed in the same folder or some parent of the folder your script is in.

(require '["vscode" :as vscode]
         '["os" :as os]
         '["./my-lib" :as my-lib])

(vscode/window.showInformationMessage 
 (js/JSON.stringify  #js {:os (os/platform)
                          :timestamp (.getTime (js/Date.))}))

; Pops up a toast message showing something like
;  {"os":"linux","timestamp":1670389172820}

Hey @U90R0EPHA - thanks - just a personal preference/familiarity with js-interop vs the default clojurescript interop (mostly I use js-interop because I’m under the impression that the advanced compiler can cause property rewrite issues if you do the standard (.- syntax)

Well your joyride code won't be going through advanced compilation. So you are free to do whatever variant you prefer, without worrying about rewrite concerns.

You can drop the source code of js-interop into the joyride/src folder and use it from there. As long as it doesn’t depend on something that Joyride does not include.

Js-interop is part of nbb and we can include it in joyride as well, if people like it. I think we should make such things to be lazy loaded so it doesn’t impact startup time when people are not using it

Do we have any other example of lazy loading things in Joyride that whoever implements this could look at. Or is there a pattern in nbb to follow?

In nbb we compile libraries as separate modules (through shadow). Then when a namespace related to the module is loaded in SCI, we lazily load the .js file that shadow produced

I think shadow even has something for lazy loading, but I didn't use that. - might be useful but didn't look at it. In joyride this would just be to use js/require on that .js file

@U0ETXRFEW - I just tried putting applied-science in src - I think it relies on require-macros which I’m guessing isn’t supported in sci. later today I can try compiling it to js with shadow and then requiring that.

OK - I tried compiling js-interop with node-library as target but it doesn’t seem to work correctly.

;; shadow-cljs configuration, for development purposes only
{:source-paths
 ["src/main"
  "src/test"]

 :dependencies
 []

 :builds
 {:test1
  {:target    :node-test
   :output-to "out/shadow-1.js"
   :ns-regexp "-test$"
   :autorun   true}
  :test2
  {:target           :node-test
   :output-to        "out/shadow-2.js"
   :ns-regexp        "-test$"
   :autorun          true
   :closure-defines  {applied-science.js-interop-test/advanced? true}
   :compiler-options {:optimizations :advanced}}
  :usage
  {:target :browser
   :output-dir "out"
   :modules {:shadow-usage {:entries [applied-science.js-interop-usage]}}
   :compiler-options {:pseudo-names true}}
  :node
  {:target :node-library
   :output-to "out/js-interop.js"
   :exports {:get applied-science.js-interop/get}
   :compiler-options {:optimizations :simple}}}}

in nbb require-macros is handled just like regular require, maybe that would solve the problem in joyride as well... the problem you're seeing above with compiling apart from joyride might conflicts in how keywords etc are optimized, you can't make this work reliably a better option is to find out how you can compile js-interop as a module in joyride which is lazily loaded when you require js-interop

this will also make it possible to include more libs, like rewrite-clj, without affecting startup time

There's also a question about how much startup time we save. nbb needs to start super quickly, since it is used from the command line. Joyride starts as a part of something else that doesn't start in milliseconds.

yeah, but it adds up over time. and eventually people won't use your tool because it became too sluggish. since joyride is started in every window you open, I think it's important and btw, this isn't so hard

I don't disagree with you. Just noting the different constraints. Calva takes about 500+ ms to start, on my quite snappy machine, which is a bit more than most extensions (not that I have any other ”big” extensions to compare with, but anyway).

I'd be most happy if we can get the lazy loading going!

ok, what needs to happen: 1. add a module in your shadow config which contains js-interop + the sci config in a namespace, see nbb as an example. this module, on load, adds itself to the joyride context. also see nbb 2. in :load-fn when you encounter the namespace applied-science.js-interop you need to lazily load that module.

feel free to work on a PR and I'll comment on it

Awesome. @U034568PWRW, you wanna do the honors?

A useful little snippet to start a remote repl from within VSCode. The isTransient flag will make it not re-start if persistent terminal sessions are enabled.

Now, if I could get Calva to connect to localhost:6666 😛

Long time ago Calva used to autoconnect if it found an nrepl-port file at startup. 😃 But I think the API using Calva connect sequences that we have discussed on Github is a better direction. We could maybe add auto-connect to the config of the sequences.

I see that you say that the persistent terminal re-starts. It's probably just a choice of words and how I interpret them, but anyway, they do not restart. Or at least they are not restarting the process they rest on. They re-attach.

There's just a note in the VSCode api:

Opt-out of the default terminal persistence on restart and reload. This will only take effect when terminal.integrated.enablePersistentSessions is enabled.

I think it is referring to VS Code restart and reload.

BTW I hope my 😛 was enough to show that I know I have requested this before, and I should shut up about it already!

Hmm, I'm currently starting my SSH tunnel manually but this shows me I could do it via Joyride -- I'm already starting Simple Browser with Joyride to connect to my QA or Production Portal web servers 🙂

(the tricky part might be that the SSH tunnel command doesn't return -- you have to ctrl+c it -- and you can't start the Portal browser until the SSH tunnel is up)

The VSCode terminal API is not waiting for the command to return, it just moves on. AFAICT, you can access the underlying process, you can just sendText.

So you either wait for a couple of seconds hoping the SSH tunnel is up, or you try somehow to ncat to the port and see if you get a connection...