something like (shadow/when-dev <perform extra expensive validation>)

this sounds handy, thank you

and now I know what to look for I see it confirmed in the https://shadow-cljs.github.io/docs/UsersGuide.html too - awesome, thank you

(I guess I was hoping for a macro to elide the code completely, but this sounds close enough)

it's gonna be removed by Google Closure compiler as dead code, so not on Clojure level, but when generated JS gets compiled by Google Closure

ah, okay, well I guess that's exactly what i wanted then. thank you, I'd not appreciated that

where do you get this? not an error I have ever seen before.

I'm compiling TypeScript code to JavaScript that then gets consumed by ShadowCljs. Any code that has async stuff will get generated with code up to that looks like this:

the ts config targets ES6 because that's the only way I could get the imports to work 😅 and the thing to compile

that still doesn't tell me who or what gives the the error?

I'll DM you

why do you want to include externs in the first place?

note that :deps is a top-level only key. it has no effect in the build config whatsoever

why do you turn caching off?

and don't even think about using your code for externs, thats not how externs work

I wanted to include externs because things were getting renamed and I didn't want them to be

regarding the caching, I've been bitten enough times by not clearing out the .shadow-cljs file that I turn off cacheing to try and prevent that from being an issue. Creates a more consistent experience across development environments

It's more like a superstition probably

well, unless you are doing some weird macro things caching should be fine

at least I haven't heard or any bugs for many years

neither have I cleared out .shadow-cljs, nor should you. I mean I'm all ears if you have a reproducible problem, just not aware of any.

unless of course you do weird macro stuff, then all bets are off.

how do you include the JS? the :js-package-dirs suggests (:require ["some-dir/that.js"]), in which cases the code doesn't even run through :advanced and externs will do absolutely nothing for that code

if its however included via (:require ["/some-dir/that.js"]) (i.e. absolute or relative path), then it might go through :advanced (and you wouldn't need the :js-package-dirs entry

@U05224H0W I use the (:require ["/path/to/js" :as js-code]) notation. I actually think what I'm seeing might be more a result of mixing "dot-attributes" and string access a little too carelessly. I try to use accessors when coding in typescript, but keywords when coding in clojurescript, and I think that I haven't been careful enough during serialization. At least that's where I'm at with it currently.

@U05224H0W no macro stuff. Actually I switched to TypeScript to avoid writing macros.

(:require ["/path/to/js" :as js-code]) is kind of dangerous. I don't really recommend doing that

I do not understand that question one bit

what does AOT have to do with .cljc files?

you use them like any other source file?

Sorry, bad phrasing and not an area I'm too familiar with. Basically I am using some Java classes but couldn't require the code in a .cljs file. But I used a macro and it works now.

I'm lost. what do java classes have to do with cljs compilation?

yes, macros run in CLJ, so they can load java code. still not sure what for though.

I was working with javax.crypto and the like, classes and APIs I know how to use. I don't know how to use equivalent functionality in JS so I did it in clj.

sounds maybe like you're talking about a node.js/backend style project?

I'm just asking because there may be two senses of the word "server" here -- there is the shadow-cljs server (at least if you are targeting the browser), and then if you are making a server style application (aka with express or something), that's something else

Ahh gotcha, yes to clarify im talking about the shadow-cljs server, to run our code in the browser. We have a webapp project, thats just shadow-cljs, no deps.edn or leiningen. Feel like we shouldnt need to build a whole uberjar for cljs code. I can copy the release build into the container of course, but it feels wrong to run a shadow watch as the container entrypoint, when we dont need the hot-reloader.

So are you serving the frontend code from the same server as the API/app server or those seperate concerns?

For instance, all my frontend code is separate from my backend code, so in my case, I can just run regular shadow-cljs watch dev , and I just use some dev settings to configure the root URL of the API server I want to point to (and run the API server a different way, perhaps with a second shadow-cljs process or just a standalone node process)

oh wait I don't even do that, I just have the dev apis commented out and I just comment them back in lol

now if you server the frontend code as static files from the same server as the API server, then you need to configure some stuff in the shadow-cljs config

There is no API/app server, its just the standalone shadow-cljs code

I was thinking of just serving them as static files, but it seems like there needs to be some kind of shadow server still running, since opening the index.html after a release build doesnt show the webapp as expected, just the 'reagent/ref-frame code goes here' splash screen

or it shows the shadow-cljs stale output banner, which isnt ideal.

so this is a front end app only?

ok so if you check out my build above

I have :output-dir "resources/public/js/compiled/" set

to test my code

I do shadow cljs release app

then in a terminal window, I navigate to resources/public

then I do python3 -m http.server 9500

then when you go to localhost:9500 in the browser, it should load up the index.html located at resources/public/index.html

In the bottom of my index.html, I have this:

<script src="js/compiled/app.js"></script>

that corresponds the the compiled code that should be in resources/public/js/compiled (according to the :output-dir setting)

in my <head> tag, I load in the CSS as per normal:

<link href="css/screen.css" type="text/css" rel="stylesheet">

I use SCSS to compile all my CSS into a single stylesheet

so to be clear, that's how I TEST the production deployment, I don't use Python's simple server for production, I just stick the static files in cloud buckets and wire up the domain routes. You could do the same thing with Nginx or Apache on a traditional webserver, though

hmmm okay. maybe i just need a static webserver docker image to serve the compiled release app. my index.html has the same script tags to get to the compiled app.js as you. I just keep getting the static reagent/reframe splash screen instead of my compiled app code

did you make a custom index.html?

<html lang="en">
  <head profile="">
    <meta charset="UTF-8">
    <title>MyApp</title>
    <link href="css/screen.css" type="text/css" rel="stylesheet">
  </head>
  <body>
    <div id="app"></div>
    <script src="js/compiled/app.js"></script>
  </body>
</html>

nothing custom, it looks basically like that, plus more css lines and another script line for the webpack bundle. Nginx might just be the move, trying to get it working rn

yeah i was overthinking it, a static webserver docker image got it up. Wish the shadow-cljs reconnecting banner didnt show though

do you still have the shadow server running? Also might need to hard refresh to make sure you're getting the correct files if you're serving from the same port

I tend to go out of my way to make sure caches are purged before testing because I've been bitten by that enough times

FWIW i deploy my frontend by just serving (pre-compressed) static files with nginx

pure shadow-cljs, no leiningen or deps.edn

I recommend reading a lot on paths since this setup is sufficient unless you want to use Node.js + SSR

my dockerfile is little more than having a "build" stage where I install java and node in alpine so I can npx shadow-cljs release app, then run gzip and brotli on the outputted JS, and finally, in a "server" stage, copy the files over and launch nginx

this image then gets deployed to a kubernetes cluster (and since the frontend is trivially stateless + requires at most 5 MB of RAM, it suffices to have 1 replica and reserve most of your hardware for backend and microservices)

just to be absolutely clear: you do no NEVER run shadow-cljs in production environments. never ever, don't even think about it.

you create a release build and then serve the assets with any webserver you chose. doesn't matter, shadow-cljs is no longer needed in release.

and if its showing a "reconnecting banner" it is not a release build, since only watch builds have the code for that