could be a side effect of you now getting different code due to the "exports" support I added

That appears to be more breaking than I hoped for

you can revert back to the old behavior by setting :js-options {:ignore-exports true} for now

can you say which dependency is causing that? need some more libs to test against I guess

I suspect react-bootstrap but I'll post a stacktrace in a moment.

thx

(FYI: adding that option indeed fixes the issue for me)

if you feel like it you can try 2.24.0 without that setting, maybe that also works

changed the defaults to be more conservative, might also make :ignore-exports true the default if more problems come up

I just tried, 2.24.0 seems to work again without the option. Thanks! 🙂

good to know. thanks.

🚀

I had a similar issue with highlight.js going from 2.23.5 to 2.23.6: require "./lib/languages/clojure" for package "XXX/node_modules/highlight.js" not exported which was solved by adding :ignore-exports (bumping to 2.24.0 didn't solve it)

https://github.com/thheller/shadow-cljs/issues/1125

@U05224H0W Hi, i have got the mentioned problem with 2.26.0, I just upgraded from 2.21.0

[:app] Compiling ...
[:app] Build failure:
package @headlessui/react had exports, but could not resolve ./dist/components/dialog/dialog
{:package #object[java.io.File 0x4ca96c7e "/Users/akiz/Projects/BIM/backend-api/node_modules/@headlessui/react"], :require-from nil, :rel-require "./dist/components/dialog/dialog"}
ExceptionInfo: package @headlessui/react had exports, but could not resolve ./dist/components/dialog/dialog
	shadow.build.npm/find-resource-in-package (npm.clj:807)
	shadow.build.npm/find-resource-in-package (npm.clj:793)
	shadow.build.npm/find-resource (npm.clj:923)
	shadow.build.npm/find-resource (npm.clj:847)
	shadow.build.resolve/find-npm-resource (resolve.clj:123)
	shadow.build.resolve/find-npm-resource (resolve.clj:94)
	shadow.build.resolve/eval12174/fn--12177 (resolve.clj:266)
	clojure.lang.MultiFn.invoke (MultiFn.java:244)
	shadow.build.resolve/find-resource-for-string (resolve.clj:81)
	shadow.build.resolve/find-resource-for-string (resolve.clj:70)
	shadow.build.resolve/resolve-string-require (resolve.clj:464)
	shadow.build.resolve/resolve-string-require (resolve.clj:447)
	shadow.build.resolve/resolve-require (resolve.clj:679)
	shadow.build.resolve/resolve-require (resolve.clj:672)
	shadow.build.resolve/resolve-deps/fn--12123 (resolve.clj:52)
	clojure.lang.PersistentVector.reduce (PersistentVector.java:343)
	clojure.core/reduce (core.clj:6885)
	clojure.core/reduce (core.clj:6868)
	shadow.cljs.util/reduce-> (util.clj:42)
	shadow.cljs.util/reduce-> (util.clj:41)
	shadow.build.resolve/resolve-deps (resolve.clj:50)
	shadow.build.resolve/resolve-deps (resolve.clj:34)
	shadow.build.resolve/resolve-symbol-require (resolve.clj:666)
	shadow.build.resolve/resolve-symbol-require (resolve.clj:626)
	shadow.build.resolve/resolve-require (resolve.clj:676)
	shadow.build.resolve/resolve-require (resolve.clj:672)
	shadow.build.resolve/resolve-deps/fn--12123 (resolve.clj:52)
	clojure.lang.PersistentVector.reduce (PersistentVector.java:343)
	clojure.core/reduce (core.clj:6885)
	clojure.core/reduce (core.clj:6868)
	shadow.cljs.util/reduce-> (util.clj:42)
	shadow.cljs.util/reduce-> (util.clj:41)
	shadow.build.resolve/resolve-deps (resolve.clj:50)
	shadow.build.resolve/resolve-deps (resolve.clj:34)
	shadow.build.resolve/resolve-symbol-require (resolve.clj:666)
	shadow.build.resolve/resolve-symbol-require (resolve.clj:626)
	shadow.build.resolve/resolve-require (resolve.clj:676)
	shadow.build.resolve/resolve-require (resolve.clj:672)
	shadow.build.resolve/resolve-deps/fn--12123 (resolve.clj:52)
	clojure.lang.PersistentVector.reduce (PersistentVector.java:343)
	clojure.core/reduce (core.clj:6885)
	clojure.core/reduce (core.clj:6868)
	shadow.cljs.util/reduce-> (util.clj:42)
	shadow.cljs.util/reduce-> (util.clj:41)
	shadow.build.resolve/resolve-deps (resolve.clj:50)
	shadow.build.resolve/resolve-deps (resolve.clj:34)
	shadow.build.resolve/resolve-symbol-require (resolve.clj:666)
	shadow.build.resolve/resolve-symbol-require (resolve.clj:626)
	shadow.build.resolve/resolve-require (resolve.clj:676)
	shadow.build.resolve/resolve-require (resolve.clj:672)
	shadow.build.resolve/resolve-deps/fn--12123 (resolve.clj:52)
	clojure.lang.PersistentVector.reduce (PersistentVector.java:343)
	clojure.core/reduce (core.clj:6885)
	clojure.core/reduce (core.clj:6868)
	shadow.cljs.util/reduce-> (util.clj:42)
	shadow.cljs.util/reduce-> (util.clj:41)
	shadow.build.resolve/resolve-deps (resolve.clj:50)
	shadow.build.resolve/resolve-deps (resolve.clj:34)
	shadow.build.resolve/resolve-symbol-require (resolve.clj:666)
	shadow.build.resolve/resolve-symbol-require (resolve.clj:626)
	shadow.build.resolve/resolve-require (resolve.clj:676)
	shadow.build.resolve/resolve-require (resolve.clj:672)
	shadow.build.resolve/resolve-deps/fn--12123 (resolve.clj:52)
	clojure.lang.PersistentVector.reduce (PersistentVector.java:343)
	clojure.core/reduce (core.clj:6885)
	clojure.core/reduce (core.clj:6868)
	shadow.cljs.util/reduce-> (util.clj:42)
	shadow.cljs.util/reduce-> (util.clj:41)
	shadow.build.resolve/resolve-deps (resolve.clj:50)
	shadow.build.resolve/resolve-deps (resolve.clj:34)
	shadow.build.resolve/resolve-symbol-require (resolve.clj:666)
	shadow.build.resolve/resolve-symbol-require (resolve.clj:626)
	shadow.build.resolve/resolve-require (resolve.clj:676)
	shadow.build.resolve/resolve-require (resolve.clj:672)
	shadow.build.resolve/resolve-entry (resolve.clj:686)
	shadow.build.resolve/resolve-entry (resolve.clj:685)
	clojure.lang.PersistentVector.reduce (PersistentVector.java:343)
	clojure.core/reduce (core.clj:6885)
	clojure.core/reduce (core.clj:6868)
	shadow.cljs.util/reduce-> (util.clj:42)

And I was able to solve it with :ignore-exports true

exports is a way for npm packages to restrict which files you are allowed to directly required. I'm guessing the package maintainers don't want you to access this directly.

@U05224H0W this is from the official documentation. import { Dialog } from '@headlessui/react'

yes, thats fine

Got it. I guess a lot of things have changed in the new versions, thanks :-)

you mean shadow-cljs? the only thing that changed is the added support for exports. previously it was just ignored. to be clear, what it doesn't like is you doing (:require ["@headlessui/react/dist/components/dialog/dialog" :as Dialog]), when they want you to do (:require ["@headlessui/react" :refer (Dialog)])

but there are benefits to your style, so I think :ignore-exports is the correct way to go

exports is still relatively new and many packages are pretty strict in what they export. note that this is entirely on the side of the npm package itself, not shadow-cljs. shadow-cljs is just following the rules for exports.

I got another bug when i upgraded https://clojurians-log.clojureverse.org/reagent/2023-03-09 But it was a quick fix. So i guessed there were more changes ;)

And thank you again!

under http://localhost:9630/runtimes you can see the connected runtimes

there should be one browser-worker showing up in addition to the regular browser one

when connected to the normal CLJ nrepl you may select the worker via (shadow/repl :app {:runtime-id <id-of-worker>})

shadow alias being shadow.cljs.devtools.api

it is a bit manual since no editor unfortunately provides any kind of mechanism to select this

:cljs/quit drops you down back to the CLJ repl, so you can switch back and forth. or just open a second connection of stay connected to both

the id of the runtime is also logged in the browser console, but you'll see both

Thanks! got it all working, a bit of hassle compared to the normal way but I guess like you said thats on cider/conjure/etc

there is not really anything else to know about it, reads a resource and inlines it

anything in particular you want to know?

I guess it just seems unusual to reach out to a build tool from within project source code.

consider that code a library where I'm just to lazy to make it an actual separate library 😛

I find it hard to consider you too lazy!

An argument for mentioning this in the user guide: When I'm trying to figure out how to do something with shadow, I go to the user guide and skim and ctrl+f my way around before turning to slack. If this was mentioned in the user guide would've saved me from pestering folks here 😁

TLDR; it is not possible. you may find a few tricks to do, but clojure do not support circularity in general. not sure about closure compiler, but closure compiler makes harder because smashes every var name in your code. One trick: add an export

(ns my.cool-ns)
(def ^:export my-global ...)

I see. Maybe also something with the namespace object, which seems to carry all the code. (???)

namespace is not a thing in clojure you can't pass a namespace as a parameter in clojure code. despite that both in JVM and JS you actually can. because of reasons. but it is not a supported/public api.

maybe in the future, with the advance of :as-alias (a new feature from clj 1.11+) circular namespaces will be possible

I just tried(j/get-in rad-mapper.evaluate ["processRM"]) and was able to run the function "processRM" that evaluated to. NS j is just the applied-science.js-interop.

Of course, might stop working any day now.

@U0D4UL3U2 you need to test with cljs advanced build. I think that the way you did only works in non-optimized builds

(or say that you dont care about your app size and do not use advanced at-all. more people than I would like do that)

advanced build = release in shadow

Yeah, makes sense. Good enough for today's demo I think running under shadow-cljs watch, I think. :face_with_peeking_eye:

Cancel that. Only works in repl.

don't being afraid of the interop (some-> js/window .-rad_mapper .-evaluate .-processRM)

In compiled code I get "Cannot infer target type"

add a few random ^js

(some-> ^js js/window ^js .-rad_mapper ^js .-evaluate ^js .-processRM)

(let [^js process-rm (some-> ^js js/window ^js .-rad_mapper ^js .-evaluate ^js .-processRM)]
-----------------------------------^--------------------------------------------

hummm ns .. :require [[goog.object :as gobj]] (gobj/getValueByKeys js/window "rad_mapper" "evaluate" "processRM")

That worked! Thanks!😄

To be clear. It worked well enough for the demo. As you suggested, it doesn't work on under a release compile. I think that's going to be okay because the code I'm trying to run runs under the Small Clojure Interpreter (SCI) and I think I can untangle my use of SCI from these namespaces.

A little binary chopping indicates the issue was introduced in v2.23.6

Possibly https://github.com/thheller/shadow-cljs/commit/97d1500d86972caaed6c1860af66ac59cf5e6e6b

@U05224H0W you seem to have been doing quite a bit with package.json exports recently, is there something we should be doing differently following these changes?

see https://github.com/thheller/shadow-cljs/issues/1125

until then you can set :js-options {:ignore-exports true} in the build config

I didn't expect wildcard exports to be so common, thought we could do without but apparently not

no worries—thanks for the quick response.

IIRC that’s a setting tweakable in a CLJS REPL, not really a bug with shadow-cljs. I remember seeing something like being able to configure how the CLJS REPL decides to print a var

After experimenting with :def-emits-var, I take back my statement. I thought it would’ve been related to that. But I see this in Emacs as well

I’ve bisected it a bit more. It was introduced in https://github.com/thheller/shadow-cljs/blob/master/CHANGELOG.md#2210---2023-02-19.

Did you catch this post, @U05224H0W? I don’t mean to nag. It’s not a big problem. Just want to check if you’re aware.

its just a printing issue. I made some changes for the Inspect UI, and one of those changes was defaulting to showing datafy'd output

the REPL was a accidental victim for that too, but so far didn't get any complaints

so what you are seeing is just a datafied var, where the default implementation wraps that in a vector, just like atoms

its still just a regular var, so all working fine 😛

Certainly. Things work fine and I have not really noticed this until it was pointed out to me. However, I imagine it could be problematic if a REPL output consumer is not a human. Would you consider a PR restoring the old REPL output?

no PR necessary. just open an issue so I don't forget. I've been meaning to fix it, just forgot.

might get to it later today

Issue filed. 😃

chrome exts are very picky about loading files. did you reload the extension properly? this has to be done manually unfortunately. so every change you make cannot be hot loaded or anything, you actually need to manually reload it.

otherwise everything should be there. assuming it was required by the build in a regular require and so on

local deps work just like any other dep, so that should not be a factor

which version do you use though? I made a few changes to :esm recently, could be that you are using a bad one?

btw in case it was unclear I updated the docs a little

https://shadow-cljs.github.io/docs/UsersGuide.html#deps-edn

you don't have to use the clj command line switch just to run with deps.edn. that is optional.

I tested with 2.24.0 and everything is still working fine in the demo

yep, reloaded must be a mistake in the dep, hmm

as for version, it's "2.23.8" (maven); so I'll see if bumping makes a difference

different problem after bumping :thinking_face:

is it :deps {:aliases [:cljs]} that allows running shadow-cljs as normal then? 🙂

nothing wrong with the local dep / require afaict but still no corresponding compiled js

reagent problem unrelated I suspect

Huh. After removing the extension and re-`Load unpacked`ing, all is now fine.

Hope I don't have to do that after every change! 😅

Apparently not. Just reload. Nice.

god extensions are annoying

but thanks for your help @U05224H0W!

but evidently not just reload for some things

(spotty signal on a train; messages may be arriving out of order)

yeah the chrome exts with v3 manifests got even stricter, so we can't do any hot-reload or REPL anymore since eval is forbidden

and it only sees files that were present when the extension was first loaded

changes made afterwards lead to sort of chaos

:deps {:aliases [:cljs]} is all yes. well in your fork you called the alias :shadow-cljs and had :main-opts in there. should remove :main-opts if you intend to run with just shadow-cljs, and change to match the alias name of course

yeah I miss the days of mv2 + https://github.com/binaryage/chromex/tree/master/examples/shadow

> and it only sees files that were present when the extension was first loaded > changes made afterwards lead to sort of chaos 🙃 good to know!