Hi Thomas, in the context of Malli function instrumentation. I'm wondering if there is a way to tell the compiler, not only to always recompile a namespace (with {:dev/always true}), but also to instruct the compiler to do so after all other namespaces - without needing a solution like you mentioned here https://clojureverse.org/t/problem-using-malli-clojurescript-instrumentation-and-shadow-cljs/8612/2 of explicitly including every namespace that you want to compile before the entry one (or preload). The dream setup would be adding one piece of metadata to the entry namespace (for a webapp) and then getting repl friendly instrumentation. Not sure if this is possible, so wanted your opinion on the matter. Thanks.

define "repl friendly instrumentation"? the hot-reload cycle is entirely independent of the REPL so that confuses me?

Ah you're right - it's really just hot-reload - making sure the changes in leaf namespaces (changing the malli schema used by a function) is picked up in the entry namespace. Here's the setup for instrumenting with fn metadata: 1. in your entry namespace in your after-load callback the user invokes a macro () this scans all namespaces and collects any functions that have :malli/schema metadata 2. In your leaf namespace like my.app.utils you have a function like:

(defn minus-small-int
  {:malli/schema [:=> [:cat :int] small-int]
   :malli/scope  #{:input :output}}
  [x] (dec x))

what you can do if abuse the after-load hook a little bit

(defn ^:dev/after-load malli-instrument []
  (js/cljs-eval "(malli.dev/start!)"))

that basically just evals () after every hot-reload

no clue how that behaves if it gets called after every compile though

might not like getting started several times

or might just do a lot of work that is unnecessary and as such slow everything else down

oh very cool! Well at least it pushes the problem from a staleness one to a perf one. Is there a way in a macro to determine which namespaces have changed (provided by some compiler data?) that way I don't have to scan every ns

in a macro not really no

I mean strictly speaking yes but that would be shadow-cljs only and even then not guaranteed to be reliable

has to account for cache and stuff

got it - would it be really bad to use the ns to lookup its file modified time ? that way I could store some state to keep track which ns's changed

or maybe hash the namespace object?

sure thats one option

ok great! thanks so much for the help

I've gotten curious about the current best way to do documentation generation. Many of the previous ways to do this (Marginalia, Codox, Dynadoc) seem to mostly be via lein plugins (or deps.edn). What's the best way to generate docs with Shadow? (Or is everyone just using cljdoc?)

anything that works with deps.edn should also work with shadow

or just use lein with the plugins. they are all seperate tools that don't require shadow-cljs in any way to work

Hi all, I'm new here. I've got a question about problems compiling with shadow-cljs for a project using Fabric.js. We're currently trying to upgrade a bunch of packages; we are building ok pre-upgrade. As I understand it, fabric is using jsdom. On lein shadow compile app we're seeing a whole bunch of errors like:

[:app] Compiling ...
Closure compilation failed with 20 errors
--- node_modules/jsdom/lib/jsdom/living/generated/AbortSignal.js:95
constructor is missing a call to super()
--- node_modules/jsdom/lib/jsdom/living/generated/Attr.js:96
constructor is missing a call to super()
--- node_modules/jsdom/lib/jsdom/living/generated/CDATASection.js:94
constructor is missing a call to super() 

@emile what are you building? looks like it might be a browser build? jsdom is intended for node envs? what is your build :target?

jsdom shouldn't be included for browser builds?

@thheller yes, :target is :browser. We have a clojurescript reframe component that uses Fabric.js and canvas element to let you draw various regions on top of an image, then turn what you've drawn into svg. Fabric is apparently using jsdom. Are you saying this should never have worked? 🙂

no, I'm saying jsdom shouldn't be included

it appears to be an optional dependency. so something you have done must lead to its inclusion. not sure what

what shadow-cljs version do you use?

anything special in your build config?

do you directly require jsdom somewhere?

You'll have to forgive me, my grasp of dealing with dependency stuff is not strong. We are trying to upgrade a bunch of stuff, including shadow-cljs to 2.19.0 from 2.11.18. I'm trying to figure out what's pulling in jsdom now...

maybe that update is enough

hmm I can reproduce this. let me look

@thheller re: jsdom as optional dependency of fabric... our team is confused 🙂 We can't find anything explicit in our dependencies for jsdom. When we remove package-lock.json , run npm install --no-optional and then lein shadow compile app we see:

[:app] Compiling ...
The required JS dependency "jsdom" is not available, it was required by "node_modules/fabric/dist/fabric.js".

Dependency Trace:
	mobot_web/app.cljs
	mobot_web/core.cljs
	mobot_web/admin/views/core.cljs
	mobot_web/admin/views/test_plan_runner.cljs
	mobot_web/admin/views/components/assessment_region_editor.cljs
	node_modules/fabric/dist/fabric.js

Searched for npm packages in:
	/home/emile/dev/mobot-doc-change/mobot-web/node_modules

See: 

the problem is in fabric, not your code

it is trying to include jsdom conditionally in a way that shadow-cljs does not recognize properly. so it ends up trying to include it fully

I'm checking why

Ah, thanks!

you can set this is :js-options in your build config

:resolve {"jsdom" false
              "jsdom/lib/jsdom/living/generated/utils" false
              "jsdom/lib/jsdom/utils" false}

that'll fix it for now

Much appreciated!

We lightly use shadow-cljs at work but this interaction here is an example of exactly why I keep my sponsorship of @thheller on github. Incredible