I'm somehwat confused by this:

circular dependency: [:shadow.build.classpath/resource "dlt/events.cljs"] -> [:shadow.build.classpath/resource "dlt/core.cljs"] -> [:shadow.build.classpath/resource "dlt/events.cljs"] -> [:shadow.build.classpath/resource "dlt/fx.cljs"] -> [:shadow.build.classpath/resource "dlt/graphql/core.cljs"] {:resource-id [:shadow.build.classpath/resource "dlt/events.cljs"], :stack ([:shadow.build.classpath/resource "dlt/core.cljs"] [:shadow.build.classpath/resource "dlt/events.cljs"] [:shadow.build.classpath/resource "dlt/fx.cljs"] [:shadow.build.classpath/resource "dlt/graphql/core.cljs"])} ExceptionInfo: circular dependency: [:shadow.build.classpath/resource "dlt/events.cljs"] -> [:shadow.build.classpath/resource "dlt/core.cljs"] -> [:shadow.build.classpath/resource "dlt/events.cljs"] -> [:shadow.build.classpath/resource "dlt/fx.cljs"] -> [:shadow.build.classpath/resource "dlt/graphql/core.cljs"]

nothing, and by that I really mean nothing, requires dlt.core

yet, somehow, it seems to say that dlt.events requires dlt.core

the only thing that requires dlt.core, if anything, is that it's :modules {:main {:entries [dlt.core]}} in the shadow-cljs.edn

(and the after-load)

"dlt/events.cljs" is the circle

it requires core?

the message indeed seems incorrect and confusing

no, it doesn't require core

(ns dlt.events (:require-macros [cljs.core.async.macros :refer [go]] [dlt.util.macros :refer [p<! jsp<!]]) (:require [clojure.string :as s] [re-frame.core :as re-frame] [dlt.db :as db] [dlt.fx :as fx] [dlt.util.core :as u]))

I mean, as I said, the only mention of dlt.core anywhere is in the shadow-cljs.edn for the :entries thing

what does dlt.fx look like?

and dtl.graphql.core?

(ns dlt.fx (:require-macros [cljs.core.async.macros :refer [go]] [dlt.util.macros :refer [p<! jsp<!]]) (:require [clojure.string :as s] [re-frame.core :as re-frame] [dlt.graphql.core :as gql] [dlt.util.core :as u]))

(ns dlt.graphql.core (:require [clojure.string :as s] [graphql-builder.parser :refer-macros [defgraphql]] [graphql-builder.core :as gql-builder] [reagent.core :as r] [re-frame.core :as re-frame] [apollo-client :refer [ApolloClient createNetworkInterface]] [graphql-tag :as gql] [dlt.util.core :as u]))

(ns dlt.util.core (:require [cljs.core.async :as async] [clojure.string :as s]))

(ns dlt.db)

and that's all the namespaces involved

strange indeed

do you maybe have a duplicate file somewhere that could cause a conflict?

src/main and src/test both having a dlt.core or so?

~/code/dlt-frontend-shadowcljs master [1+] ❯ ag dlt.core src/clj/dlt/core.clj 1:(ns dlt.core) src/cljs/dlt/core.cljs 1:(ns dlt.core public/index.html 29: <script>dlt.core.init();</script> shadow-cljs.edn 26: :modules {:main {:entries [dlt.core]}} 33: :after-load dlt.core/on-js-reload assets/index.html 29: <script>dlt.core.init();</script>

any of the othrs?

not really, no

would it help trying to blow away the output js dir?

I had a version with a circular dependency at some point, but I fixed that by factoring the circular bits out into that fx namespace

hmm not aware of any caching bugs currently but maybe you found one

just delete the target/shadow-cljs/builds directory

and restart the compile

no joy

circular dependency: [:shadow.build.classpath/resource "dlt/events.cljs"] -> [:shadow.build.classpath/resource "dlt/core.cljs"] -> [:shadow.build.classpath/resource "dlt/events.cljs"] -> [:shadow.build.classpath/resource "dlt/fx.cljs"] -> [:shadow.build.classpath/resource "dlt/graphql/core.cljs"] {:resource-id [:shadow.build.classpath/resource "dlt/events.cljs"], :stack ([:shadow.build.classpath/resource "dlt/core.cljs"] [:shadow.build.classpath/resource "dlt/events.cljs"] [:shadow.build.classpath/resource "dlt/fx.cljs"] [:shadow.build.classpath/resource "dlt/graphql/core.cljs"])} ExceptionInfo: circular dependency: [:shadow.build.classpath/resource "dlt/events.cljs"] -> [:shadow.build.classpath/resource "dlt/core.cljs"] -> [:shadow.build.classpath/resource "dlt/events.cljs"] -> [:shadow.build.classpath/resource "dlt/fx.cljs"] -> [:shadow.build.classpath/resource "dlt/graphql/core.cljs"]

I guess I can push the repo somewhere

(if you want to have a look)

that would help

https://github.com/bwalex/dlt-frontend-shadowcljs

it's a mess, including the commit messages, but there it is 🙂

looking into it

one quick note: the :exlusions are incorrect, just one vector with symbols, no nested vectors

changed, thanks

(somehow did work well enough to get rid of my issues though - a warning with cuerdas and the fact that I wanted to use react 16 instead of 15.something)

maybe someone thought of useless users like me and added a flatten in there 😛

ah found it

events -> fx -> graphql.core -> events

dunno why the error message contains the others

doh. sorry

cljsjs is all ignored anyways so it doesn’t matter much which version you have on the classpath

only their externs are used

@thheller thanks for looking into it for me

np, now I have a good example to use to tweak the error message

that error definitely didn’t help at all 🙂

you also don’t need clojure,clojurescript in the deps

shadow-cljs provides those

and thats just my preference but do you really like putting everything into separate source paths?

well, as I warned you a few days ago, I've only started looking into clojurescript ~2 weeks ago

so my opinions are, well, based on random bits and pieces that I've seen

some of the lein-fighweel boiler plates for reagent or re-frame did that structure of src/clj/foo, src/cljs/foo

hehe ok. it is totally fine to put .clj files next to .cljs files

yeah no idea why they do that

it did feel a bit awkward for example for my dlt.styled thing

where macros live in one directory, and the rest in another entirely

yeah. I typically have a src/main where all sources live clj,cljs,cljc

src/test for tests etc

yea, sounds like a plan. I might reorganize it like that

the one .js include you have might get you in trouble at some point

I would also put that directly into the folder of the .cljs if possible

how so?

going “outside” the classpath is not actually safe

ah!

reason is if you want to put things in a .jar and publish that, the relative path will be invalid since it wouldn’t be in the jar

yea, makes sense

(relative paths aren’t supported in jars anyways yet)

fixed the error, next release will show the error properly. (eg Circular dependency detected: circular.foo -> circular.util.lib -> circular.foo)