I'm not sure what you mean by join/pipe

I mean: we can see stdout/stderr output from both shells in the single terminal session.

yes

Great.

If you upgrade squint, compile compiles all files in path

If you want optimizations I recommend using a tool like esbuild

Sorry, optimizations maybe not required. squint -> mjs/jsx -> (vite/esbuild etc.) -> production bundle will be more proper.

Now testing with squint version 0.3.35 should I try with the master branch instead?

No, check the latest version on npm

And re-run npm install

This should work since I’m also using it on CI in a test project

Great. Will use the latest.

Maybe I was mislead by the --help output?

vite-react on main $ npx squint --help
Squint v0.0.0

Usage: squint <subcommand> <opts>

Subcommands:

-e           <expr>  Compile and run expression.
run       <file.cljs>     Compile and run a file
watch                     Watch :paths in squint.edn
compile   <file.cljs> ... Compile file(s)
repl                      Start repl
help                      Print this help

Use squint <subcommand> --help to show more info.

Just don’t use any arguments, just “npx squint compile”

Yeah maybe the help should be updated :)

I'll have a look

the issue is that you have to name your source directory src-cljs, not src_cljs

I get the confusion but everything on the path needs to use underscores, but not the path directories itself, unless you write :paths ["src_cljs"]

Oh, this helped! But, ultimately, the cli should warn that it could not find the path .

sure, issue (+ PR?) welcome

Btw, what is the meaning of adding - to functions and tasks, does it mean an entry point hint? Like here https://github.com/squint-cljs/squint/blob/main/examples/vite-react/bb.edn#L4

- means "private", these tasks don't show up in bb tasks output

Still working on squint-vite and trying to https://github.com/sher/squint-vite/blob/main/bb.edn#L2 to the dest path, replicating what https://github.com/squint-cljs/squint/blob/main/src/squint/internal/cli.cljs#L142. Added shadow-cljs to node dependencies, but can't require it in the babashka task. Getting this error.

----- Error --------------------------------------------------------------------
Type:     java.io.FileNotFoundException
Message:  Could not locate shadow/esm.bb, shadow/esm.clj or shadow/esm.cljc on classpath.
Location: <expr>:4:47

@URCRY0U87 I don't understand what you're trying to accomplish. When you run npx squint watch, files are already watched and compiled by squint? (it uses chokidar under the hood btw) and why do you need shadow-cljs?

What I m trying to do is copy files like styles, images that can be required like this https://github.com/sher/squint-vite/blob/main/src-cljs/core.cljs#L5

And the compiled output will be like vite would expect https://github.com/sher/squint-vite/blob/main/src/core.jsx

And rely on vite to handle bundling css or other static assets.

Why don't you just write (:require ["assets/core.css"])?

$ ./node_cli.js --show --no-run -e '(ns foo (:require ["assets/core.css"]))'
import * as squint_core from 'squint-cljs/core.js';
import 'assets/core.css';

I am doing as you mentioned above, but the actual assets/core.css file is never copied to the output destination folder, never processed by squint's chokidar watch function.

My understanding is that chokidar now filters only cljs files https://github.com/squint-cljs/squint/blob/main/src/squint/internal/cli.cljs#L152

this file doesn't have to be compiled using squint, so why should squint watch it? vite itself should pick up on it

where does assets live in your directory structure? I think you should just place this where vite can already see it

You are correct. The plan was, to make it more developer friendly, to write the app in the src-cljs folder, also putting all static assets there. Then the dev or build tasks would compile cljs files and copy static assets to the src folder.

This way src folder can be also gitignored

Sorry for confusion, the src folder will be the destination for squint compiler.

right, I think we could add maybe something to squint watch to support this, to watch all files but to copy all other assets that aren't .cljs files

Also thought about this, but am not sure if this copy feature has place in squint.

I think that would be the easiest way

PR welcome

Great, will try.

Then you could add :paths ["src" "resources"] and even separate the css stuff from the srces

Have to think about making this configurable. Certainly :paths ["src" "resources"] could work, also clojure way to separate resources. But then vite also should be able have access to files out of src scope.

I will try possible options and create a PR.

Thank you.

> But then vite also should be able have access to files out of src scope No, these files are copied to :output-dir and vite is going to pick them up as relative imports

Oh right, thanks

I'll have a go at it right now

Nice. I was still figuring out how to implement and test it locally.

@URCRY0U87 publishing 0.4.41 now, all non .cljc/.cljs files are just copied over to the output-dir

Thank you. Will test it right away.

Do you think it is ok to be the default behavior, with no option to disable it?

that's what it is now

there is no option to disable it

this also works nicely if you want to include some .js files among your .cljs files btw

If all works as expected, can I update your https://github.com/squint-cljs/squint/tree/main/examples/vite-react example or create a new example?

Sure!

Just tried and files other than cljs are recursively copied to :output-dir 🎉 Things left to do: • update squint-vite and squint README, mention caveats like ◦ asset imports must have relative path (:require ["./assets/some.css"]) or (:require ["../resources/assets/some.css"]) ▪︎ depending on where you wish to keep them ◦ bb tasks should run in parallel in order to have their stdio piped ▪︎ {:parallel true} option can also be re-considered, because dependent tasks may run serially but still have stdio piped, so we can see output from every spawned process ▪︎ {:parallel false :stdio "pipe"} as an option for node https://nodejs.org/docs/latest-v18.x/api/child_process.html#optionsstdio Will prepare a PR.

This is a great change. Now you can write full vite project with just bb/squint.

I'm not sure what you mean with the stdio issue but maybe it will become clear in the PR

Yes, I will try to clarify this matter.

Sorry, not pipe but inherit (in nodejs terms) so all spawned child processes' logs will be print to parent process streams.

Currently, if you not state that tasks should run in parallel child process logs dont appear. https://github.com/sher/squint-vite/blob/main/bb.edn#L5

They don't appear since the "second" task doesn't even run, it's blocked by the other one until it finishes

It doesn't have to do with inherit/pipe etc

You can however start the two tasks in separate terminals, then it should work

I see, if a task depends on multiple other tasks listing them like -dev {:depends [dev:squint dev:vite]} , none other tasks will run until the previous one is finished?

yes

Unless we declare them to run in parallel dev (run '-dev {:parallel true})

true

Now I understand the point. But in dev mode, processes may watch and never exit. You may have bunch of those processes, that bundle some sort of deliverables. Maybe there is a way to accommodate this case, maybe we can consider.

I don't think anything has to change really. watch is a development task. when you need to bundle stuff up, you quit the watcher, and run squint compile + vite build or whatever

https://github.com/nextjournal/clojure-mode/blob/2da3d79f082ae29e4510b28448217abffa929489/bb.edn#L56

I am excited to share vite-bb with others who wanted to write clojure for frontend SPA.

squint-vite you mean?

Still not sure which is the main: squint or bb

Plan is to create a npm create vite-bb command

bb is just a development tool, it has nothing to do with vite or JavaScript

bb is more like JVM Clojure than ClojureScript

or do you want to create a web application with a backend in bb?

For this phase, I want to create a command that will give the dev a boilerplate to create a vite SPA project scaffold which has bb.edn squint.edn etc.

ok

cool

I am looking forward to attracting more enthusiasts to both https://github.com/sher/squint-vite/tree/main frontend, using vite SPA and nbb fastify https://github.com/sher/nbb/tree/main/examples/fastify to create a public facing service, all written in cljs.

you can build the backend in nbb too :)

eh squint I mean

but the nREPL experience isn't as great yet with squint, working on it

fastify-nbb is working just well

Oh, nREPL - for newcomers like me, we were never used to that kind of development

So no rush

But, ruby on rails we had this experience decades ago, with rails c command. You can query database, you can require any class etc.

👍

Squint nREPL if combined with browser websocket, refresh the state of an item: this should be very complicated.

yes, but for Node.js applications nREPL is doable. I'm of the opinion that for front-end hot-reloading with vite is 90% what I want

still I want to have a go at making nREPL work for front-end too, eventually

but first nREPL on Node.js needs improvements

nREPL on Nodejs = Nodejs repl + (SCI) clojure + classpath + discovery paths ?

nREPL on Node.js with squint I mean. nREPL on Node.js with nbb already works perfectly

I understand it is complicated (without understanding the actual complexity), but JavaScript runtime engines trying their best.

> JavaScript runtime engines trying their best. Actually this is what makes it complicated: ES6 (immutable) modules destroy the REPL experiences, you have to basically undo everything ES6 modules stand for

so I don't agree with "trying their best" to make this experience possible ;)

Good REPL experience assumes mutation of imported modules?

Imported, external - that you have no control of to publish updates.

Of course. When you import function f from module F and you call it in your own function:

(ns my-ns (:require [foo :refer [f]]))

(defn g [] (f))

so when you are in a REPL:

foo> (defn f [] 3)

and

my-ns> (g)

Every file in squint is compiled to an ES6 module but to make the above possible you basically have to work around it

Is it just a namespace/naming issue, because we can import and destruct values like import { a: b} from 'c' where original b inside the module, will be mapped to a within current context.

is this a question or a remark?

Remark.

This seems to me that you are creating not only compiler, but have to struggle with linker.

It is not just a mapping problem. The original b can change because of what you are doing in the REPL, but ES6 module c can never change.

vite uses workarounds for this like adding a ?<timestamp> to each module and rewrite all imports using these timestamps

CLJS makes the REPL experience possible by just using global mutable objects for namespaces

while emitting normal ES6 modules on non-REPL output

Now I kind of understand, that in REPL anythyng should happen, even rewriting the imported external library logic.

Actually, I do change code in node_modules/etc lib folder, to debug its' behavior.

In an ES6 module but without restarting Node.js for a node app? This is what a REPL should support

I mean, initially, I'm ok with just supporting this for code on :paths, not JavaScript libraries, but in a squint node app you will be working on multiple namespaces at the same time

With the latest squint copy command update, we can create a full web service: front: squint-vite back-api:nbb-fastify.

yeah

I see a chance to lure young programmers to lisp )

Figuring out the npm create command, planning to execute with bb wherever possible.

If this means there's a possibility I can npm install a babashka-like-in-js then I'm very interested! The main thing that stops me from making my apps depend on bb is needing to install a separate binary outside the normal deployment flow.

This is only about one library, babashka.cli, so no, it doesn't mean that

bb itself has JVM-semantics, you cannot possibly port that all to pure JS