Fork me on GitHub
#shadow-cljs
<
2021-05-12
>
mbertheau03:05:57

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

thheller07:05:09

the docs mention that, you can run them while watch is running

mbertheau07:05:58

Indeed! Sorry I missed that. Thanks!

mbertheau03:05:36

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

thheller07:05:48

dunno, I'm guessing they are all anonymous functions?

Robert Pofuk07:05:51

Hi! I was trying to set

:module-loader    :no-inject
Based on code https://github.com/thheller/shadow-cljs/blob/master/src/main/shadow/build/targets/browser.clj should be ok:
;; 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)
But spec for module loader forces bolean (s/def ::module-loader boolean?) What is missing in my setup to avoid inclusion of module loader in js?

thheller07:05:10

@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

Robert Pofuk07:05:11

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]}
App 2:
MODULES:
:main {:entries [:react, :material-ui]}
:feature-2 {:entries [alpha/feature-2]}
App 3:
MODULES:
:main {:entries [:react, :material-ui]}
:feature-3 {:entries [alpha/feature-3]}
Then I would be able to load javascript produced from :feature-1 and :feature-2 modules into APP3 . All of them are compiled using :simple optimization and are forcing for all shared deps to be in main module. My assumption here was that I will be able to override loadig of modules and put in :feature-1 and :feature-2 modules inside
var shadow$modules = {"uris":{"main":[],
                      "feature-1":[""]},
                      "feature-2":[""]},
                      "infos":{"main":null,"feature-3":["main"]}};

thheller07:05:34

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

Robert Pofuk07:05:52

All of them are compiled using :simple optimization

thheller07:05:26

even then that is questionable, :simple is also gigantic

thheller07:05:42

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

thheller07:05:10

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

thheller07:05:56

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

Robert Pofuk07:05:35

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.

thheller07:05:46

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

thheller07:05:26

you can't possibly regain that loss from sharing code

thheller08:05:12

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

thheller08:05:34

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

thheller08:05:49

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

Robert Pofuk08:05:57

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.

Franklin09:05:22

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#))))

Franklin09:05:44

and I call it as follows:

Franklin09:05:01

(utils-events/reg-event-assoc-in ::accounts-dropdown-selected-option
                                [:accounts-dropdown :the-selected-option])

Franklin09:05:49

shadow-cljs keeps throwing this error:

4 | (utils-events/reg-event-assoc-in ::enable-new-project-modal?
-------^------------------------------------------------------------------------
Syntax error macroexpanding cljs.core/fn.
Call to cljs.core/fn did not conform to spec.
-- Spec failed --------------------

  ((clojure.core/apply
    clojure.core/vector
    (clojure.core/seq
     (clojure.core/concat
      (clojure.core/list 'quagga.utils.events/db__31345__auto__)
      (clojure.core/list
       (clojure.core/apply
        clojure.core/vector
        (clojure.core/seq
         (clojure.core/concat
          (clojure.core/list 'quagga.utils.events/_)
          (clojure.core/list
           'quagga.utils.events/value__31346__auto__)))))))) ...)
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

should satisfy

  vector?

or value

  ((clojure.core/apply ... ...) ...)
    ^^^^^^^^^^^^^^^^^^

should satisfy

  vector?

-- Relevant specs -------

:shadow.cljs.devtools.cljs-specs/param-list:
  (clojure.spec.alpha/and
   clojure.core/vector?
   (clojure.spec.alpha/cat
    :params
    (clojure.spec.alpha/* :shadow.cljs.devtools.cljs-specs/binding-form)
    :var-params
    (clojure.spec.alpha/?
     (clojure.spec.alpha/cat
      :ampersand
      #{'&}
      :var-form
      :shadow.cljs.devtools.cljs-specs/binding-form))))
:shadow.cljs.devtools.cljs-specs/params+body:
  (clojure.spec.alpha/cat
   :params
   :shadow.cljs.devtools.cljs-specs/param-list
   :body
   (clojure.spec.alpha/alt
    :prepost+body
    (clojure.spec.alpha/cat
     :prepost
     clojure.core/map?
     :body
     (clojure.spec.alpha/+ clojure.core/any?))
    :body
    (clojure.spec.alpha/* clojure.core/any?)))

Franklin09:05:57

any pointers on how to fix this?

Franklin09:05:02

can I silence the spec checks?

thheller09:05:47

the _ is the problem, use ignored# or so instead

thheller09:05:09

also this doesn't need to be a macro at all, just use a function

thheller09:05:14

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

thheller09:05:50

you can't silence the spec checks since they are telling you that your code is incorrect and won't compile

Aron11:05:29

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?

thheller11:05:23

:node-test already takes CLI arguments

Aron11:05:42

already I start to feel stupid

thheller11:05:52

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

thheller11:05:34

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

Aron11:05:27

you don't mean config-merge I am sure

thheller11:05:43

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

thheller11:05:58

not a build option at all, just a runtime thing

thheller11:05:22

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

Aron11:05:17

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

Aron11:05:53

compile the tests with different fixtures/mock data

thheller11:05:09

what you do in your tests is up to you

Aron11:05:54

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

thheller11:05:38

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

thheller11:05:03

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

Aron11:05:38

thank you, immensely helpful as ever