Based on the exception it seems to be saying that when my app.main.js file is reloaded it evaluates a goog.provide expression and doesn’t have that defined. Parcel is being used to handle the bundling of the npm-module, it should be only importing the assets declared inside of here: https://github.com/seanstrom/cljs-dev-template/blob/debug-build/src/cljs-index.js From what I can see, after I save a change to main.cljs , a script is evaluated for the changes by the shadow devtools. In version 2.21.0 the script will evaluate a script shaped like this:

"var COMPILED = false;

var cognitect=$CLJS.cognitect || ($CLJS.cognitect = {});
var clojure=$CLJS.clojure || ($CLJS.clojure = {});
var cljs=$CLJS.cljs || ($CLJS.cljs = {});
var shadow=$CLJS.shadow || ($CLJS.shadow = {});
var goog=$CLJS.goog || ($CLJS.goog = {});
var app=$ || ($ = {});
var com=$ || ($ = {});

$CLJS.SHADOW_ENV.setLoaded("app.main.js");

goog.provide('app.main');
app.main.render = (function app$main$render(){
var change_me_21185 = "Hello";
var node_21186 = document.getElementById("root");
var text_node_21187 = document.createTextNode(change_me_21185);
node_21186.appendChild(text_node_21187);

return cljs.core.println.cljs$core$IFn$_invoke$arity$variadic(cljs.core.prim_seq.cljs$core$IFn$_invoke$arity$2(["[main]: render"], 0));
});

"goog.provide('app.main');
app.main.render = (function app$main$render(){
var change_me_21191 = "Good Bye";
var node_21192 = document.getElementById("root");
var text_node_21193 = document.createTextNode(change_me_21191);
node_21192.appendChild(text_node_21193);

return cljs.core.println.cljs$core$IFn$_invoke$arity$variadic(cljs.core.prim_seq.cljs$core$IFn$_invoke$arity$2(["[main]: render"], 0));
});

don't do any hot reload at all

just open the webpage

in the console type goog

and then $CLJS.goog

they should be the same object but for some reason are not

I don't know why

but that is the source of the problem. hot-reload will eval in the global scope, thus use the goog object. which for some reason only exists partially

var goog = $CLJS.goog = {}; this line should make sure that it is always the same object

I don't get why it isn't

Well during startup that’s present, but at reload it’s missing, so goog becomes the window.goog and not the $CLJS.goog right?

var global = arguments[3];

this might be the problem. this isn't something shadow-cljs injects. might be parcel doing that?

maybe it has its own notion of what global means?

oh just noticed that your build config is missing :runtime :browser

hmm but that doesn't seem to change anything

I hate :target :npm-module. is there a specific reason you are using that?

and not :target :esm?

or even :js-provider :external?

I added the :runtime :browser , but it didn’t fix the problem. I started using the npm-module format because I couldn’t use the esm format for similar hot-reloading issues. In the esm target, the hot reloading attempts to redefine an existing namespace and throws an exception. Until recently I didn’t have any issues with npm-module format, but I would prefer esm as an option too. I’m not sure what :js-provider :external will do here, but I can try.

In general it seems that maybe the code was relying on that variable statement to always be within the hot reloaded script. I assume it was removed to keep things small, so maybe I can override goog manually and see if my problems are fixed temporarily.

if (process.env.NODE_ENV !== "production") {
  require("../cljs-dist/shadow.cljs.devtools.client.browser.js")

  window.goog = $CLJS.goog;
}

that seems to do it

don't ask the me why that is necessary though 😛

When the script is evaluated it seems to use the window.goog because window is the default global context right? Maybe most of the code just uses the $CLJS namespace most of the time?

hmm I can't remember. :npm-module is one hack after another and not exactly ideal 😛

I would recommend using :esm if you can

Well if window.goog is suppose to be $CLJS.goog could that be defined in cljs_env.js? I’ll try esm and I can show you the other output that I get, one sec.

it is

but I remember something now. I might actually have broken this not too long ago unintentionally

Ah okay, we do you think it might have happened?

note sure but I'm guessing it was this commit https://github.com/thheller/shadow-cljs/commit/7d6ca44906143a69eb5999ce23d67641fe870073

so 2.22.0 likely is the first breaking version

not exactly sure what yet though, still just guessing

I’m trying to debug each commit inside the 2.22.0 release. How do I build the project with all pieces pinned to a specific commit so I can run each commit as a release?

no need. it is the commit I linked

Well how would test that previous commit still works?

just test 2.19?

eh 2.21

If I make a changes to the source code I do I test the changes with a build. I need the latest changes so I can’t use the old build otherwise it just works

then just checkout the version you want

I always just run lein install for local testing

you can build some of the supplemental stuff too if you intend to use the UI or so

but its not required

Okay I’ll try that, I’ve been running build-all until now.

that also works

you can also just add shadow-cljs as a usual dependency

and then add :source-paths ["src/main" "../shadow-cljs/src/main" "../shadow-cljs/target/classes"]

in your project I mean

then it'll just use whatever the current state is, no need to build a jar

That’s great! I’ll give that go

https://github.com/thheller/shadow-cljs/commit/7d6ca44906143a69eb5999ce23d67641fe870073#diff-3416083e4a00d16a8d5520ece8690f4fc988f2b52d639689b8531da6b0be5ba6L764-L782

it is this change I'm fairly certain

that used to add a wrapper for code to pull in all the "locals", so it didn't use any globals

but now it uses globals. I haven't decided how to handle this

you didn't answer why you are not using :esm? 😛

it doesn't have all the old random hacks that :npm-module has, so it should be preferred

The compile output for esm can’t be hot reloaded atm, the source is reloaded and throws an error. I would like to use esm but I don’t think it works with the hot reload.

The esm target throws an exception related to namespace already being defined by goog

Okay here’s an another version of the project but with ESM setup: https://github.com/seanstrom/cljs-dev-template/tree/debug-build-esm

This is the kind of error I get when I hot reload: Error: Namespace "goog.asserts" already declared.

ok, it is time you need to explain what your goal is with all of this. you are using two build tools, each trying to provide basically the same features. and they are interfering with each other big time.

I get a couple of problems, the already declared only being one of them

the problem is parcel hot-reloading way too early, then shadow-cljs trying again

parcel even tries to reload sometimes while shadow-cljs is still writing the file, so I get EOF errors

The goal is to use a JS bundler for bundling JS dependencies and watching reloading JS and CSS. I don’t want to deal with JS externs and other issues with importing JS dependencies through the normal build pipeline, and I want to hot reload css changes.

Yeah I gave up on using Parcel because I cant prevent it from watching the CLJS output. I pushed up a working build configured with the ESM output from Shadow and Vite.

https://github.com/seanstrom/cljs-dev-template/tree/debug-build-esm

https://shadow-cljs.github.io/docs/UsersGuide.html#js-provider-external

that sounds like what you want?

> I don’t want to deal with JS externs

none of that eliminates the need for externs? in fact you'll need MORE if shadow-cljs isn't processing npm dependencies?

> I want to hot reload css changes.

shadow-cljs can do that on its own?

What about importing svg files? or Sass files, or any other media types that the JS tooling supports?

The point is to use the JS tooling for pieces of the JS ecosystem that I can’t get from Shadow

And I want to shadow to manage the CLJS stuff because it basically the only option for compiling stuff with hmr (outside of Figwheel and building my own).

Ideally I would have a cljs to esm compiler, with repl and hot-reloading support. And that should be able to work as along as I don’t use to hot reloaders for the CLJS stuff

Because it seems that way shadow hot reloads stuffs is more specific than just a re-eval the whole file right?

:target :external sounds like what you want here?

just found a bug in :esm, but thats beside the point

your template seems to work, just need to update shadow-cljs. template is using 2.22.0, 2.22.9 works

https://code.thheller.com/blog/shadow-cljs/2019/08/25/hot-reload-in-clojurescript.html

that explains how it reloads stuff

Version 2.22.9 does not work for me with the Parcel JS configuration. It works only if I add the extra window.goog = $CLJS.goog to it.

I only tested vite now?

but literally. your use case sounds exactly like what :js-provider :external is designed to do

you don't lose anything. you only lose headaches because vite/parcel/whatever don't need to process the CLJS output

js-provider :external would only configure the CLJS output to represent JS dependencies as require expressions right?

That would happen when I import stuff into CLJS that’s JS right? If I have to independent systems of JS and CLJS I need a bundler that works with both. The viewpoint here is that it’s a headache to do JS stuff in the CLJS tooling without going all-in on the CLJS way of doing stuff.

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

it does not no

but yes, the js bundler will only see JS dependencies

it will not touch CLJS code at all

the only thing you can't do is access the CLJS code from JS

the CLJS code can access JS just fine, but it is one way

well, if you like hacks you can make it both ways but I wouldn't recommend that

I don’t think we’re talking about the same stuff. Look at the original example, it broke because the semantics of npm-module hot reloading has changed right?

It used to be scoped but not it relies on globals instead right?

I came here looking to fix that

I can add this snippet: window.goog = $CLJS.goog somewhere in my file, but that seems like a hack

So im trying to avoid my builds exploding because the outputs from CLJS don’t quite mesh well with every other JS bundle tool because of google closure stuff and side effects for declaring namespaces inside of all the modules

No matter how many ways I can configure :js-provider :external that doesn’t solve the issue of organizing a polyglot project

I need both JS and CLJS to play nice

That’s a reasonable take when you build both systems actively

It seems that the best way to avoid headaches is to disable Vite’s (or Parcels) HMR for any CLJS assets. How is that a hack?

it is not?

ok, so vite now works perfectly fine for me

just was way slower than it needed to be but I fixed that

Did you make a change to the project configuration?

no

well, updated to 2.22.9

The vite was working for me with 2.22.0, but I’ll also try 2.22.9 just to confirm. Would you say this is a hack when: • Shadow controls all the CLJS reloading still • Vite only controls unrelated CSS and JS stuff that isn’t being touched by the CLJS

no, not a hack. that is a supported use case, which may have rough edges since not many people do this

yup yup, I can feel the bleeding edge at this point 😅

I can confirm that 2.22.9 also works for me

:js-options {:js-provider :import} you need to add to the build config once you want to start using actual JS code

since otherwise shadow will still try to bundle on its own

Ahh good call, ill add that

vite config you may want to change to ignored: ['**/cljs-dist/cljs-runtime/**'],, so it'll still pick up new npm depencencies and such

and let me make a new release so everything isn't so horribly slow

Nice, thank you!

I guess the bonus here is that I’m using the esm format now, so I don’t have that npm-module bug

Do you still want help fixing npm-module goog thing?

the problem is that :npm-module is using the same shadow.cljs.devtools.client.browser namespace as the :target :browser does

but they are fundamentally incompatible with each other in how they need to reload stuff

so I'd like to avoid having a bunch of if in that ns, checking what it is supposed to do

but I guess thats what is needed

try 2.22.10 btw, :esm much faster

Nice! just try it and works like a charm 🎉

Will you be able to completely remove npm-module at some point?

no reason to break people using it, so no need to remove it

but I always try to steer people away from it because its use is pretty niche

I still want to fix it regardless, stuff that exists should work after all

I like that vite only touches the import paths and nothing else it seems. that is ideal as far as shadow is concerned

Good to know!

Overall, thanks for the help, and sticking through to confirm that this new solution seems more maintainable

For the npm-module stuff, do you think it would be easier to include all of the window.goog = $CLJS.goog inside of cljs_env.js ? I think before it was inside each script when reloaded, but now it’s the minimal amount of JS update the namespace

window.goog = $CLJS.goog is not enough, don't get hung up on that

i meant all of the possible one’s inside the script? or are they different per script?

its just the first you run into, so it doesn't get to the other errors later on

ok, long story: once upon a time I decided to try to make :npm-module be a good citizen and NOT expose any globals whatsoever. how then do you make sure the REPL and hot-reload and CLJS in general still work, since everything in that world assumes to live in the same global scope. so in my younger days I decided to be clever and recreate and fake that "global" scope in every single namespace

thats what all the var goog = $CLJS.goog stuff is

it turns out this was a terrible idea, and not actually useful and gets in the way more than I'd like

hmm okay, so we want to avoid that fake global stuff and just define all the global on window?

so instead, everything should live in global during development. and only be local in release builds

but that also doesn't play with certain tools, such as parcel which seems to have a weird notion about what global means

in :esm it just uses globalThis which is sort of standard and I guess respected by vite

so, everything just works as expected

so the choice I have to make in :npm-module is a) remove all the fake-global stuff or b) keep the hacks and "fix" the hot-reload problem browsers now have

I'm leaning towards a since it removes so many headaches

but it is basically rewrite everything :npm-module related type of thing, and given how many hacks that has I'm not sure it will not break in unexpected ways in other peoples builds actively using it

I'm trying to avoid breaking changes at all costs, but :npm-module is giving me nightmares at this point. so I guess I might need to do this at some point

Well if we had a global object will all of the definitions you’d want on global, you could pass that into the script eval as the context?

the eval already happens in the global scope, that is precisely the problem after all. it doesn't see the fake global properly, so there are two worlds. one that is fully initialized on startup, one that is partially broken on hot-reload

yup yup, and I’m thinking that when we know something is “reloading”, we can reference the fake global inside script evals arguments

:npm-module also had a bunch of node specific things baked in, which always get in the way when not actually building for node

let me double check if that’s supported

you can't fake a global in eval, can't control how the browser resolves stuff after all

:npm-module has been by far the most problematic targets of any of them. thats why I hate touching it so much, fix one thing always breaks another 😛

you’re right, i was imagining the node version of some eval stuff

and all only for trying to avoid the global scope 😛

the cleanup should make things much nicer, just need to find and revert all the hacks first

Okay so what’s our best guess as to why the global stuff is incorrect, because Parcel overrides the global?

no because of the commit I linked

before that change the server used to wrap the output it generated for hot-reload

so it would append the whole var goog = $CLJS.goog; stuff

Yup exactly, though I thought you were saying that window.goog should already be the same as $CLJS.goog?

but I only changed how reloading works in the new shadow.cljs.devtools.client.npm-module (intended for node), and not the shared browser ns

yes, because when the code was initially loaded everything was properly on the $CLJS global object

but hot-reload wasn't. thus stuff starts to break

I see what you mean, during load stuff uses $CLJS right?

but reload it uses global

yes, during normal loading it avoids global completely except for one actual global $CLJS which is used to bridge stuff

but after that shadow.cljs.devtools.client.browser just assumes everything is global, because in all other targets it is used in it is

just :npm-module is a special case

ahhh so this extra tricky because you’re trying to remove this fake global stuff, but some code still uses it, and new code depends on it not being there at all.

Is it possible to have a separate shadow.cljs.devtools.client.npm-module-legacy file that adds back scoping stuff?

I would lean towards what you recommended earlier about removing all the fake global stuff and maybe just using globalThis, but that would seem to break anyone using the npm-module stuff right?

At least if they depend on global stuff never being touched

can't reliably use globalThis since it might not be supported in all environments but can probably test for it and fallback for global if it doesn't exist

Does using globalThis in the browser for an npm-module target work?

ah, to avoid the XYZ problem: what I'm really trying to do is create a subclass of Object like this

class Foo {
  constructor(guts) {
    this.guts = guts;
  }
  raw() {
    return this.guts;
  }
}

either should work? deftype and defclass

your code looks fine?

hmm. I just got it to work with a basic deftype; I suppose that solves my problem. but I couldn't get the defclass to work.

and your example code works for me?

> (require '[shadow.cljs.modern :refer (defclass)])
nil
cljs.user=> (defclass Foo
  (constructor [_this])
  Object
  (bar [_this] 17))
#object[Function]
cljs.user=> (let [foo (Foo.)]
  (.bar foo))
17
cljs.user=>

in the browser repl works just fine

weird. I'm running a node REPL via Conjure, but that shouldn't break this?

nope, should be fine. maybe you have some old Foo reference somewhere?

that's probable, I suspect I broke my REPL state with an early attempt.

hmm

it does indeed fail in node

not sure why though, let me check

(it seemed like there was no prototype at all. (.-prototype Foo) ;=> {})

no rush; I'm unblocked by using deftype for this simple case.

hmm yeah I don't get it. generated code looks fine

huh, that's a strange gap. Node is V8 (right?) so I don't see where the gap would be. something about exporting, maybe?

did you only try this in the REPL? it works fine via load-file

Yeah, only the REPL.

Hi @thheller, Here is my code testkit.cljs where wrapped with fulcro

(ns fulcro-atlaskit.testkit
  (:require
   ["@testkit/react" :refer [Box GlobalHeader]]
   [com.fulcrologic.fulcro.algorithms.react-interop :as react-interop]))

(def ui-box (react-interop/react-factory Box))
(def ui-global-header (react-interop/react-factory GlobalHeader))

(ns xxxxx-xxxxxx.ui.pages.xxx-xxxx
  (:require
   ..
   [fulcro-atlaskit.testkit :as testkit]))

(defsc Root [this _]
  (dom/div
    :.container
    (dom/h1 (tr " Get started"))
    (testkit/ui-box)))

looks fine to me