Fork me on GitHub
#shadow-cljs
<
2019-10-17
>
thheller08:10:35

@lilactown thats a known bug in CLJS. I think the fix is in master. can't remember the ticket number, something related to type-inference

ghaskins11:10:44

@thheller following up on the cljs-protobuf conversation: im trying to untangle the next problem (adding grpc-web on top of google-protobufs

ghaskins11:10:05

when I go with a closure-based output, I see an error like this

ghaskins11:10:16

The required namespace "grpc.web.GrpcWebClientBase" is not available

ghaskins11:10:27

however, when referencing it purely from the npm “grpc-web” package, I see

ghaskins11:10:29

so, if I had to guess, something about the way the community packages the npm package loses the export in translation

ghaskins11:10:36

is that a good summary of the problem?

thheller12:10:28

@ghaskins don't try to use this npm packages

ghaskins12:10:52

yeah, im using your approach to jspb on grpc-web

ghaskins12:10:01

yep, thats what I am doing now

ghaskins12:10:15

it seems to work, though I saw one thing in release builds that might be an issue

ghaskins12:10:18

still investigating

ghaskins12:10:59

is this a common problem, or something inherent to how the pb/grpc community is packaging for npm?

thheller12:10:36

the thing about all of this is that the "greater" JS ecosystem has no clue how to consume closure JS code

thheller12:10:11

so to get this all accessible to the npm world they "wrap" everything in some boilerplate code to make it work with npm

thheller12:10:37

and that is always strictly worse than just consuming the closure JS code directly

thheller12:10:52

which is no problem for use given that we use the closure library + compiler anyways

thheller12:10:06

BUT since that is not a "common" thing in the JS ecosystem

thheller12:10:12

there are not "pure" closure JS packages

thheller12:10:37

ie. you could put the grpc-web stuff into a .jar and publish it as a regular library

thheller12:10:54

but they (ie. google) doesn't even do that for the closure-library itself

thheller12:10:53

whats the release build issue? this should be working out of the box as far as I can tell (no custom config)

ghaskins12:10:39

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

ghaskins12:10:03

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

ghaskins12:10:50

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

thheller12:10:55

that would be normal behavior in advanced optimized code

thheller12:10:00

why is that a problem though?

ghaskins12:10:21

it might be exposing a different issue

thheller12:10:23

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

ghaskins12:10:39

it materialized as not recognizing the message type

ghaskins12:10:50

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

thheller12:10:04

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

ghaskins12:10:12

thats what I am doing now

thheller12:10:14

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

ghaskins12:10:37

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

ghaskins12:10:39

i assume that is ok

thheller12:10:58

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

ghaskins12:10:17

let me get a clean run in and ill report back

ghaskins12:10:37

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

thheller12:10:43

FWIW you can prevent it from changing the name via externs

thheller12:10:04

just create a externs/app.txt with typeUrl

thheller12:10:28

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

ghaskins12:10:35

ah, awesome

ghaskins12:10:41

ty, i will keep that in my backpocket

ghaskins17:10:06

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

ghaskins17:10:55

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

ghaskins17:10:50

e.g.

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

ghaskins17:10:14

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

ghaskins17:10:21

but for custom types, etc

ghaskins17:10:59

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

ghaskins17:10:11

just curious if I need to abandon the .toObject approach

ghaskins17:10:58

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

thheller19:10:00

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

thheller19:10:17

but yes that would break with renaming enabled

thheller19:10:36

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

ghaskins20:10:10

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.

ghaskins20:10:13

but point taken

ghaskins20:10:08

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

ghaskins20:10:11

thanks again for the help

thheller20:10:34

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

thheller20:10:56

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

ghaskins21:10:03

is that simply because the commonjs code cant be optimized?

thheller21:10:19

it is optimized but not with :advanced

thheller21:10:09

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

thheller21:10:16

makes your app start faster and so on

thheller21:10:05

another way out is just turning off the propery renaming globally

thheller21:10:15

you were writing a react-native app IIRC

thheller21:10:25

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

thheller21:10:46

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

thheller21:10:56

no externs needed after that point

thheller21:10:47

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

ghaskins21:10:10

awesome on property-renaming

ghaskins21:10:13

will give that a shot

ghaskins21:10:29

(yes I am currently working on react-native

ghaskins21:10:37

and agree size isnt super critical

ghaskins21:10:07

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

thheller21:10:37

the output easily goes to several MB with :simple

thheller21:10:48

maybe it contains code patterns it doesn't like

thheller21:10:12

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

ghaskins21:10:54

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

ghaskins21:10:00

for this particular app

ghaskins21:10:32

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

thheller21:10:38

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

ghaskins21:10:49

that might be perfect

ghaskins21:10:10

I had resolved myself to worse, already, heh

ghaskins21:10:27

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

thheller21:10:46

:none is worse than :simple 😛

ghaskins21:10:02

yeah, except it completes AND runs

ghaskins21:10:08

two key criteria, heh

thheller21:10:43

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

thheller21:10:58

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

ghaskins21:10:04

awesome, ty

ghaskins21:10:07

will check that out

thheller21:10:25

still suffers the renaming problem though

ghaskins21:10:45

yeah, im about to fire up :property-renaming

ghaskins21:10:50

that might be perfect

thheller21:10:34

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

thheller21:10:43

so it may just decide to remove it entirely

ghaskins21:10:03

ah, i can see how that might be

thheller21:10:34

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

thheller21:10:50

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

thheller21:10:23

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

ghaskins21:10:52

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

ghaskins21:10:26

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

ghaskins21:10:07

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

ghaskins21:10:25

i now know my options, anyway

thheller22:10:01

yeah :advanced can be tough sometimes

thheller12:10:40

but you have to use it correctly still, so no (:require ["grpc-web" ...])

thheller12:10:58

just make sure that all code you generate uses the closure JS output

thheller12:10:04

never mix it with commonjs or so

thheller12:10:22

either go purely this way or purely npm

vinurs14:10:54

(let [username (r/atom "")]
  (swap! username "admin"))
i eval this, it outputs
TypeError: f.call is not a function
    at Object.eval [as cljs$core$ISwap$_swap_BANG_$arity$2] ()
    at Function.eval [as cljs$core$IFn$_invoke$arity$2] ()
    at Function.eval [as cljs$core$IFn$_invoke$arity$2] ()
    at cljs$core$swap_BANG_ ()
    at eval (eval at <anonymous> (), <anonymous>:2:29)
    at eval (eval at <anonymous> (), <anonymous>:3:3)
    at eval ()
    at Object.shadow$cljs$devtools$client$env$repl_call [as repl_call] ()
    at Object.shadow$cljs$devtools$client$react_native$repl_invoke [as repl_invoke] ()
    at shadow$cljs$devtools$client$react_native$handle_message ()

p-himik14:10:41

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

vinurs14:10:06

oh, i see, thanks

sb14:10:00

is that possible run npx command via shadow.api? eg ‘npx sass --watch sass/main.scss:public/css/main.css’

thheller14:10:19

just run it separately

sb14:10:34

ok, thanks. yes, in this case!

thheller14:10:09

there are enough tools that only focus on running things in parallel. use one of those

👍 4
magra19:10:21

Hi! shadow-cljs works fine and fast. But once in a while my app stops working (fulcro) and shadow-cljs in the browser reports that semantic-ui node modules can not be found. Restarting the browser does not help, but terminating shadow-cljs and doing a new jack-in (from cider) and all is well again. How do I force a recompile from the connected repl without restarting the dev environment? when I type :cljs/quit and then (shadow.cljs.devtools.api/watch :main) it says "already watching".

lilactown19:10:32

you can try (shadow.cljs.devtools.api/stop-worker :main) and then run the watch again

thheller19:10:03

@magra any more info on "when" it stops working? might it be relating to running npm install or so while the watch is running?

magra20:10:05

@thheller Last time it happened after I did a restart on the fulcro server. That does a (tools-ns/refresh). I did not issue a manual npm install before the last occurance.

thheller20:10:36

do you have shadow-cljs running in embedded mode?

thheller20:10:53

in which case tools.namespace will definitely mess things up badly

magra21:10:24

I don't think so.

emccue23:10:32

shadow-cljs - config: C:\Users\Ethan\Development\vrtest\shadow-cljs.edn  cli version: 2.8.64  node: v10.16.3            shadow-cljs - socket connect failed, server process dead?
shadow-cljs - server version: 2.8.64 running at 
shadow-cljs - nREPL server started on port 49330
shadow-cljs - watching build :frontend
[:frontend] Configuring build.
[:frontend] Compiling ...
[:frontend] Build completed. (134 files, 1 compiled, 0 warnings, 3.18s)

emccue23:10:55

starting up a new project with shadow-cljs and i am not able to connect over http

emccue23:10:02

following the readme directly

emccue23:10:12

{:source-paths
 ["src/dev"
  "src/main"
  "src/test"]

 :dependencies
 []

 :builds
 {:frontend
  {:target :browser
   :dev-http {8080 "public"}
   :modules {:main {:init-fn vr/init}}}}}

emccue23:10:27

with the regular command npx shadow-cljs watch frontend

emccue23:10:49

my suspicion is that "server connect failed, server process dead?" error is to blame

emccue23:10:02

aaand i put :dev-http in the wrong place

emccue23:10:15

(init)
Hello World
=> nil
(js/console.log "A")
Syntax error compiling at (REPL:1:1).
No such namespace: js

emccue23:10:28

maybe a cursive question