when implementing server-side-rendering, I'm thinking about switching to :target :esm so I'm able to keep a single bundle that I can run in the browser and in node (or graal). Are there any reasons I'm missing why this would be a bad idea?

well for node you usually wouldn't bundle all the dependencies and let node load them

for graal/browser you'd need to

but I guess for node it doesn't matter too much if you just bundle it

graal IIRC doesn't support ESM, so only single module release builds would work

right, I think you convinced me regarding getting things working in node vs in graal first.

I'd recommend :node-script, it just is the most straightforward way for node

ESM is a little bit of a journey given the state of ESM in node

oh, there's still issues with it? Ok, will try :node-script on the first glitch I run into

or actually, trying :node-script first, thanks for the rec!

ESM needs to be opt-in for node. only ESM code can include ESM packages thought, so depending on what you want to use that may be required

and for the browser do you recommend :esm these days or also sticking with :browser?

:browser, unless you want to load ESM code dynamically via import

ok, so I actually do load esm modules in node now, so trying :esm instead of :node-script

running into ReferenceError: WebSocket is not defined at shadow$cljs$devtools$client$websocket$start (full error in 🧵 ) with target :esm and trying to run it via node .

Is there any guide that says something about how to use the output of the "release" target? I see various files lying around in ".shadow-cljs/builds/app/release", but.. what do I do with them?

you don't do anything with those, you only use the actual configured output files. ie. :output-dir in a browser build

the files in .shadow-cljs are build supporting files (eg. caches). they are build internal and aren't used anywhere besides that

Ah, I see thanks. 🙂 Okay, now I need to find out why the release build doesn't work.

whats the problem?

"Error: No item 1 in vector of length 0"

There's some of my own log messages in the console before the error, so I guess I need to see where it crashes by putting in more console logs.. or is there a better way?

thats the error message you'd get for (nth [] 1)

I recommend using npx shadow-cljs release app --debug to debug issues

or npx shadow-cljs release app --pseudo-names but that doesn't have source maps, so a little lower level and may require looking over some JS code

generally --debug is best

Damn, I actually have a single stupid "nth" in my code. I'll check that right away. Thanks so much!

Got it working. Awesome!

now running into https://clojurians.slack.com/archives/C6N245JGG/p1627574180362500 with the advanced build. @borkdude you wrote you replaced this, is there a way to let shadow fix this now?

Want to confirm there's no shadow-cljs easy pathway for this kind of js:

import 'draft-js/dist/Draft.css';

// ./src/js/project/css.js
import 'draft-js/dist/Draft.css';

(defn project.css
  (:require "/project/css"))  ;; <-- Invalid namespace declaration    

correct, shadow-cljs does not support css. use a tool that actually only handles css and don't try to turn css into js

just postcss or so is fine

and absolutely never even try to include some webpack output in a shadow-cljs build just to get css. thats madness 😛

So, I have an idea that I'm working on, and I'm trying to figure out how to proceed. In essence, I want a command line tool that executes, reads some data from the local directory, and then launches a browser to interactively show the results. I'm just trying to find my way around all the browser UI stuff I've ignored for about 10 years, and wrap my head around shadow-cljs concepts. First off, is this a normal use-case?

As in, I would want my browser FE on launch to chat with a local server, passing EDN or Transit or JSON back and forth.

yes, you can use shadow-cljs to build the cljs code that ends up running in the browser

and the node script in case you want to run node for the command line parts

(or use CLJ for the command line parts)

Right, so a Clojure CLI command that, at launch, starts up a web server, serves up the previously compiled JS & assets plus additional routes specific to the tool, and opens a browser to the URL?

yes, that would be one way

Is that a well trodden path, or do I have some bad preconceptions?

well running it locally is probably not done too often. but any CLJ website works that way, so yes very good path

its basically what shadow-cljs does during development ;)

ie shadow-cljs server and open (its UI)

serves the precompiled JS code and talks to the CLJ process via websocket

I'm a little lost into how I can add my own routes to http://localhost:8080 when running shadow-cljs watch frontend

well that should be the server you intend to run for "production", which shadow-cljs should not be a part of

dunno what you use for :8080 now? :dev-http?

it should be your own server. ring, pedestal, whatever you like

So far, no server support. I guess we would set up :8080 for JS and other assets, and another port, say :8081, for data?

no, just one server. as far as JS and other assets are concerned, it just needs to serve the static files. any webserver can do that

So far, all I have is this:

;; shadow-cljs configuration
{:deps true

 :dependencies
 []

 :dev-http {8080 "public"}

 :builds
 {:frontend
  {:target :browser
   :modules {:main {:init-fn }}}}}

no

you create a server to run your CLJ code. the one you intend to use for your command line tool

shadow-cljs is not involved in that in any way

you build it like you would for a regular website

eg. pedestal. no knowledge of shadow-cljs whatsoever. separate worlds.

Right, that's what I was thinking when I said "data on port 8081".

yeah, just remove :dev-http {8080 "public"} then

its not needed if you have your own server

just make that server serve the files in the public dir

So I want all the live reloading goodness when developing, but then I want to package it all up and serve static assets off the classpath; so it feels like you are telling me about the second part of the story (one production server to handle static and dynamic) but I'm not quite sure what it looks like during development (where I want all the shadow-cljs live reloading goodness, at least for client components).

all REPL and hot-reloading is handled independently of the :dev-http server. it is not involved in that

that is handled by the main shadow-cljs server running on :9630, which also serves the UI parts

the server serving the JS doesn't need to do anything special, just static files. it'll work with any server and needs no knowledge of shadow-cljs

Oh, it's coming into focus for me; so the shadow-cljs code is doing its thing and it's writing stuff intoo my public/js folder and using websockets to force the client to reload, but the server on :8080 is vanilla, and I can just replace that with my own app-specific server that servers assets from public but also hands the routes I need.

yep

Maybe I can do a documentation PR that lays some of this out?

https://shadow-cljs.github.io/docs/UsersGuide.html#dev-http

> IMPORTANT These are just generic web servers that server static files. They are not required for any live-reload or REPL logic. Any webserver will do, these are just provided for convenience.

its sort of there already?

Yes, I'd love to expand on this a bit: "As you develop your client side application, you will reach the point where it needs to communicate with a backend; at that point, you should remove :dev-http and provide your own server, that serves the assets in public but also provides the additional routes your frontend requires." Something like that.

you might not. we use a reverse proxy to route our requests to either our local UI, local APIs or dev env APIs

we continue to use shadow's dev-http server with that setup

there are just too many possible setups to cover everything I'd say

Ok I am trying to figure out how this sorcery works:

import cljs from "goog:cljs.core";

closure compiler

sorcery