Ended up doing: (merge (read-string (shadow.resource/inline "dev.edn")) (process-env-map)) behind a DEV closure-define. Release just uses (process-env-map). This means the actual configuration mapping doesn’t change between dev and release, which should help with “Works on my machine” issues 😉

I keep getting this warning (doesn't seem to break anything but is rather annoying). First line below is the warning, then my file directory, and my source paths

Invalid Filename, got cljs/foo/bar.cljs but expected foo/bar.cljs (or .cljc)

src
- cljc
- cljs
-- foo
--- bar.cljs (ns foo.bar)

:source-paths ["src/cljc" "src/cljs"]

Are deps managed by lein, clj, or shadow?

Wondering if it’s supposed to be paths and not source-paths. And it’s defaulting to “src” which would explain the error

I depend on a package that depends on a specific version of react.js (stable). I would like to use experimental version of react.js which is a different version. Can I use :resolve for this?

@ashnur just install whatever react version you want. no need to configure anything in shadow, it will just use whatever you have installed

Right, so I have 2 dependencies that use 2 different versions of react, I have 3 different versions of react installed, how can I tell which dependency to resolve which react version?

the problem for me is that helix expects react under the name react, and I would like to use a react version installed under a different name (alias), so that for other react libraries in the same build I could still provide react under a different name. in #helix I am told it's shadow-cljs's job, but I don't like to make tooling complicated. It's also a bit of an edge case, since it might be easier to just do a different build for different versions of react, I am not sure. Ideally I could share react component code without actually share React rendering contexts (so different apps using different react versions could use some share of application code)

shadow-cljs will always use node_modules/react

it doesn't care about any other installed versions

what you are describing is not supported since it won't work

you can't just use two different react versions and expect them to work together

@thheller who said anything about using the react versions together?

sharing code is not using them together

it's not sharing runtime memory

then I don't understand your question. "Ideally I could share react component code" so you just have two different builds?

whats the problem though? usually react has been pretty decent with backwards compatibility so using a newer version with something that expects the old one just work?

https://claudiopro.github.io/react-fiber-vs-stack-demo/ would like to build this

but not the way it was done originally, because that's pointless, I figured I do it from cljs, it's a good exercise project.

apparently, it's too good

: D

ah so you want two different builds with one build using one version

and the other using a different version?

thats easy via https://shadow-cljs.github.io/docs/UsersGuide.html#alt-node-modules

just make a build1/package.json with the deps for build1 and build2/package.json

then make the one build use :js-package-dirs ["build1"] etc

well, originally I didn't want two builds, I figured I just alias and use it, but since I gave up for many reasons, some of which you pointed out now I would be fine with a single build to be honest, if it would work, I installed only the experimental react version and it's breaking, I am guessing it's because "experimental" but haven't had the time to actually debug this too. Maybe first I do it in javascript just to be sure it actually works before I start experimenting here too?

no clue what issue you are actually trying to solve here. nothing in the build config will allow you two include two different react versions for one build UNLESS you actually require a differently named version directly in your code

so (:require ["react-foobar" :as react]) or whatever will of course work but overriding :resolve for react will effect everything in the build

thanks, that's clear

if i have a :node-script target is there a way to ask shadow-cljs to run it in the background when i do npx shadow-cljs watch server?

@chris358 there is not no

@jjttjj just released shadow-cljs version 2.8.110 that includes the updated CLJS release 1.10.758 that should fix the self-host issue you ran into

what’s the best way to add externs for GA’s scripts?

the issue I’m running into is I have GA on the page, and call (apply js/ga args) apply checks to see if .-cljs$lang$applyTo exists on the f passed in, which gets munged to like f.d, which actually exists on the ga object 😕

don't use apply then? 😛

there are some externs for google analytics in a google repo somewhere

you can include those

would that work if the GA script is already minified?

that question is weird. the externs are for the script you are including in your page. wouldn't make sense for them to provide externs for you and then minifiy to use different names

but I repeat ... just don't use apply 😛

yeah that’s what I’m going with

the "false" positive behavior of detecting properties that aren't actually from CLJS is a known problem

affects js->clj as well still

can't really do much about those other than adding externs for the properties it clashes with

only reliable way is to treat foreign objects as actually foreign and not expect them to behave like CLJS