Can I run build-report at the same time a dev build watch is running, or should I stop the dev build watch first?

And another question: is it expected that the function names in stack traces are less helpful than they maybe could be?

Hi! I was trying to set

:module-loader    :no-inject

;; true to inject the loader data (which changes the signature)
              ;; any other true-ish value still generates the module-loader.edn data files
              ;; but does not inject (ie. change the signature)
              (true? module-loader)
              (inject-loader-setup-release config)

@robert.pofuk thats a boolean only, so just :module-loader false? what are you trying to achieve? that comment refers to old code that doesn't exist anymore

I have multiple we applications, all of them are build with shadow-cljs, clojurescript, react material ui. I would like to share some code between them. Because I would like to avoid re-building all of them every time shared peace of code changes i wanted to modularize them. App 1:

MODULES:
:main {:entries [:react, :material-ui]}
:feature-1 {:entries [alpha/feature-1]}

MODULES:
:main {:entries [:react, :material-ui]}
:feature-2 {:entries [alpha/feature-2]}

MODULES:
:main {:entries [:react, :material-ui]}
:feature-3 {:entries [alpha/feature-3]}

var shadow$modules = {"uris":{"main":[],
                      "feature-1":[""]},
                      "feature-2":[""]},
                      "infos":{"main":null,"feature-3":["main"]}};

that is not possible, separate :advanced builds are not compatible with each other

All of them are compiled using :simple optimization

even then that is questionable, :simple is also gigantic

you can set :module-loader-init false in your build config

and then initialize the loader via shadow.loader/init yourself. you can change the shadow$modules however you want before that

but I strongly advise against doing this. it will have unintended consequences.

I know it is big 4x in my example. But sharing modules between apps would be amazing. I could have multiple teams in parallel developing without having 1 project as bottleneck. Also I could use this feature as feature toggle, rewrite module from scratch and so on... And javascript it self makes it easy to load code on demand and then it would be cool to utilize this in clojurescript. I only did small comparison and 2 different apps create same output of same code in module.

but if you care about performance at all then :simple is a dealbreaker

you can't possibly regain that loss from sharing code

the trouble is that even with :simple some code is rewritten in incompatible ways

if you just want to move out the JS dependencies and share those you can do so by using :js-provider :external

but sharing :modules will end up in trouble at some point

Thank you for help! I will try to figure out if it is worth the risk and load the modules on my own or find a way how to compile things together.

I have a macro that looks like this

(defmacro reg-event-assoc-in [name seq-of-kw]
  `(re-frame/reg-event-db
    ~name
    (fn [db# [_ value#]]
      (assoc-in db# ~seq-of-kw value#))))

I have a beginner question this time. I suspect the answer might not be shadow-cljs related, but I am not sure yet. Basically, I have two different problems related to testing, and I would like to solve them both at once. I am using a :node-test target to compile puppeteer tests that I run manually. The problem is that sometimes I only want to run a single test, but the only way to easily configure this so far was through the :ns-regexp config. Is there a conventional solution to this problem? I can imagine writing an ad-hoc solution that takes CLI arguments and calls the tests or not based on that, but I am always wary of reinventing the wheel. And the second problem is that similarly through CLI arguments, I would like to feed different data to the same tests. Anyone here has some suggestions for some tooling, any kind of tooling, that would make both these problems easier to solve? Or should I just give in and code it up myself?

:node-test already takes CLI arguments

already I start to feel stupid

smh

try --help, or --test=a.single.ns or --test=a.single.ns/test-name

I think I didn't document those when I added them

you don't mean config-merge I am sure

no, when running the test node the-test-file.js --help

not a build option at all, just a runtime thing

trying

the second part with passing custom data is not supported since tests themselves don't take arguments

if I can do any cli based logic, then i can load the necessary data from disk

compile the tests with different fixtures/mock data

what you do in your tests is up to you

I wish, but my colleagues have a say too : )

TEST_DATA=foo.txt node the-test-file.js --test=that.one/test-thing

and in your test (fs/readFileSync js/process.env.TEST_DATA) or whatever

thank you, immensely helpful as ever