It's a TS interface - they don't exist in JS. That interface has a single field type. Just create a plain JS object with that field that has the right value and you should be all set.

So e.g. #js {:type "LOCAL"}.

Oh wonderful! you're a lifesaver. Thanks! ❤️

So it seems to work in that the login actually persists, but I get an exception: @firebase/auth: Auth (9.9.0): INTERNAL ASSERTION FAILED: Expected a class definition Would you know of a way to get around this?

That seems like an unrelated error, no clue.

Hmmm I found a way to sidestep it: Turns out google made an escape hatch for Persistence.LOCAL etc..., and it's browserLocalPersistence, browserSessionPersistence and the like. They are of "type" Persistence. I think maybe the library has some mechanism to reject js objects {type: "LOCAL"} for additional type safety.

The type property is supposed to be readonly. The value of a readonly prop must be declared on instantiation of a class (meaning inside constructor or as parameter to instantiating function new MyClass(someValue). Which means it must be a class property, not just an object property. The minimal step to mimic this is to add your type property to the prototype of an empty object, instead of to the object itself. But who knows what Google is actually using to test for the class def assertion. You might need to actually create an ES5 class and instantiate it. Looks like firebase provides a firebase.auth.Auth.Persistence.LOCAL, which I would expect to be an already instantiated Persistence.type. https://firebase.google.com/docs/auth/web/auth-state-persistence

You've deployed a development version. Usually, you should deploy a production version, created with shadow-cljs release.

Unless you're developing an app with shadow-cljs running in a container?..

ok

I did a lein uberjar and created the jar file which is run in the container. Is there a better way to do it?

No clue on the details of what exactly lein uberjar does, but ideally you should have a separate output directory for your production build and tell lein to only package that dir and not the other dir that stores UI development build.

ok

This might help you get it sorted out: https://shadow-cljs.github.io/docs/UsersGuide.html#Leiningen

it's been a while for me with lein but it sounds like lein uberjar might have packed up a development build that was lying around in resources/public and your host page fed it out. It depends on your build settings but this is exactly what I got help with here: https://clojurians.slack.com/archives/C6N245JGG/p1656086872084299 If you make sure that shadow doesn't put its dev builds in /resources then I don't think lein uberjar will pick it up. You will have to add whatever your dev location is to the classpath for dev only, though ... if it's not on the classpath, dev cljs won't load, and if it's on the classpath for prd builds, then you're back where you started with dev code in a prd uber jar.

you could also make sure to rm the dev code from /resources/public, then run the shadow release build, then make the uberjar, at least to debug and keep it simple.