I can change above to

(ns foo)
(declare *a)
(coment
  (def *a (....))

well hot reload and REPL are somewhat at odds with each other sometimes

suppose you have

(defn a [])

(defn b []
  (a))

regularly in a file and rename (defn a []) to (defn x []) without changing b

I want to get a warning for that immediately and not at some arbritrary time later when I restart the build or something

But consider my use case, it is possible to tell shadow to not erase the declaration for vars beginning with a * ?

there is no setting to disable the namespace "reset" for hot-reload

no there is not

Then what’s your workflow regarding this? Hotload is great, but on the other hand, it breaks the interactive testing loop cycle.

I never have these kinds of defs

(comment
  (tap> (result-of-some-http-req)))

is what I would have

but honestly given hot-reload I barely use the REPL for CLJS

I mean if you reload the file via the REPL in the first place

After the tap, what’s the next step? How can you look into some nested data fields of the result? Some tools like portal?

eg. load-file it will not be reset

the shadow-cljs inspect UI

http://localhost:9630/inspect-latest

One thing to mention, it does not has much to do with the REPL. I mostly perform evaluation in the comment block with the repl panel closed. It’s just things def-ed in the comment block are resetted.

thats a weird statement. I mean what do you care about it getting reset if you don't look at it anyways?

I mean you can always move things to a namespace not part of the actual build

those won't get reset or touched in any way

(comment
  (def *a (some-stuff))
  (def *b (:key *a))
  )

I considered (def x/a (some-stuff) but it’s definitely results in syntax error.

well, not removing the analyzer data hides all sorts of issues

I can add a flag to not do the reset, thats not a big deal

Awesome. One more thing, what part does the magic? I am interested.

https://github.com/thheller/shadow-cljs/blob/22d875f9b0a8a9cd5f07ee8fad590eb0fd511558/src/main/shadow/build/data.clj#L240

please open an issue for this. can't get to it today and might forget otherwise

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

Btw, will the previously required names, e.g., (require ’[foo :refer [bar]), will the bar be kept around after a reload?

no, the entire analyzer data is reset for that namespace

Just wanna make sure after the new flag, the above bar is also kept.

:advanced is whole program optimization. :modules just splits the final output into multiple files. it still needs to compile everything all at once.

no, this also cannot be done incrementally in any way

Ok, thanks for clarifying

I guess you are running shadow-cljs in an embedded/repl context somehow that binds *warn-on-reflection* to true globally? normally you shouldn't see those?

makes sense, gonna dig in, thanks!

Seems that it only occurs in React18. React17 works.

graaljs is rather limited and does not have the common browser features

I guess react just assumes TextEncoder is present and wants to use it?

nothing to do from the shadow-cljs side. this is just graaljs being very limited and honestly I would strongly recommend to just use node instead

Yes. I will try to polyfill. I'm just having fun and learning about graaljs

btw, graaljs is undocumented because it is unstable/unsupported?

well, I consider it incomplete since you really can't do much with it

but thats really a graaljs problem not a shadow-cljs problem

no async support, no common APIs, pretty much nothing

That limitations are by design (the don't want to implement it) or it just incomplete because it is in development?

seems that graaljs@node-mode has TextEncoder. Anyway thanks thheller. Now I know what to do https://github.com/oracle/graaljs/blob/f13548b2536971b58c185ba37dc50e6cc29fe968/graal-nodejs/test/parallel/test-whatwg-encoding-custom-interop.js

I haven't figured out how you can run the scriptengine with node mode enabled. so far it just seems to be available as a node executable replacement

I don't follow graaljs much. so no clue what their plans are regarding more features

(.eval "js" "TextEncoder = class { encode() {} }") is enough 🙈

BTW, I just leaned about https://blog.cloudflare.com/introducing-the-wintercg/ Seems that a cool project could be WinterGC compliance to graaljs. It may turn graaljs into a nicer target for shadow-cljs 👀

@U05224H0W do you have a list of API's that shadow-cljs need to be able to have a REPL inside graaljs?

that entirely depends on how you use it. it is somewhat possible if you control the JVM side graal context and can just use the java side to eval stuff and so on

the JS side doesn't have any IO built-in so the REPL is pretty much a no-go purely from the JS side

I'm working on add fetch/websocket/other missing api's into graaljs 🙂 https://github.com/souenzzo/inverno/blob/fetch/src/test/br/dev/zz/inverno_test.clj#L27

Still learning A LOT about polyglot/graaljs, but seems to be "just" hard-working

Most of the API's, like textencoder is already present at JDK stdlib.

I’ve had a similar experience using pnpm, in that not all the dependant libraries get installed as happens with npm. Without fully understanding what the issue is, I found that running pnpm i --shamefully-hoist usually fixes this type of issue. The https://pnpm.io/npmrc:

shamefully-hoist
Default: false
Type: Boolean
By default, pnpm creates a semistrict node_modules, meaning dependencies have access to undeclared dependencies but modules outside of node_modules do not. With this layout, most of the packages in the ecosystem work with no issues. However, if some tooling only works when the hoisted dependencies are in the root of node_modules, you can set this to true to hoist them for you.

That did help, thanks 😄

can't say., which shadow-cljs version do you use? older versions didn't properly support symlinks and the node resolve rules fully. current version does but I never tried pnpm so no clue what else might be going on

The latest one that is on the npm registry, so 2.19.5