Is there a way to filter down tests somehow / only run for a particular file? This issue suggests no: https://github.com/thheller/shadow-cljs/issues/322 Currently simply running them all using a test target:

:test
           {:target    :node-test
            :output-to "out/node-tests.js"
            :ns-regexp "-test$"
            :autorun   true}

@ritt93 for :autorun true no. otherwise yes. see node out/node-tests.js --help

ClojureScript compilation fails for me with shadow-cljs 2.12.2 and ClojureScript 1.10.844. I get a bunch of errors like this:

Multiple files failed to compile.
aborted par-compile, [:shadow.build.classpath/resource "re_frame/interop.cljs"] still waiting for #{reagent.core}
{:aborted [:shadow.build.classpath/resource "re_frame/interop.cljs"], :pending #{reagent.core}}

@flowthing is this in a :browser build?

I did change something regarding this in 2.12.2 but I haven't been able to reproduce

Hi! I’m latest shadow and tools.deps, trying to pass a config map through CLI. my alias looks like this

{:some-alias  
{:extra-deps  {
 thheller/shadow-cljs  {:mvn/version "2.11.23"}}
:main-opts   ["-m" "shadow.cljs.devtools.cli"
                                         "--config-merge" {:some "thing"}]}}

Error while parsing option "--config-merge {:some": java.lang.RuntimeException: EOF while reading

@thheller :node-test, actually.

oh. then I know.

Hi, I'm being bitten by a strange issue when trying to compile Reagent code to React components using Shadow-CLJS. I don't know whether this has to do with Reagent, build configuration or something else. The problem is that when I'm compiling Reagent to React components, the components fail to render on the React side if they use Material UI components, with the error: Uncaught Error: Minified React error #321; visit for the full message or use the non-minified dev environment for full errors and additional helpful warnings. Could this be caused by the fact that Material UI components use React Hooks, which are disallowed in React class components? While debugging this, I set up a minimal test project to investigate the issue: https://github.com/tvirolai/mui-cljs-test. Here, Component1 renders while Component2 (with a Material UI icon) fails with the error. Any idea how to get around the issue? I asked around in the #clojurescript channel a couple of weeks ago, but couldn't find a workaround...

@tvirolai yes, this is related to hooks. ask in #reagent, this is not a shadow-cljs issue

@flowthing should be fixed in 2.12.3

anyone want to leave a reply here: https://ask.clojure.org/index.php/10403/pros-and-cons-figwheel-vs-shadowcljs

I'm too biased to answer 😉

@thheller Many thanks, will give it a try next week!

@thheller I don’t use shadow-cljs currently but I would love you to answer 🙂 Always appreciate your input.

misread sorry. I feel like I shouldn't answer because I have never used figwheel so I'm not qualified to compare it

just listing the shadow-cljs features doesn't really answer that question 🙂

Fair enough 🙂 I’ve been juggling whether I should try shadow-cljs; not having to deal with JS bundlers (webpack etc) is very compelling; However, for my current project in React Native specifically (and I mentioned that in the thread), you still need to use Metro, even if you use shadow-cljs (I am pretty sure that’s the case); so for that setup specifically, it doesn’t feel like it makes a ton of sense for me right now;

I always say to never change a running setup, so what you have now is working properly for you and does what you expect it to do keep it

you'll still use metro regardless yes

I also don't do react-native development so I can't even speak to what figwheel might be doing differntly

I know that the loading mechanism is different but at runtime things are probably quite equal

One problem I did run into, but I’m not sure if shadow-cljs can help with this (and I don’t presume you know, because you don’t do much RN), is integrating a library like reanimated-v2

They do something unusual, in which they use React hooks that add ‘worklet’ in this style: https://docs.swmansion.com/react-native-reanimated/docs/worklets

as someone who briefly used figwheel/main and is now using shadow-cljs, I can say that setting up SCLJS takes much much much less time than figwheel/main

I was struggling to get figwheel-main up for an entire day and all it took was 15 mins with SCLJS

also one more thing I like about SCLJS is the doc itself. Figwheel/main doc was kind of a mess when I was using it, and it contributed to why it was taking so long to set things up.

@rextruong yea the shadow-cljs docs are really top notch

Seems like :target :npm-module is broken in at least 2.12.3:

IllegalArgumentException: No matching field found: stripTypePrefixes for class com.google.javascript.jscomp.CompilerOptions

stripping was removed yes. what is the full stacktrace?

I mean unless you are setting this in your build config it shouldn't be used anyways?

ah right ... npm-module calls it

please open an issue or it'll get lost, can't fix it now

Hi! I tried to implement Inertia.js client side with Shadow-CLJS and Reagent. The documentation give this snippet who contains this following dynamic require

import { App } from '@inertiajs/inertia-react'
import React from 'react'
import { render } from 'react-dom'

const el = document.getElementById('app')

render(
  <App
    initialPage={JSON.parse(el.dataset.page)}
    resolveComponent={name => require(`./Pages/${name}`).default}
  />,
  el
) 

Source: https://inertiajs.com/client-side-setup#initialize-app

For now, I'm stuck with the expected error Uncaught ReferenceError: require is not defined

(ns myreagent.core
  (:require
   ["@inertiajs/inertia-react" :refer [App]]
   [reagent.dom :as d]))


(def el (.getElementById js/document "app"))

(defn home-page []
  [:> App {:initial-page (.parse js/JSON (.. el -dataset -page))
           :resolve-component (fn [name] (.-default (js/require (str "./Pages/" name))))}])

(defn mount-root []
  (d/render [home-page] el))

(defn ^:export init! []
  (mount-root))

@admin055 dynamic require like that is not supported, but you can probably replace it with either just a normal reference or something using shadow.loader

OK, thx for the confirmation.

I don't about shadow.loader, I'll check, thank you. When you say normal reference, you mean like that?

(defn Home [{:keys [name]}]
  [:h1 (str "Hello " name "!")])

(defn home-page []
  [:> App {:initial-page (.parse js/JSON (.. el -dataset -page))
           :resolve-component (fn [name] (r/reactify-component Home))}])

yes

I don't know what intertia.js is so I don't know what it expects, but that would be what I'd guess

OK, in my case this is not suitable because it takes away the principle of Inertia.js.

if this is about code splitting then follow https://code.thheller.com/blog/shadow-cljs/2019/03/03/code-splitting-clojurescript.html

I’m getting these strange errors in a fresh project recently:

107 |   (let [an (rum/react *active-notes)]
 108 |     [:div
 109 |      [:div [:code (pr-str an)]]
---------------------------------^----------------------------------------------
Use of undeclared Var starter.browser/an
--------------------------------------------------------------------------------

shadow version 2.11.23

@thheller Inertia.js seems interesting project that I'll tried to write an back and adapter for Clojure. From the website: "Inertia.js lets you quickly build modern single-page React, Vue and Svelte apps using classic server-side routing and controllers." The dynamic require is use to load the front component base on backend routing. Inertia read the component from the data-page attribute object.

but why does it have to be a dynamic require?

I mean you can use code-splitting but you can also case (case name "foo" ComponentA "bar" ComponentB ...)

@martinklepsch since this is with rum I'm guessing that would be related to https://github.com/tonsky/rum/issues/233

@thheller Yes the case works great but this implies adding the components by hand as the project progresses in this condition + require namespaces, etc.

well yes but at some point you could write a :target :intertia that automates all of that and emits the code optimal for intertia

you shouldn't except a generic :browser (or whatever you are using) build to match what intertia wants

I'm too drained to look into what intertia is so I really don't have a clue what it does or wants

Yeah I understand, your help has already been precious. 😉

Thx Thomas.