still investigating, but preliminary issue seems to be that the “typeUrl” field in any.js was renamed to “om”

right now, trying to clean up so I can reproduce more scientifically

ill post back my findings, and with reproduction steps if I can

that would be normal behavior in advanced optimized code

why is that a problem though?

it might be exposing a different issue

it would only be a problem is you are accessing typeUrl incorrectly in your own code?

it materialized as not recognizing the message type

yeah, it could just be that (or some other substrate related to it

so just to be clear. you have removed ALL references to npm code from this?

thats what I am doing now

it will not work if you mix it with ANY npm code

to be clear: ive removed the “google-protobuf” and “grpc-web” npm packages, but I have others

i assume that is ok

as long as they aren't protobuf related that is ok yes

ok

let me get a clean run in and ill report back

i suspect if its even an issue, its an issue like you mentioned (something else, probably my code, doing the wrong thing)

FWIW you can prevent it from changing the name via externs

just create a externs/app.txt with typeUrl

then it won't rename that field. although you should find out why renaming it is a problem because it shouldn't be

ah, awesome

ty, i will keep that in my backpocket

@thheller so i confirmed this does indeed break for release, and I think I understand why

in essence, I am using a flow like (js->clj (.toObject pb)) so I can use clojure’s destructuring

e.g.

(let [{:keys [typeUrl]} (js->clj ..)])

not just here, where the Any type is not that difficult to work with either way

but for custom types, etc

is there any way to disable the field renaming for an entire module?

just curious if I need to abandon the .toObject approach

but it does strike me that renaming fields with ABI implications is probably not ideal

using js->clj just for the destructuring is a really bad idea. performance and code wise

but yes that would break with renaming enabled

there is no way to turn it off other then by specifying all the field names in the externs

yeah, you are probably right. Of course, my use is not quite as simplistic and crude as I imply above. Generally I just run js->clj on message receipt and then the map is passed around, destructured as needed.

but point taken

but it would seem that if I want to use jspb and advanced, I have little choice

thanks again for the help

you can always go back to the npm version and we can try to figure out why that wasn't working

it could also be fixed in the code without externs but that requires modifying the generated sources which isn't great

is that simply because the commonjs code cant be optimized?

it is optimized but not with :advanced

:advanced optimizations is really the ultimate goal since it makes your code sooooo much smaller which is good in pretty much all environments

makes your app start faster and so on

another way out is just turning off the propery renaming globally

you were writing a react-native app IIRC

so code size isn't the most important thing in the universe

:compiler-options {:property-renaming false} will turn off the renaming globally

no externs needed after that point

:compiler-options {:optimizations :simple} will be substantially bigger

awesome on property-renaming

will give that a shot

(yes I am currently working on react-native

and agree size isnt super critical

oddly, :simple blows up in xcode when I try to archive the .ipa

the output easily goes to several MB with :simple

maybe it contains code patterns it doesn't like

the react-native metro packager also had issues with :simple I believe

yeah, IIRC, :advanced is about 400k and :simple is ~5.5MB

for this particular app

doh

anyway, code cranks on trying to package up the main.jsbundle in a node process and eventually hits an OOM threshold and dies

:property-renaming should only add like 20% or so

that might be perfect

I had resolved myself to worse, already, heh

(i.e. shipping :none or dropping my beloved destructuring)

:none is worse than :simple 😛

yeah, except it completes AND runs

two key criteria, heh

maybe consider using https://github.com/mfikes/cljs-bean instead of js->clj

it isn't perfect but waaaaaaay better than js->clj

awesome, ty

will check that out

still suffers the renaming problem though

yeah, im about to fire up :property-renaming

that might be perfect

it might still blow up though since :advanced won't be able to identify that you are actually using the property

so it may just decide to remove it entirely

ah, i can see how that might be

but just to repeat. adding externs is probably the easiest and fastest way to fix it

either via interence type hints or just manual externs/app.txt

then you don't have to worry about renaming or removal

as you suspected, things werent quite right with just the property-renaming, though i dont quite understand what actually happened

I did observe that :typeUrl was left unperturbed, but there were other :advanced related issues that cropped up

what I dont get is why those worked when propety renaming was enabled.

oh well

i now know my options, anyway

yeah :advanced can be tough sometimes

swap! expects a function. You probably wanted to use reset!.

oh, i see, thanks