looks like you are missing externs? do you not get warnings about that?

i do have both libs and main in the folder

and index.html imports both of them and it works using compile and not release

yes, release applies optimizations that minify yyour code

compile does not do that

these optimizations sometimes require "externs", to prevent renaming/shortening of certain stuff

normally the places that cause problems should cause compiler warnings

so that is why I'm asking whether you get compilation warnings when making the build

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

no i dont have warnings and i have set a few externs before when i had warnings

I have set the externs only when I had warnings, is there any other place required, like a global place?

you can set shadow-cljs release :dev --pseudo-names to make it a little more apparent where the error is

no, I'm not currently aware of cases where externs are required but no warnings are generated

except I guess when you are actively writing bad code to circumvent the externs handling

pseudo names should help you figure out where the problem is

if you paste that here I can maybe provide more info

yea thanks, it points me to google map auto complete

var $locations$locations_service$$ = new google.$maps$.$places$.$AutocompleteService$();

and what is the CLJS code producing this?

cljs file:
(def locations-service (new google.maps.places.AutocompleteService))

index.html
    <script
      src=""
      type="text/javascript"
    ></script>

that produces no warning? that is definitely invalid

I have added js extern now

(def ^js locations-service (new google.maps.places.AutocompleteService))

that is incorrect

try (def locations-service (js/google.maps.places.AutocompleteService.))

can you explain please the differences?

well google.maps.places.AutocompleteService on its own is an invalid symbol

since you are accessing the global google variable that should be js/google.maps.places.AutocompleteService

(new js/google.maps.places.AutocompleteService) is also fine

(new js/google.maps.places.AutocompleteService) would have worked as well?

great thanks, I see now

it did work by the way! thanks

(def ^js locations-service hints the locations-service as a JS object, but not the call that produces it

how do you not get warnings for this?

ha this indeed does not produce a warning

shadow didnt give me a warning, but vs code (clj-kondo) did

but only when i have opened the file

weird, let me check that

👍

regardless, accessing global variables is done with the js/ prefix

hehe because of the closure compiler having some default google externs shadow-cljs doesn't complain about anything starting with google. 😛

ohh wow.. that's an edge case

there's another weird behavior I experienced a few days back. Locally the release works, but building it via CI it breaks with:

Uncaught ReferenceError: shadow$bridge is not defined
    at main.js:684:61
    at main.js:3075:4

shadow$bridge is the variable defined by the external output, so I guess thats not loaded correctly?

It's the same code and executes. Only difference is running on my machine vs a container

I don't know your CI setup, so how does that execute? I mean is it a full browser driven remotely or what does that do?

just because there is the same files on disk, does not mean they are loaded the same way 😛

depends, shadow-cljs only does the CLJS

if you want a CLJ webserver or anything server side that is CLJ you likely want leiningen or deps.edn

otherwise shadow-cljs covers everything CLJS and does not need leiningen

That's great to hear 🙂

FWIW at work we use shadow-cljs "by itself", no leiningen or deps.edn For a simple reason: the shadow-cljs release from npm provides everything we need out of the box. The built-in web server with live reloading CSS is pretty useful (in addition to shadow's cljs reloading)

it is the goog.provide in

...

      E.parser = qa // this seems to come from CodeMirror
    };
    'use strict';
    goog.provide('goog.events.EventWrapper');
    goog.provide('goog.events.EventLike');
    goog.provide('goog.debug.ErrorHandler'); /*

 Copyright The Closure Library Authors.
 SPDX-License-Identifier: Apache-2.0
*/
    var CLOSURE_NO_DEPS = true;
    var CLOSURE_BASE_PATH = 'js/cljs-runtime/';
    var CLOSURE_DEFINES = {
      'goog.DEBUG': false,
...

version 2.25.7 is out, don't know if that helps

Sadly no, it doesn’t help.

and older versions of shadow-cljs? ;)

Shadow 2.20.0 has the same problem

why whitespace? that is pretty much an unsupported optimization option

whitespace literally means leave everything as is, remove whitespace

so the code looks like dev code

I am trying to troubleshoot https://clojurians.slack.com/archives/C015LCR9MHD/p1695985193245379 - with :simple it does now work, but with :none it does. By “it” I mean the following shadow init fn:

(defn init []
  (println "Init run")
  (sci/eval-string* full-ctx "
    (do
      (ns test (:require 
        [com.fulcrologic.fulcro.dom :as dom]
        [com.fulcrologic.fulcro.application :as app]
        [com.fulcrologic.fulcro.components :as comp :refer [defsc]]))
      (defonce app2 (do (println \"Def app!\") (app/fulcro-app)))
      (comp/defsc Root [_ _] (dom/div (dom/h3 \"One\")))
      (app/mount! app2 Root \"app\"))
    ")
  
  (sci/eval-string* full-ctx "
    (do
      (ns test (:require 
        [com.fulcrologic.fulcro.dom :as dom]
        [com.fulcrologic.fulcro.application :as app]
        [com.fulcrologic.fulcro.components :as comp :refer [defsc]]))
      (defonce app2 (do (println \"Def app!\") (app/fulcro-app)))
      (comp/defsc Root [_ _] (dom/div (dom/h3 \"TWO\")))
      (app/mount! app2 Root \"app\"))
    ")
  )

(I already suggested release with --debug)

(I also suggested getting rid of asset-path)

Not sure if we should bug thheller with this @U0522TWDA

It doesn't seem to be a shadow problem to me

what is the build config used?

currently

:builds   {:dev     {:compiler-options {:output-feature-set :es8
                                         :optimizations :simple
                                         :source-map true}
                      :target     :browser
                      :output-dir "www/js/dev"
                      ;:asset-path "/js/dev"
                      :modules    {:dev {:init-fn development/init}}
                      :devtools   {:after-load development/reload}}}

try adding :output-wrapper false to the compiler options

I did, doesn’t seem to have any effect. Michiel suggested that in my SCI macro I must be emitting something which is prone to renaming. But simple only renames local vars and fn params, right? I wanted to try whitespace to be sure whether it is renaming or st. else causing the problem…

yes, simple only renames locals. whitespace keeps all the other dev stuff, so it is not recommended or by my account supported

don't know what you are doing with SCI, so can't comment much

the goog is undefined stuff usually means that something was eval'd in the wrong scope

Then I will look at the variables and params in the functions to see which one could it be…

you also should keep :asset-path, don't know why @U04V15CAJ recommended to remove it?

it is a must have setting when it isnt /js

because I got rid of the goog is undefined warning when I removed it

it is /js

but there is a js/dev folder? so I'm assuming the JS is accessed via /js/dev/dev.js

so I figured it was one less mis-configuration to worry about (in addition to the simple stuff which I know isn't support in shadow)

I just got rid of that dev indirection

This is my config which works:

{:deps     {:aliases [:test :dev]}
 :nrepl    {:port 9000}
 :dev-http {8081 "www"}
 :builds   {:dev     {#_#_:compiler-options {:output-feature-set :es8
                                         :optimizations :none #_whitespace}
                      :target     :browser
                      :output-dir "www/js"
                      #_#_:asset-path "/js/dev"
                      :modules    {:dev {:init-fn development/init}}
                      :devtools   {:after-load development/reload}}}}

<script src="js/dev.js" type="text/javascript"></script>

yes, this is using /js as the output folder, then the :asset-path "/js" default is correct. in the above config it was not. :asset-path "/js/dev" in your config would have been incorrect

:asset-path is basically "path to the folder where the .js files are"

I just wanted to go with the defaults, not to conflate the issue any further. can add those asset path stuff back in later

needed in development for things like source maps in some circumstances

FYI Michiel figured out that if we modify the script by renaming Root to Root2 in the second eval call, then it will work and correctly show the second app. So it looks like we can define & mount new classes, but not change existing ones, somehow, when optimizations are on. I need to dig into it…

what is the point of rendering something and then immediately rendering over it?

as I already told, this is likely not a shadow issue ;)

Well, the whole adventure started with https://blog.jakubholy.net/2023/interactive-code-snipets-fulcro/#_demo - the point is having a code editor in a web page, and being able to change the code, reeval, and see the output change. The last part - seeing the effect - is broken with optimizations right now.

localhost...

hehe yeah, no clue what that is 😛

sorry, fixed link

"snipets" you might want to correct that to "snippets" (very minor thing ;))

ERROR: Could not resolve symbol: js/console.log does sci not know this?

yes, it has to be configured for it, which Jakub hasn't done yet

Let me release a new version, which exposes it

my guess is somehow that Root is not overwritten

if I name it to Root2 and change the mount arg accordingly it renders the "new" code fine

yeah, that's what I also figured :-) https://clojurians.slack.com/archives/C015LCR9MHD/p1695992591883249?thread_ts=1695985193.245379&cid=C015LCR9MHD

ah 😛

could be the defsc macro? 😛

likely

The problem is that for the editor to be really useful, I need to be able to change existing code/components 😭

The defsc macro is something I had to rewrite into a SCI fn so most likely I do st. wrong there…

perhaps a defonce or so somewhere

serems to be the defsc macro, if I use defn it works fine

(defonce ~(vary-meta sym assoc :doc doc :jsdoc ["@constructor"])
                    (comp/react-constructor (get options# :initLocalState)))

Thank you both ♾️ times! I will dig into the macro-fn thingy…

FYI https://blog.jakubholy.net/2023/interactive-code-snippets-fulcro/ now supports js/

when I change the defonce in the defsc macro to def it starts to work

not sure why it did "work" under non-advanced compilation though

🙏🙏🙏

that would still be interesting to find out imo

shadow does this https://github.com/thheller/shadow-cljs/blob/cf5e87d48f4ca381e9c0521616f3b87da78de9db/src/main/shadow/build/cljs_hacks.cljc#L704-L712

but that should have meant that :release works and watch/compile doesn't?

ah nvm .. its not shadow-cljs doing the compilation so this has no effect whatsoever 😛

yeahs, it's defonce in SCI ;)

Thank you both so much, for spending your valuable time to help me out! I couldn’t do this on my own. Thank you, and have a great weekend!

Jakub:, when I add back the defonce:

(defonce ~(vary-meta sym assoc :doc doc :jsdoc ["@constructor"])
             (do
               (prn :redefine)
               (comp/react-constructor (get options# :initLocalState))))

Thank you! Yes, let’s do that. I have to leave now to arrange stuff, but will get back to it in the evening.

using --debug output and rendering the same code through the normal CLJS compiler, I get:

var $options__47309__auto___58136$$ = new $cljs$core$PersistentArrayMap$$(null, 1, [$cljs$cst$2826$render$$, function($_$jscomp$693$$) {
  return $com$fulcrologic$fulcro$components$wrapped_render$$($_$jscomp$693$$, function() {
    $com$fulcrologic$fulcro$raw$components$props$$.$cljs$core$IFn$_invoke$arity$1$ ? $com$fulcrologic$fulcro$raw$components$props$$.$cljs$core$IFn$_invoke$arity$1$($_$jscomp$693$$) : $com$fulcrologic$fulcro$raw$components$props$$.call(null, $_$jscomp$693$$);
    return $com$fulcrologic$fulcro$dom$macro_create_element$$.$cljs$core$IFn$_invoke$arity$3$("div", new $cljs$core$PersistentVector$$(null, 1, 5, $cljs$core$PersistentVector$EMPTY_NODE$$, [$com$fulcrologic$fulcro$dom$macro_create_element_STAR_$$(["h3", {}, "One"])], null), null);
  });
}], null), $development$Root$$ = $com$fulcrologic$fulcro$components$react_constructor$$($cljs$core$get$$.$cljs$core$IFn$_invoke$arity$2$($options__47309__auto___58136$$, $cljs$cst$2816$initLocalState$$));
$com$fulcrologic$fulcro$components$configure_component_BANG_$$($development$Root$$, $cljs$cst$5218$development_SLASH_Root$$, $options__47309__auto___58136$$);
$cljs$core$prn$$.$cljs$core$IFn$_invoke$arity$variadic$($cljs$core$prim_seq$cljs$0core$0IFn$0_invoke$0arity$02$$([$development$Root$$]));
$com$fulcrologic$fulcro$application$mount_BANG_$$.$cljs$core$IFn$_invoke$arity$3$($development$app2$$, $development$Root$$, "app");
var $options__47309__auto___58137$$ = new $cljs$core$PersistentArrayMap$$(null, 1, [$cljs$cst$2826$render$$, function($_$jscomp$694$$) {
  return $com$fulcrologic$fulcro$components$wrapped_render$$($_$jscomp$694$$, function() {
    $com$fulcrologic$fulcro$raw$components$props$$.$cljs$core$IFn$_invoke$arity$1$ ? $com$fulcrologic$fulcro$raw$components$props$$.$cljs$core$IFn$_invoke$arity$1$($_$jscomp$694$$) : $com$fulcrologic$fulcro$raw$components$props$$.call(null, $_$jscomp$694$$);
    return $com$fulcrologic$fulcro$dom$macro_create_element$$.$cljs$core$IFn$_invoke$arity$3$("div", new $cljs$core$PersistentVector$$(null, 1, 5, $cljs$core$PersistentVector$EMPTY_NODE$$, [$com$fulcrologic$fulcro$dom$macro_create_element_STAR_$$(["h3", {}, "TWO"])], null), null);
  });
}], null);
$development$Root$$ = $com$fulcrologic$fulcro$components$react_constructor$$($cljs$core$get$$.$cljs$core$IFn$_invoke$arity$2$($options__47309__auto___58137$$, $cljs$cst$2816$initLocalState$$));

which is probably due to CLJS hacks in shadow:

release builds will never overwrite a defonce, skip DCE-unfriendly verbose code

still a mystery why there is a difference between dev and release with SCI but I'm willing to let this detail slide now

although I don't get the comment in shadow: isn't it the case that a defonce is always redefined, instead of "never overwrite"?

there is never a cause where a defonce is executed twice basically

defonce exists because of the repl/hot-reload

release builds don't do either, so you don't need defonce

ah right :)

unless you re-define a var twice like:

(def x 1)
(defonce x 2)

which is what happens in the above example

but typically you don't do this

that should give a warning yes

from both CLJS and clj-kondo if somebody's using that as well ;)

I shall henceforth address you as Mr. Holmes :sleuth_or_spy: :-)

so I have this dev compiler, ClojureScriptStorm, which is a fork of the cljs compiler that adds automatic instrumentation when it compiles anything. You can change what ns get instrumented by changing a clj var. So lets say I want to change what gets instrumented, I can change that var, but then I need to recompile everything, to bring the new instrumented/uninstrumented code the browser

does it make sense?

maybe you want to turn of caching entirely for that case? https://shadow-cljs.github.io/docs/UsersGuide.html#_compiler_cache

so shadow-cljs is still doing the compilation, just not using actual cljs.analyzer anymore? is that right?

interesting, I guess I can try cache-level :jar, which will always recompile my app but no other lib?

like some middle ground

or maybe leave normal cache an run a shell command that touches every cljs file? so it will force a full recompilation?

there is also https://github.com/thheller/shadow-cljs/blob/45587a80bf55bb971ed009168a80af58a0fd02ac/src/main/shadow/build/compiler.clj#L739-L766

those are all the options that cause the cache to be invalidated and recompiled

I guess you could use [:compiler-options :tooling-config] or :external-config? or however is all is controlled?

sorry, not sure I follow, you mean changing one of those in my shadow-cljs.edn will fire a full recompilation?

yes

well, need to restart the watch

I guess I'm not really sure how this all works from your end

so, what I'm looking for is a way of recompiling all without restarting the watch. The compiler will emit different output depending on the contents of a global var (clj land). So I can go and change that var from the clj repl, but then I would like to re-compile all my app so I get the newly compiled code. Since this is a dev tool I would like to do all this interactively, as part of your dev flow, that is why I don't want to restart anything

recompile everything is a bit tricky, as reloading cljs.core for example is not safe

also reloading any of the shadow.cljs.devtools things will cause a reconnect, which may confuse the REPL

so you likely want to limit that to project files

yeah, got it, I was looking for recompiling my app stuff only

I can give you shadow-cljs specifc way of doing this, that basically abuses the hot-reload mechanism?

I think this made the trick find src -name "*cljs" -exec touch {} +

the main issue is that shadow-cljs is not aware of your CLJ var doing stuff to the compilation

so it just ignores it when it comes to cache

but that find command did exactly what I need

so hacky as it gets but is an easy way of forcing only your app recompilation with one command

yes, I'm just warning you about caching issues

what do you think could go wrong with touching all my cljs files and make shadow recompile them?

the compiler is not aware of what is in your tool settings

so say you compile once

restart shadow-cljs and it'll think the cache is good

but your app settings are gone

so maybe things are broken

I mean, this compiler is aware, because is a fork of the ClojureScript compiler, which looks at those vars when emitting code

I mean shadow-cljs when I say compiler

but shadow-cljs is just calling the current cljs compiler

in this case ClojureScriptStorm

that is not at all what I mean

oh sorry

shadow-cljs when starting a build decides whether it can use the cache for a file or whether it needs to recompile

it has no concept of what your tool is

so it will likely skip compilation entirely and use the cache

but the cached code still had all your old tool settings

so now things may blow up since those settings don't really exist anymore

but again ... I don't know what you are doing .. so this is just a general warning about cache. there be dragons.

so, the only thing I'm doing is that I'm swapping the official Cljs compiler, by a fork that just emits some extra code when emitting js, that is it, think of like adding js/console.logs everywhere, no other magic. I understand that shadow-cljs will cache the compiled output, but if I have a simple way of touching every cljs file under my project, I can fire that whenever I want to be sure that everything is being recompiled

make sense?

again .. just a warning. its always weird to have "only works after I do this" behavior

should be fine but you are messing with shadow-cljs in ways it doesn't like to be messed with 😛

but you mean by running a touch on all cljs files?

I don't think it isn't messing with it in any other way

you are changing the cljs.analyzer and compiler under the hood, so I'd say that qualifies as messing with it 😉

but if you are careful everything should be fine. I'll just direct users your way if they run into problems 😉

well, yeah, BUT since shadow-cljs support is my main concern, all I'm touching is always after I'm sure it works with shadow-cljs

so, you can think of it as a shadow-cljs plugin thing at the compiler level

I'm aware of the shadow hacks ns, and stuff like that, so I'm designing the compiler with that in mind, and works great so far

> I'll just direct users your way if they run into problems 😉 hahah yeah, of course, I mean, is a thing with this dev compilers, same thing with ClojureStorm, I don't want people to go complaining with the Clojure team for a dev compiler error, but since swapping compilers is a keyword away, is very easy to know if an error is coming from the dev compiler or the original one

anyway, thanks for your time!