as the name should imply the :node-library is targetting a node runtime, therefore it will not work in the browser without additional processing

how do you intend browsers to consume this? I mean how would they access the exports? regular JS doesn't have anything like that

you can use https://shadow-cljs.github.io/docs/UsersGuide.html#target-esm

that'll work fine in node and the browser using <script type=module ...>

Actually, the library is intended to be consumed by a Purescript app. I don’t know much about it, except that it is using esbuild at some in it’s build process. I think Purescript, with imports, so perhaps that would work.

Wondering… the problem seems to only be the reference to the global object. I believe globalThis is the environment compatible reference. Is there a way to fix that?

use :target :esm with :js-provider :import probably https://shadow-cljs.github.io/docs/UsersGuide.html#_third_party_tool_integration

but I believe you don't have any actual JS dependencies in your build, so the :import part doesn't matter

:esm is the better choice, as :node-library has very many assumptions about actually running in node

:npm-module would also work

Ok, I’ll try those. What’s the best way to configure the build so that I can export the api from a single file? Like this: https://github.com/diegovdc/erv/blob/main/src/js/export_fn.cljs#L9-L14 So that accessing the functions could be done like: erv.cps.make(...)

ESM is too strict to make it that dynamic, so would need to be done in the build config

I'd recommend to just create a defn that handles the translation between JS/CLJS

Ok

Thanks

hard to say. could just be a version conflict.

if you want to setup a repro I can take a look

Thanks Thomas, I'll try to do that then.

I created a small repo that exhibits the same problem on my machine: https://github.com/svdo/shadowtabulator. Thanks for offering to look into it!

ok yeah, this is due the tabulator-tables shipping two different dist versions. one for ESM. one for CommonJS, with an incompatible API (i.e. different export style)

so react-tabulator imports it the "wrong" way and breaks

You gotta love it 🙂

you can "fix" this by setting :js-options {:entry-keys ["module" "browser" "main"]} in the build config

but be aware that this may break other packages

commonjs/esm interop is still an absolute mess and not getting better

works in the repro but doesn't mean it will in bigger projects with more dependencies

I'm not sure if it was that specific order that I tried yesterday, but that broke tons of things. But I'll try again 🙂

you can try https://shadow-cljs.github.io/docs/UsersGuide.html#js-provider-external and see if that works. webpack uses module entries by default

if it doesn't work also try adding :export-conditions ["import" "module" "browser" "require" "default"]

At the very least 'emotion' breaks with that js-options setting

unfortunately the JS world keeps adding to this mess instead of fixing it 😛

:export-conditions also goes in :js-options

I can just put that in the dev section for trying it right?

:dev        {:js-options {:entry-keys ["module" "browser" "main"]
                             :export-conditions ["import" "module" "browser" "require" "default"]}
                :compiler-options {:output-feature-set :es8
                                   :infer-externs      :auto
                                   :external-config {:guardrails {}}
                                   :warnings {:fn-deprecated false}
                                   :closure-defines {goog.DEBUG true}}}

then your release builds will just break, so not recommended in :dev

Yeah right but just to see if it works, which it doesn't apparently.

Switching to a js bundler feels like a step back. What's the state of the are there, what is the current simple+popular choice? Last time I used something like that it was rollup iirc?

no clue, I never used it myself. I tend to not use many npm packages myself, so never run into those that don't work 😛

That's also a solution 😉

Anyway, thanks for clarifying and looking into it!!!

good to know it works

what works? Not using it? 😛

oh oops

well I'd try webpack, thats most widely used and fixes most quirks

but there are things even webpack can't fix. let me know the result if you try

I'm getting cold sweat from the memories of fighting webpack. I'll skip that for now and use Tabulator directly without react-tabulator.

:service-worker true is not a valid option, you want :web-worker true

otherwise looks fine

but I believe service workers still have the restriction of needing to be in the root folder

so your :output-dir likely needs to be resources/public and :asset-path "/" accordingly

I think I'm passing the correct header when serving Service-Worker-Allowed: / And I am getting the correct file when I try to register, but it fails to execute the actual output script.

Uncaught Error: browser bootstrap used in incorrect target
  at service-worker.js:1253:11
    at service-worker.js:1394:3

thats because of not using :web-worker true

you can also use :target :esm btw I believe

mmh I thought I changed that, I need to sort my caching I guess. One more thing I now noticed is that in the docs it's as module instead of at top-level within :builds I'll hack some more, thanks @U05224H0W

@U47V0EZF1 if you figure out how to get a repl going with a service worker lemme know

@U3BALC2HH I did get a service worker start but I'm fighting with the repl, I could share my messed up shadowcljs file if you want. The problem I have now is that if the service worker is running calva puts the repl inside the service worker rather than the core, I'm not sure how to deal with that yet

To be honest I don't know how much of a shadowcljs or calva problem this is

happy to hack in pair on an empty shadowcljs project just to produce a working template as I'm finding very little online

whats the problem?

I'm struggling to have a setup that works with re-frame-10x hotreload and a working repl in calva when serviceworkers are installed. In particular if I run (js/console.log js/self) from the repl I get different results depending on whether the serviceworker is installed and running at page load (ServiceWorkerGlobalScope) or not (Window). This seems not related to which file I'm on, ie: looks like the same repl. I've uploaded my edn file https://pastebin.com/hbsEMMqQ if that makes it any easier

that indeed seems to be full of stuff that doesn't do anything 😛

I'll get back to you, busy currently

{:deps {:aliases [:cljs]}
 :builds
 {:app
  {:target :browser
   :output-dir "resources/public/assets/js"
   :asset-path "/assets/js"
   :modules
   {:shared
    {:entries []}
    :service-worker
    {:depends-on #{:shared}
     :entries [com.mydomain.serviceworker.core]
     :web-worker true}
    :main
    {:init-fn com.mydomain.core/init
     :depends-on #{:shared}
     :preloads [day8.re-frame-10x.preload]}}


   :tailwind/output "resources/public/assets/css/site.css"
   :tailwind/config {:dark-mode "media"
                     :content ["src/cljs/**/*.cljs"]}

   :devtools
   {:reload-strategy :full
    :devtools-url ""}

   :build-options {:manifest-name "../../../manifest.edn"}
   :dev {:build-hooks [(teknql.tailwind/start-watch!)]
         :compiler-options
         {:closure-defines {re-frame.trace.trace-enabled? true
                            day8.re-frame.tracing.trace-enabled? true}
          :elide-asserts false}}

   :release {:build-options {:ns-aliases {day8.re-frame.tracing day8.re-frame.tracing-stubs}}
             :build-hooks [(teknql.tailwind/compile-release!)]}}}
 
 :dev-http {5003 "resources/public"}}

ok this is with all the stuff removed that didn't do anything in the first place

the way this works is that the REPL connects for each new runtime

the browser itself is a runtime, and the service worker is another one. so 2 runtimes per build, and I'm not sure how you'd select which one you want to talk to in calva

what might be easier to settle this is just using two builds separately

so something like

{:deps {:aliases [:cljs]}
 :builds
 {:app
  {:target :browser
   :output-dir "resources/public/assets/js"
   :asset-path "/assets/js"
   :modules
   {:main
    {:init-fn com.mydomain.core/init
     :preloads [day8.re-frame-10x.preload]}}

   :tailwind/output "resources/public/assets/css/site.css"
   :tailwind/config {:dark-mode "media"
                     :content ["src/cljs/**/*.cljs"]}

   :devtools
   {:reload-strategy :full
    :devtools-url ""}

   :build-options {:manifest-name "../../../manifest.edn"}
   :dev {:build-hooks [(teknql.tailwind/start-watch!)]
         :compiler-options
         {:closure-defines {re-frame.trace.trace-enabled? true
                            day8.re-frame.tracing.trace-enabled? true}
          :elide-asserts false}}

   :release {:build-options {:ns-aliases {day8.re-frame.tracing day8.re-frame.tracing-stubs}}
             :build-hooks [(teknql.tailwind/compile-release!)]}}
  
  :sw
  {:target :browser
   :output-dir "resources/public/assets/sw-js"
   :asset-path "/assets/sw-js"
   :modules
   {:service-worker
    {:entries [com.mydomain.serviceworker.core]
     :web-worker true}}}}

 :dev-http {5003 "resources/public"}}

since the service worker doesn't support reframe 10x or tailwind anyways that config becomes much simpler

you can then run shadow-cljs watch app sw to run both builds

and have calva connect to the app build as usual

please do make sure that both build use a separate :output-dir though, using the same for both builds will get you in trouble.

That makes sense, I had them separate and couldn't make it work before. I'll try again now, thanks a ton!

By the way, if I could sculpt I'd build you a statue. Is the best way to support you through github or what?

hehe, all the links listed there work yes https://github.com/thheller/shadow-cljs

Magical, thanks a ton @U05224H0W! @U3BALC2HH FYI the last config shared by Thomas works flawlessly. In order to get a REPL on the :sw I needed an extra

:devtools { :devtools-url "" }

(comment (js/console.log "Self is " js/self))

holy f*ck 😮

thank you @U47V0EZF1 @U05224H0W, didn't think it was possible

it is possible with just one build too, calva just doesn't support it. and neither does any other editor to be fair, since its shadow-cljs only feature thats not well documented. 😛

but in case of service workers I'd recommend a secondary build anyways since its unlikely to share much code with your regular build

well ... it can make sense to combine. service workers with caching create sort of a chicken/egg type problem where updating them gets tricky 😛

what do.you mean by invoke a build? you just build them like normal

I typically use cider-jack-in-cljs > shadow, then it prompts me for a build

so do I use it twice, once with each build?

cant say anything about the cider side. no clue how you'd tell it to start both builds

ok, so "like normal" means on the command line

you could run npx shadow-cljs watch app sw to start both and then cider connect or whatever thats called

yep perfect, that works

or you start the first with cider and start the second over the repl or the ui

that would probably work better

❤️ @U05224H0W you da man. Might have to bump up your corporate sponsorship for this one!! @U47V0EZF1 thanks for making this happen!

I'm honestly stunned that that even works

beware of service workers though, since they can intercept network requests and reply with cached values. caching is usually not something you want in development, so don't go too crazy with it. 😛

it's a rich client application and caching is a critical part of it... so better to have a repl than not!

I had that part entirely in typescript so I could use the webstorm debugger, but the webstorm debugger for service workers really isn't that great

shadow-cljs does not support using cljsjs packages, instead you use the npm packages directly

Thank you