Possibly I'm not seeing something obvious here, but I have a namespace with no require

(ns cljs.globals)

(goog-define ENV-NAME "NONE")

(ns cljs.core
  (:require
   [cljs.globals :refer [ENV-NAME]]
....

Circular dependency detected: cljs.core -> cljs.globals -> cljs.core

just dug to the bottom of a problem, having a lot of cljc files but not using java other than compilation and macros, then adding a :require-macros on a file which imports a lot of other files seems to force the clojure part to activate and the compiler "notices" that my cljc files aren't valid, having js/blah and other clojurescript-only things. It's like there's this kind of bomb in my code waiting for me to make a high level file macro-self-referential

because the errors only come up intermittently between big changes, it means that the "space" I have to search for the problem and fix is big, and also these sort of cljc compilation errors often don't give the file/line that explodes, which overall makes it something that causes pain every now and again

this last one took me doubly long because it seems that requiring a defrecord or defitem by name is valid clojurescript but not valid clojure:

(defrecord MyRecord [a b c])
 (:require [my-ns :refer [MyRecord]])

high level file in the sense of importing lots of other files, because failing under clj is transitive to files-importing so I basically have to search the space of all imported files for the problem

one technique which might be superstition is to put (:require-macros [this-ns :refer [dummy-macro]]) #?(:clj (defmacro dummy-macro [] nil)) into files that I consider suspect to force the underneath-clojure-tree to be checked or at least that file itself

sorry I don't have a specific suggestion and this also might be obvious or stupidity on my part but maybe my pain and ignorance is useful somehow

why write .cljc files if you don't want the CLJ side?

I thought it was a necessity to put macros in the same file

It also kind of seemed like good practice, to keep code minimally seperated from clj in case part of the code was later exposed that way, but a combination of the way that it's lazy in checking the clj half works, rough non-file-specific error messages and some pitfalls I didn't know like the record import incongruity mean that this is maybe the third time it's cost me quite a while effectively doing a slow, semi-blind search through the code for cross-compilation problems

if I'm right that self-requiring any macro forces a check that all recursively required files work under clojure then I can do that at the app entry point in future to catch problems (earlier === in a reduced search-space) but I just thought I'd mention it here since it's maybe the most painful thing I've found in cljs development recently

Is there a reason cljs.test wouldn't be available from the repl connected to a shadow-cljs watch process for a :react-native build target? I'm used to being able to run tests for cljs at the repl, but I'm getting TypeError: undefined is not an object (evaluating 'cljs.test.report')

I’m seeking help debugging discrepancies between the shadow watch behaviors I’ve observed on two different OSes (I’m on a Mac M1, and my colleage is on WSL2). Our current hypothesis is that watch treats symlinks differently on Mac and WSL. Observations: When I run shadow watch on my Mac, Shadow runs the build and only re-compiles the CLJS files when I change a file in the src-paths directory. In contrast, when my colleague runs the shadow watch command on his WSL machine, his build loops indefinitely - it will finish compilation and then recompile (in a never-ending loop). The endless cycling behavior in WSL is associated with creating soft symlinks during our build process. Normally, the build emits compiled Javascript into a folder called .compiled-stories and then it symlinks the .compiled-stories folder to another location inside the src-paths directory. When we stop the build from creating the soft symlink of the .compiled-stories directory, the WSL machine does not loop indefinitely. Right now we hypothesize that the shadow watch (or the code it relies on, or WSL itself) somehow treats the WSL and Mac symlinked folders differently. Specifically, it looks like the https://github.com/thheller/shadow-cljs/blob/master/src/main/shadow/util/FileWatcher.java#L34-L46 creates different watchers on Mac vs Linux, so we’re hypothesizing that that could be a factor. Before we start to explore the differences between FileWatchers, we were looking for a sanity check: is there way we can determine why shadow triggered a recompile and trace the causal chain of events leading to a recompile?