Clojurians Log v2

https://clojurians.slack.com/archives/C03U8L2NXNC/p1777923452670219

Yes, we have a browser nrepl now!

@chromalchemy See examples/browser-repl and examples/replicant for example. Run npm run dev in those and it'll spin up a browser repl for those projects

let me know if you need any help or run into UX problems

Thanks. I’m trying it out. Running the browser-repl example in a local fork. It wasn’t clear to me at first that i needed to to build squint first. But got the example working. So cool to see the page update on ns reload via hotkey. Hot reload FTW! ❤️

yeah sorry about that

I need to make some kind of "create-squint-app" thing I guess

what is "hotkey"?

I’m trying to see if it can be integrated in my current project. Which is an ecommerce theme that depends on a npm + webpack build script . I’m not sure how vite can participate in a dev server trying to do it’s own HMR. The browser-repl ability depends on Vite right? Here is the prescribed node-based cli https://github.com/bigcommerce/stencil-cli

currently the browser nrepl support is built on vite HMR yes, since that does all the websocket + JS dependency stuff for me

I don't know if you have auto-save but save triggers a hot-reload but nrepl triggers repl evaluation without changing a file

Just tried it again. Reloading ns updates page! (Nice. I usually turn the auto reloading off)

why do you turn auto-reloading off? you mean hot reloading?

I meant I usually turn of “auto-reload ns when saving file” in calva settings, preferring to reload namespaces explicitly.

@borkdude I challenged claude, and it apparently got it working with my theme build! I cant just swap out my current build pipeline for vite. But it realized it could use the https://browsersync.io/ tool leveraged in my build cli for websocket and HMR, and essestially replaced Vite in the mix. > A squint browser REPL for a webpack (non-Vite) app, built without forking the bundler or adding a second socket server. All .cljs namespaces are compiled in repl mode (`compileFile({repl:true})` → top-level-await ESM + globalThis bindings over one shared ns-state) into an alternate output dir that a dev-only webpack alias swaps in. A squint nREPL server runs in the dev-server process and delegates each eval, over the existing browser-sync http://socket.io channel, to the live page and back — reusing the HMR-style transport the framework already ships instead of standing up its own. The nREPL:left_right_arrow:browser boundary is exactly squint’s two-touchpoint contract (`browserTransport.send` / handleBrowserMessage), so it’s essentially the Vite REPL’s architecture retargeted onto browser-sync as the message bus.

So you got nREPL working with browser-sync?

That's impressive!

Did you need to change squint for this?

Yeah, I didnt think it would work, but it seems to. 🤖! I dont think squint lib changed. I think the only thing that changed is using different tooling than Vite for the websocket repl relay and HMR stuff. I’ll review it though to confirm.

Is far as i understand brower-sync was one of the first popular html/css/js hot reload command line tools. I used it directly many years ago.

I'd be very interested in hearing/seeing how this works. Having multiple options is good since not all people want bloated JS tooling

I mean I did decouple stuff from vite, but I haven't tried another HRM backend

Here are the bones of the implementation and an overview. I used Claude fable to vibe it. It wrote more js than i expected. I should have told it to use squint! Probably pretty hacky. Looks like it is leveraging hooks in browser-sync and webpack. https://gist.github.com/chromalchemy/793544ec61db775fb5aff32dbe96be08 (ps “Stencil” is the name of the bigcommerce theme stack and cli) It suggested the vite decoupling was critical. https://gist.github.com/chromalchemy/793544ec61db775fb5aff32dbe96be08#what-was-helpful--was-the-vite-decoupling-integral

I wonder, how does this cope with dependencies you require in squint from npm?

@borkdude new doc on npm dependency handling https://gist.github.com/chromalchemy/793544ec61db775fb5aff32dbe96be08#file-npm-dependencies-md > Adding a new REPL-requirable dep requires a stencil restart > runtime REPL requires are a closed-world whitelist you grow by hand > a bring-your-own-resolver hook in squint’s client protocol would delete the regex + map entirely. The map is the webpack-world stand-in for vite’s dep server

did it already do this before I asked?

can you ask it how to enhance REPL mode so we don't have to do these tricks. e.g. also emit a normal import top level, could work?

The doc is new, but I havent touched the implementation since after it was created. I’ll ask..

First-class npm deps in squint REPL mode? https://gist.github.com/chromalchemy/793544ec61db775fb5aff32dbe96be08#file-squint-npm-deps-proposal-md

Seems like this implementation currently cannot resolve new deps dynamically, that are added in a session, like vite solution can. (not sure if proposed additions cover that?). Hard limits of AOT bundlers? Still would need an dep-resolving layer?

I would generate this before starting the browser REPL from a list of deps, but a problem is that you don't know which deps in npm are for the browser

maybe your oracle knows a solution to that

and new deps are also a problem since you'd have to complete that list

https://gist.github.com/chromalchemy/793544ec61db775fb5aff32dbe96be08#file-npm-deps-list-md

ps I’m just asking the raw questions. I have no opinion on it’s takes.

I understand

would you be interested in a ready to do webpack plugin? something like:

// webpack.config.js
const { SquintPlugin } = require('squint-cljs/webpack');
module.exports = {
  // ...
  plugins: [new SquintPlugin()], // reads squint.edn like the vite plugin
};

Yes. i think. Im kind of green on the standard js ecosystem, so dont have solid intuitions outside of “give clj or give me death clojure-spin ” I originally struggled to get shadow-clj set up properly in this code base, so i moved on to scittle (where i avoided most of this config), and then squint. But i don’t know webpack, etc well.

well, I made a local webpack plugin here and tried to make the architecture such that it can be shared with vite etc. I also don't know webpack well. it seems most people nowadays use vite? not sure. but if this makes it easier to adopt squint in certain scenario's why not. I'm also looking into making a bb/JVM based solution using the same approach.

Very cool. It can certainly help in this somewhat legacy build. The reach you provide is always appreciated.

Feel free to copy at will 😊

@christian767 how did you make it, manual html + css?

I made it with Powerpack: https://github.com/cjohansen/replicant-docs

The “design” is tailwind and daisy UI

It’s not quite as straight forward as md->html, although not very far from it. It uses “mapdown”, which enables embedding a little bit of EDN structure in markdown files: https://github.com/magnars/mapdown

yeah I guess I'm mostly interested in the "design". I can do md -> html myself quite easily

Yup, I figured. Then the answer is tailwind+daisy. Design is kinda inlined throughout though.

:div.text-sm.leading-6.overflow-y-auto.space-y-2.pb-4.-mt-10.pt-10.text-base-content#table-of-contents OMG 😂

It’s very tailwind. Haha, ouch.

yeah not sure if I want to go that way :)

maybe I'll just make a nice landing page which takes you to github ;)

but the playground is already taking up that place now https://squint-cljs.github.io/squint/

Yeah, my site wasn’t made with duplication in mind 😅

You could add some “chrome” around the playground to take you to the other bits?

I guess so yeah

> maybe I’ll just make a nice landing page which takes you to github ;) If you setup a basic landing page with the content I’m happy to contribute a design pass, also some basic improvements to the playground chrome. I would do this with vanilla css, most likely a single file.

yes please :)

I'll think of something soon

no rush, its a standing offer just ping be when its ready to go

i can start thinking about the playground chrome in the meantime, assuming you were not planning any radical structural changes to that ui

it's been pretty stable for a long time (and also pretty messy but you should be able to squeeze some css in)