I may be wrong, but I feel like the returned build-state from :compile-prepare and/or :compile-finished isn't ending up in the source code, be it watch or release. Just doing string/replace on the string of js resource (nested under :sources [:shadow.build.npm/resource "libcsound/libcsound.js"] :source)

@hlolli what I would suggest is creating a libcsound/libcsound_browser.js and then in package.json use a "browser":{"libcsound/libcsound.js": "libcsound/libcsound_browser.js"} override

this will cause pretty much all JS build tools (including shadow-cljs) to include the libcsound/libcsound_browser.js when building for the browser

but otherwise use the node version

https://github.com/defunctzombie/package-browser-field-spec#replace-specific-files---advanced

@thheller didn't know about this funtionality with "browser", sweet. Was hoping to avoid having two copies of that file. As it would essentialy mean two copies of the wasm binary as well. Is what I'm trying to do, in build-state, assoc-ing-in :sources a new source string, possible?

yes but not recommended because you destroy source maps that way

here my hook

(defn wasm2datauri
  {:shadow.build/stage :compile-finish}
  [build-state & args]
  (let [resrc   [:shadow.build.npm/resource "libcsound/libcsound.js"]
        src     (get-in build-state [:sources resrc :source])
        wasm    (string/trim (:out (sh "node" "libcsound/datauri.js")))
        new-src (string/replace src "libcsound.wasm" wasm)]
    (assoc-in build-state [:sources resrc :source] new-src)))

ah ok, it's only one line, so won't create a new line.

can't do it in :compile-finish though

but I really do not recommend doing it this way

it messes with the cache as well

ah I see.. maybe only in release, as flush?

no it uses cache too I guess

can I calculate sha256sum of the string and replace it with what the cache hash value?

why reinvent the wheel though? "browser" is exactly for cases such as yours?

do you have the code available somewhere? I kinda don't understand what exactly you are trying to do

I'm just trying to avoid having two different files, just create the file/string during compilation

why does it have to be during compilation though?

why not do it before?

trying to do this as part of the compilation itself just makes it 100x more complicated

then I have two 6mb files, 1 is js bindings files from emscripten, another .wasm, and when the .js file gets 6mb with the base64 string, it's hell to open and edit.

no I mean create the file before you run shadow-cljs

node create-that-browser-file.js && shadow-cljs ....

ah yes

haha of course

I can hook shadow to delete it after compilation

bingo!

if the extra file is a problem you could also create a secondary package?

libcsound-browser or whatever

and include that via :resolve settings

yup, that's what I previously did.

and that works too

so I'm only trying to simplify, by having 1 copy of every file that I need.

what you are trying to do doesn't exactly sound simple to me

yes, I can see how you see that. And it's probably true.

you could also use a CLJS macro and read the file directly during compilation

but no idea if that works with the way the js bindings are setup

yes, didn't consider that, a macro. I guess a slurp can be evaled by a macro.

I strongly suggest however that you do whatever you need to do BEFORE shadow-cljs compilation starts

and then compiling everything normally

doing it during compilation will just break in various ways

yes, your suggestion above, just use package.json script and create the file before, sounds clean to me

I have a lein project that I want to use shadow-cljs for, so I included [thheller/shadow-cljs "2.5.0"] in the project.clj deps. However now I get an Exception when I run lein cljsbuild once min:

@pauld there is figwheel in that stacktrace and not shadow-cljs?

I know, very strange.

ah you have a user.clj that loads figwheel on startup

the problem is an old closure compiler version

check lein deps :tree

ah! thanks - that fixed it

I had an older clojurescript dep

I'm wondering if I can run a build report on this lein project.

npx shadow-cljs run shadow.cljs.build-report app report.html

depends on the cljsjs deps. some may not work

yeah I do get an error

Caused by: /home/paul/.m2/repository/cljsjs/create-react-class/15.6.0-1/create-react-class-15.6.0-1.jar deps.cljs refers to file not in jar: cljsjs/create-react-class/production/create-react-class.min.inc.js

thats an old reagent version I think

it was fixed a while ago though.

you can just exclude cljsjs/create-react-class from your deps for that one

I will have to see where it gets pulled. It's a qlkit transitive dependency.

[cljsjs/create-react-class "15.6.2-0"] [cljsjs/react "16.2.0-3"] [cljsjs/react-dom "16.2.0-3"]]

Or is there newer version I should be getting? say from npm?

I get the following error now:

@pauld I would use react and react-dom from npm isntead of cljsjs when useign shadow-cljs

And what if the clojurescript library I use - uses it?

can I do some :excludes to make the switch?

You can just provide it by providing the CLJS namespace.

Like this example: https://github.com/kurtharriger/shadow-cljs-reframe-template/blob/master/src/cljs/cljsjs/react.cljs

That way, your dependent library gets react in the namespace it expects.

you don't actually need those for the most common dependencies

they are provided by https://github.com/thheller/shadow-cljsjs

its just that one exception that had a buggy cljsjs release

otherwise you don't need to exclude cljsjs dependencies

yeah react stuff seems to work after npm install except:

Caused by: The required namespace "cljsjs.material-ui" is not available, it was required by "qlkit_material_ui/core.cljs".

yeah that would require one such wrapper

(ns cljsjs.material-ui
  (:require ["material-ui" :as mui]))

(js/goog.exportSymbol "MaterialUI" mui)

I'm not exactly sure what the global or npm package are for those though

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

but FWIW since you want build-reports anyways. material-ui is one of those huge packages

and its much much better to only include what you actually need.

like @material-ui/core/Button

but qlkit probably assumes that you use everything

yeah... I read that somewhere

I wonder how I would go about trimming down qlkit deployment size

npm installing cljsjs dependencies, putting in excludes, wrapping where necessary and putting in only specific material-ui deps via npm install?

In my example I posted a comparison for antd vs individual antd components

https://clojureverse.org/t/shadow-cljs-build-reports/2284

and thats 1.6mb vs 350kb

material ui is larger than that

the problem is with qlkit. if that always imports the material-ui "meta" package which in turn includes everything else

you won't get a smaller bundle

so only option is to fork qlkit?

geez

https://github.com/forward-blockchain/qlkit-material-ui/blob/master/src/qlkit_material_ui/core.cljs#L2-L3

the svg-icons are another megabyte or so I believe

-rw-rw-rw- 1 thheller thheller 1007K Feb 27 17:59 material-ui.min.inc.js
-rw-rw-rw- 1 thheller thheller  1.4M Feb 27 17:59 material-ui-svg-icons.min.inc.js

2.4mb total

just due to those two requires

for the SVG icons its really important to only import the ones you actually use and not everything

qlkit-material-ui.core is super small. you could probably rewrite it to only include what you need

yeah I think you can take it out completely

the only thing that seems to be relevant is the (ql/regsiter-component ..) call https://github.com/forward-blockchain/qlkit-material-ui/blob/master/src/qlkit_material_ui/core.cljs#L51

so (:require ["@material-ui/core/Button" :default Button]) and (ql/register-component :button Button) may just work?

sounds like it, as long as the register-component is called before qlkit/mount

doing that for all the components and icons you actually use seems to be best

annoying but best 😉

Thanks!

Also material-ui-svg-icons is now depreciated in favor of: @material-ui/icons

yeah you can import each icon individually there too

It could be a fun game to trim this down.

module keys can be namespaced right?

@lilactown no they cannot

well they can but the ns will be dropped

😞

why? what would it accomplish?

I know I’m going to run into an issue eventually where two different experiences might have similar components, e.g.: dashboard/livehelp homepage/livehelp I can simply use dashes instead of slashes, it’s not a huge deal. just aesthetically it would be nice to be able to namespace them

hmm, would there be any harm in adding a build hook that goes before :configure, where I could modify :closure-defines?

maybe I am just editing the wrong piece of the state

ah. I was trying to modify :shadow.build/config, but those settings have already been locked-in elsewhere, so I can instead update-in build-state [:compiler-options :closure-defines]

@mhuebert yeah you can do it in :compile-prepare

@thheller Just wondering about the react-native support. Is this supported or on the roadmap?

@larshelg depends on what you expect to work. I do not use react-native myself and haven't done any work on the support in a while

There is an example: https://github.com/shadow-cljs/examples/tree/master/cljs-react-native-app

:npm-module will work but is sort of limited regarding repl/live-reload

Great, I will give it a try 🙂

Well it would be great with repl/live-reload support. I dont know how hard it would be to implement. But seeing that there is partial support for RN it would be great to have it on the roadmap.

its on the roadmap yes. just don't know when I can get to it since I need to look into react-native stuff first

last attempts always had me frustrated figuring out the metro details

never could get source maps to work for example

Yeah i found this: https://github.com/thheller/shadow-cljs/issues/214

thheller if I have time, I’d like to dig into the RN stuff. would you appreciate any help with that?

any help is appreciated yes

I sure would appreciate it

FWIW I think the only hurdle left were the source maps

which however are very important but I couldn't even figure out if they are even supposed to work at all

documentation on that subject is sparse

https://github.com/facebook/metro/issues/104 nothing happened here so they still might not be supported

I see, but the hot reload is working?

should be yeah

not with :npm-module though

great, i guess no source maps means debugging is a nightmare, but still glad to hear that all the other stuff is working

well with :npm-module you can just use the built-in RN reloading stuff

yeah, I´ll look into it