Im trying to specify a private npm pkg named something like @org/some-pkg in my shadow-cljs.edn but its complaining about the @ character. Ive tried googling but to no avail

@nicdaoraf why would you specify that in shadow-cljs.edn? where?

["@org/some-pkg" ...]

oh, inside :dependencies

you don't put js dependencies inside shadow-cljs.edn

they are managed by package.json via npm/yarn

hmm quoting didnt work, just complained that: Doesnt support "@org/some-pkg"

oh right

Yeah, I misread the question and thought you were just trying to require it.

i thought id have to go yarn add @org/some-pkg and put it into :dependencies

I'm looking at https://shadow-cljs.github.io/docs/UsersGuide.html > Example 1. Specify dependencies > {:dependencies [[lib "1.0"]]}

What dependencies do they mean here?

CLJS dependencies

oh and those are different from "js" deps?

yes

> Or a `.jar` file, representing Clojure(Script) or JVM libraries. These are compressed archives containing many files (basically just a `.zip` file). These are added by your `:dependencies`.

Also, I just realized that you're the author of shadow-cljs 🤯

thanks a lot

I've been looking at lighthouse performance on clojurescript apps, well, re-frame in particular. And I was really surprised to see they score pretty low. Is that just a re-frame thing? Reagent perhaps? Any tricks to improving run time performance people know of?

@cam.asoftware did you measure a release build or a development build?

Some deployed apps, so I'd hope they are release builds @thheller

well how large is it? lighthouse really only measures load times and they are horrific unless you used :optimizations :advanced to build it

I see, do you think the projects measured here are not using those optimisations? https://www.google.com/amp/s/www.freecodecamp.org/news/a-realworld-comparison-of-front-end-frameworks-with-benchmarks-2019-update-4be0d3c78075/amp/

I don't know .. what are you comparing exactly?

I only ask because I'm seriously fed up with JavaScript. I looked at elm which looks great, but there is some really interesting things about clojurescript

it is pretty easy to get 100/100 in lighthouse with any CLJS if that is your concern

Cool! As long as it's possible, and I understand it's not the only thing to consider, then awesome! Right now I'm trying to figure out what I should use as my toolchain (that makes performance optimisation a possibility if needed) so far I see figwheel, devcards, shadow cljs.... Lol, hard to know where to begin!

And don't start me on editor's.... That's another story. But repl type dev looks very attractive.

I bet the "which toolchain" question gets asked a lot

Although, from what I can tell, devcards is not really about builds.... More of a helper? Not sure

@cam To reduce choice, re-frame-template might be a good place to start?

Is that a lein template?

Yes

Right, ok cool.

does anybody know how to disable process.env when target a browser?

apparently, it gets required by cljs

i'm using figwheel main

Is there such a thing as "boxed math" in js/cljs, in the same performance-harmful way that exists in JVM clj?

when I deref an atom does it create full copy of the atom I have some big atoms in ref-frame app when I deref them do I cause the app use more ram or is it just a link to an immutable element?

My app crashes for some people in Chrome because it creates an object called XR. This name was blacklisted for renaming in the Google Closure Compiler 10 months ago, but cljs is using an older version: https://github.com/google/closure-compiler/blame/5c84f3cc92dc5369d50f0398505fa45573be125f/src/com/google/javascript/jscomp/parsing/ParserConfig.properties#L227 Is there an easy way to use a newer version of the GCC or is that usually tricky? Or can this setting be configured for cljs builds?