we have a pretty large re-frame app at work

try 2.8.76 and generate a build report and then one with :compiler-options {:shadow-keywords true} looking to compare the gzip size before/after

impact will be bigger with lots of namespaced keywords though

oops :compiler-options not :js-options

in our main bundle, • before: [JS: 4.19 MB] [GZIP: 1019.18 KB] • after: [JS: 3.99 MB] [GZIP: 960.59 KB]

thats a decent chunk. thx.

👍

(scary large build btw)

PS we ship way too much code

😂

it’s my goal in life right now to at least get code splitting going so we can chunk out the loading process better

on low-end machines it takes like 10s to download and load all the JS

it'll probably melt a low-end phone 😛

I only recently joined this project. unfortunately, re-frame is fighting me on that front… our code is laid out in a way that makes it harder to split

yes luckily it is a SPA meant for enterprise desktop usage

Hey, dudes and dudettes!

I have an unusual question, does shadow-cljs provide anyway to have optimization/minification on for hotreloaded code when running watch? I know that's generally a no no but I have a bit peculiar use-case here.. I'm figuring out to a way to compile code that I use in Screeps, which is a Coding Sandbox game. The thing is that the code works wonderfully when I build a node library in release mode and use that in the game. Naturally the watched dev version includes some Shadow-CLJS-related stuff so that doesn't work. I'm well aware that what I'm asking might be impossible, but I figured if someone smarter/more experienced one would have an idea? Otherwise it's really nice to use shadow-cljs and it's not so bad having to manually build your code for this specific case 🙂

can shadow-cljs work with lumo?

@theamazingekko hot-reload is impossible with optimized code so no its not possible to have a release "watch"

@eliraz.kedmi no

Thanks for the verification, assumed so 🙂

if you run shadow-cljs server and then shadow-cljs release app whenever you need while that is running you at least won't pay for the startup cost each time

or you can trigger the compile from the REPL too of course

yup, been taking the REPL-route so far and it's good. Just wondered about the concept :)

Just noticed that running release twice produces different files. Seems like Closure renames some objects in different ways. Is it possible to create the same output from the same input?

did you delete the cache between the builds?

Nope.

so not running in CI or something?

Just two consecutive release commands on my local machine. Removed only the js and js.map files in between.

did it recompile any CLJS?

you can't really get the same output unfortunately

as soon as any compilation happens that used any kind of gensym

> did it recompile any CLJS? Probably - it took some time and CPU. Ah yeah, gensym is in there somewhere. Although I would expect the order to be the same. But maybe that's not the case, or maybe the order doesn't matter.

gensym is using an incrementing number thats reset whenever you restart the JVM

Yeah, but since I restart it each time I run release, the numbers should've been the same. Unless there's some concurrent work being done.

so with caching the ids may change

there is also parallel-build yes

Ahh, right. Damn.

I wouldn't ever count on builds being identical

shadow-cljs adds a couple closure compiler options to "try" that

but that only really works if no CLJS compilation occurs .. which of course makes it pointless

Well, one could hope. 🙂 It's pretty often that I make only backend changes but CI runs the same pipeline either way and releases the UI bundle. But it's not a huge deal. And module splitting should make the situation a bit better, I assume. Whenever I finally start using it, that is.

maybe separate the frontend/backend CI 😛

you can check with shadow-cljs release app --verbose if any actual CLJS compilation occurs

if not the builds should be the same. assuming of course that .shadow-cljs/builds is preserved between the builds (which may require additional CI config)

Ah, but that's more complicated and probably not worth my time. After all, I use macros and CLJC. Thanks, will try.

Yeah, a bunch of CLJS gets consistently recompiled on each run. So, I should look out for gensym and see if I can remove it. Is there anything else that I should look out for that could prevent a cached compilation result from being used?

Huh. Just checked gensym usages in CLJS files. It's definitely used. Only those files are never recompiled.

you don't have to use it directly. any macro using gensym or auto# uses it for you

maybe check why things get recompiled?

I mean if they didn't change they should be cached. unless they have warnings or so.

I'm trying to check a particular file by commenting out suspicious imports and pieces of code and running the release twice.

Ah, prettifying cache files and comparing them is much faster. Yeah, it's definitely gensym. But only at some very particular places, and not the others. The same 6 files, each and every time. The offending calls to gensym are made by doto and by cljs-oops. But I use them in a much greater number of files. It's interesting how only those 6 get different results.

why are they getting recompiled though?

Because gensym returns different result in different runs.

I feel like you are digging into something thats kinda pointless. using when uses gensym

any macro basically does

Yep. At this point, I'm trying to understand why those particular 6 files are affected. And others are not.

so you are trying to figure out why they are getting recompiled?

Yep. Not so much to fix it but to understand what's going on.

do you use clara-rules?

Never heard of it.

do the files have warnings?

do you explictely block the cache?

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

No warnings in those files. Only a couple of warnings from transit-js, and it's not used by those files. Nope, don't block anything.

closure compiler warnings aren't relevant to this cache

actual CLJS warnings only

No warnings at all then. Just lines like these

<- Cache read: hgs/platform/abc/core.cljs (8 ms)
-> Compile CLJS: hgs/platform/abc/core.cljs
[...]
<- Compile CLJS: hgs/platform/abc/core.cljs (282 ms)
[...]
<- Cache write: hgs/platform/abc/core.cljs (32 ms)

what the heck? is that from one compile?

Yep.

so you did make changes?

because it read the cache but decided not to use it?

Let me double-check.

Yep, seems like it:

-> Cache read: hgs/platform/abc/core.cljs
<- Cache read: hgs/platform/abc/core.cljs (8 ms)
-> Compile CLJS: hgs/platform/abc/core.cljs
<- Compile CLJS: hgs/platform/abc/core.cljs (358 ms)
-> Cache write: hgs/platform/abc/core.cljs
<- Cache write: hgs/platform/abc/core.cljs (45 ms)

Two consecutive runs with grep abc/core, the same output.

so something happened that made it not use the cache

Just in case it affects something - the file requires some JS files. Both from NPM and from a dir relative to src.

ANY change may affect it yes

anything used by the file that changes will invalidate the cache (as it should)

Oh, but the files didn't change!

Nothing was changed.

Except the system time.

hmm then I don't know. you can compare the cache files before/after to see what changed besides the generated code

:compiled-at and some other timestamp-looking values (transit cached the keys, can't really tell without deserializing).

you can use (shadow.build.cache/read-file (io/file ".shadow-cljs/builds/foo/....")) in the REPL with the full path to the cache file

*read-cache Ah, that was stupid. The JS files are not changed. But their timestamps are.

[SOLVED]how do shadow-cljs watch files? hawk {:mvn/version "0.2.11"}

@souenzzo thats only used on macos. otherwise the default JDK watcher is used.

@p-himik yes timestamp changes are enough to invalidate cache

Fixed it, no cache misses now! And the file name stays the same, so that's great. But why is this step still executed though? Is it really needed given that the output file is already there and none of the cache entries got stale?

<- Closure - Optimizing ... (46580 ms)

hi, is it possible to get source maps working with Web Workers? Debugging the following errors is difficult otherwise:

Uncaught Error: nth not supported on this type cljs.core/PersistentArrayMap
    at Function.eval [as cljs$core$IFn$_invoke$arity$3] (/js/compiled/cljs-runtime/cljs.core.js:6349)
    at eval (/js/compiled/cljs-runtime/orgpad.client.layout.webworker.ops.js:23)
    at Object.eval [as cljs$core$IFn$_invoke$arity$3] (/js/compiled/cljs-runtime/cljs.core.js:36362)
    at Function.G__27279__2 [as cljs$core$IFn$_invoke$arity$2] (/js/compiled/cljs-runtime/cljs.core.js:14986)
    at eval (/js/compiled/cljs-runtime/cljs.core.js:8044)
    at Function.eval [as cljs$core$IFn$_invoke$arity$3] (/js/compiled/cljs-runtime/cljs.core.js:8045)
    at Object.eval [as cljs$core$IReduce$_reduce$arity$3] (/js/compiled/cljs-runtime/cljs.core.js:10474)
    at Function.eval [as cljs$core$IFn$_invoke$arity$3] (/js/compiled/cljs-runtime/cljs.core.js:8198)
    at Object.orgpad$client$layout$webworker$ops$apply_ops [as apply_ops] (/js/compiled/cljs-runtime/orgpad.client.layout.webworker.ops.js:177)
    at eval (/js/compiled/cljs-runtime/orgpad.client.layout.webworker.handle.js:71)

I am trying to make a bundle with shadow-cljs that uses quil library, that has as transient dependency p5

I am getting crazy errors, does anybody know why they come?

what kind of errors?

I copied my configs nd the error ito the therad to keep the main chat clean

hmm looks like p5.js does something weird ... check what happens in the :line it lists

:js-errors [{:line 69565, :column 0, :message "Invalid delete operand. Only properties can be deleted."}]

the error log is huge

I am trying to redirect it to a pastebin

but seems like I cannot redirect the error message itself

https://pastebin.com/Va3NgmnV

this link contains most errors

I already pasted you the relevant one

its a bunch of warnings .. which you can ignore. the :js-errors above is the one causing the crash

Thanks Thomas!

Can I see somewhere the version of the npm modules for which you have provided cljsjs wrappers?

hmm? they don't have a "version"?

I mean the wrappers don't have a version

Well, in the wrappers I dont see them at least.

you decide the version of the npm package?

But what if there is a breaking change in the library?

nevermind

your wrappers seem to all just set one symbol in the window

that wont break

ideally you wouldn't use those wrappers at all

So what happened to me is that the clojurescript compiler detected something bad in the npm bundle of p5 ?

the "delete this"

yes

That is an amazing benefit of shadow-cljs!

well not really .. the code probably runs otherwise. if they'd run their code through a linter that would likely catch it too

but that one function would break

or throw exceptions

yeah .. but people probably use p5 without it ever breaking

you can probably report that error ... maybe they care about fixing it

I will.

Good point!

https://github.com/processing/p5.js/issues/4158

Many thanks @thheller

wow. nice response time on that issue 🙂

I'm using shadow with :target :react-native (based on the reagent-react-native template) and connecting to the cljs repl from emacs/cider. One unexpected behavior is that when I evaluate an expression over cider that throws an error, the trace is displayed in the simulator window, and no feedback is given in emacs/cider. Is that expected? Is there a way to get the exception to come back to emacs/cider so I can see it there?

no clue. I don't do react-native development myself.

the eval happens in a try/catch so the react-native side probably intercepts the error somehow?

OK, so the eval is expected to wrap a try/catch and return the error to cider then

So yeah, seems like something about the react-native environment is intercepting the exception. Any tips on how to track that down?

I know next to nothing about react-native sorry 😛

Yeah no worries, I just tried it with a regular :target :browser shadow project, and a similar thing happens, it just prints the error in the repl buffer instead of popping up a *cider-error* buffer. So I'm guessing that this is actually something to do with how shadow emulates piggieback.

thats possible ... I don't use emacs so no clue what *cider-error* even is

Don't mean to belabor this, but if you're curious, there must be something in the piggieback repl protocol that tells cider that an error occured during evaluation, which cider uses to present some UI indicating this. It appears that shadow emulates piggieback in a way that cider doesn't get this info. If there's any interest in tracking this down, I'd be thrilled to help, but if you consider it too low priority, that'd be understandable.

happy to add whatever is needed but I have no energy to spend on tracking yet another cider nrepl issue myself

since there are no docs for any of this it is likely just an nrepl message missing some field or something

Hi, is it possible to get REPL for a Web Worker?

@pavel.klavik not currently no

and concerning the source maps I mentioned above? I am just able to get to Javascript code which is not very useful to debug Clojurescript

source maps in Web Worker

I'm not sure why they don't work. I'd expect them to work. haven't used workers myself for years

if you open an issue I can take a look when I have some time

deep in other stuff currently

sure, I will produce some example and make an issue, thx

outside of these two issues, I am quite happy with Web Workers support in Shadow, super easy to get it working

is there any way to include CSS?

import DatePicker from "react-datepicker";
 
import "react-datepicker/dist/react-datepicker.css";

not in your code. you can copy the datepicker .css file into the folder your js is hosted in and add it to your index.html

cool