Clojurians Log v2

when you require it from the ns :require it will become part of the shadow-cljs build

when you js/require it then it will just resolve at runtime and not be part of the build

Yes, that works. Whereas before I wasn't trying to make shadow bundle things, I later wanted to see if I could get shadow bundling everything as you mentioned in that ticket. I've been reading stuff you said there multiple times and understanding more and more 😄. > Just stick with :node-library. :esm will not give you any "new" features if it requires post-processing anyways. So until vscode can load ESM directly without further bundling :esm should not be used. I'm sticking to :node-library but was thinking I could still bundle things with shadow if I could make typescript ignore the goog:.. imports, as you mentioned, and then stop using webpack. But I see you mentioned potential issues with that, so I probably will stop this approach now.

yeah I'd recommend sticking with js/require until you get the amount of JS code down significantly

That makes sense

its fine for smaller bits of JS code or JS code that is fully advanced compatible

but for the vast chunk of the vscode based code you probably won't have externs anyways

I see

I mean you can still go with this route and try it

but not many people do so there may be many issues with this that may require tinkering with shadow-cljs

it works ok-ish in the browser but node seems to have some problems

Yeah, I'd rather go the path of least resistance in this case

Has anyone built a custom shadow-cljs build target before? Is this actually possible? I spotted this in the shadow-cljs docs: > The build target is an extensible feature of `shadow-cljs` but am still looking for details about how it might be done :thinking_face: .. wondering if there are any examples out there

I would like to make a build target that combines devcards and karma (basically combine the current built-in :browser and :karma build targets), so I can use devcards as a test harness for UI-based cljs tests

@kiraemclean I guess as example you could look at the default provided targets, they all use the same mechanism a custom target would use. https://github.com/thheller/shadow-cljs/tree/master/src/main/shadow/build/targets

it is however not exactly documented or easy to do since they can get rather involved in low level stuff (eg. :browser https://github.com/thheller/shadow-cljs/blob/master/src/main/shadow/build/targets/browser.clj)

:karma is much simpler and I think already allows what you are looking for via the :runner-ns option https://github.com/thheller/shadow-cljs/blob/master/src/main/shadow/build/targets/karma.clj

defaults to this one https://github.com/thheller/shadow-cljs/blob/master/src/main/shadow/test/karma.cljs and I guess you could just create one that uses devcards instead

I'm trying to put my web-app into an app. I think http://capacitorjs.com looks pretty good so giving that a try. I've built and ran my app successfully, however firebase auth works a bit differently when running in apps (webview). I'm using the capacitor-firebase-auth plugin, but running into an error I haven't been able to solve yet and I think it's related to esModules stuff. The error I'm getting is: ⚡️ TypeError: undefined is not an object (evaluating 'new q.auth.GoogleAuthProvider') Originating here: https://github.com/baumblatt/capacitor-firebase-auth/blob/master/src/facades.ts#L28 I've tried to shadow-cljs release with

:release {:compiler-options {:variable-renaming :off
                             :property-renaming :off
                             :pretty-print      true
                             :source-map        true
                             :infer-externs :auto
                             :output-feature-set :es6
                             :optimizations :simple}}

Might it be there is a conflicting issue with typescript somehow? There is this comment in the readme:

1 import firebase from 'firebase/app';
         ~~~~~~~~
    8601 export = firebase;
         ~~~~~~~~~~~~~~~~~~
    This module is declared with using 'export =', and can only be used with a default import when using the 'allowSyntheticDefaultImports' flag.

@bbss and how does the CLJS code looking doing this?

(ns kr.ui.firebase
  (:require ["firebase/auth"]
            ["firebase/analytics"]
            ["firebase/app" :default firebase]
            ["capacitor-firebase-auth" :refer [cfaSignIn]]
            ["firebaseui" :as fbui]))
...

(.subscribe (cfaSignIn "<http://google.com|google.com>") (fn [u] (js/console.log u :signed-in))) ;;offending line in my code

the library file on github does a require like this: import * as firebase from 'firebase/app';

so (cfaSignIn "<http://google.com|google.com>") this fails?

yes

did you verify that the firebase version you use matches EXACLTY the version capacitor-firebase-auth expects?

I did not, let me check.

firebase is notorious for changing its API constantly

so I expect that you just use an incompatible version

could be! checking.

for example in the lib there is import * as firebase from 'firebase/app'; but you have ["firebase/app" :default firebase]

those are not the same thing and only one version is correct 😛

Ugh, they're not the same?

Yeah it's a major version mismatch, the plugin has peerdep 7.x.x and I use 8.x.x

downgrading..

https://github.com/baumblatt/capacitor-firebase-auth/issues/128 looks relevant..

great! updating to that alpha version mentioned in the issue seems to fix it!

Thanks for the insight @thheller

Does anybody know of an alternative to codox to auto generate documentation for a private cljs project? Codox looks great but seems like shadow w deps isn't officially supported.

(hope I'm posting in the correct place, if anyone knows a better channel to post in just lmk 🙂 )

you can just create a lein project.clj and use codox that way. as far as I know codox doesn't actually compile the code, just needs to be able to read it.

but it has been a while since I used and and only for CLJ at that