Fork me on GitHub
#shadow-cljs
<
2022-06-22
>
martinklepsch12:06:52

When working with the node repl I occasionally get these logs from the server output. I think I’m evaluating something that fails but I’m not sure how to investigate, it just seems to kill the node repl process:

:shadow.cljs.devtools.server.repl-impl/node-repl-exit - {:code 1}
Looking for pointers to debug this 🙂

martinklepsch13:06:02

Somehow this seems to vaguely correlate with warnings in the shadow compilation process :thinking_face:

martinklepsch13:06:43

And then it also seems as if — after the first REPL session crashes — the next one is started with slightly different settings, i.e. I’m getting an error (deep in library code) that I believe is linked to env vars that I’m not getting in the first REPL session

martinklepsch13:06:53

This warning is also confusing me… there is a type hint but it seems like its not picked up?

40 |     (.. ^js client -tags (tagContact (clj->js {:contactId contact-id
-----------^--------------------------------------------------------------------
 Cannot infer target type in expression (. (. client -tags) (tagContact (clj->js {:contactId contact-id, :tagId (:id matching-tag)})))

martinklepsch13:06:25

I now tried commenting out this line but the REPL still seems to pick up the old state of the file somehow

martinklepsch13:06:45

Sorry for this very chaotic report to anyone who tries to follow along 😅

martinklepsch15:06:29

Found https://github.com/thheller/shadow-cljs/blob/b1d564f2987ee5ff281f8114f22644a2ab5f770e/src/main/shadow/cljs/devtools/server/repl_impl.clj#L451-L454 where ::node-repl-exit is used — would there be any way to log more information about the error? I’m just seeing the node repl process crash again and again and can’t really tell why…

thheller17:06:21

there is no more info available. it just quits with exit code 1. I'm guessing you just have an uncaught exception? which in node means the process dies.

thheller17:06:22

about the typehint I believe .. looses typehints. I only use -> nowadays

martinklepsch17:06:25

could shadow set up an exception handler for this type of thing (but still kill the process) so that some more info can be reported?

thheller18:06:00

well for that I'd need to know what you are doing exactly

thheller18:06:03

cljs.user=> (js/setTimeout boom! 1)

C:\Users\thheller\code\shadow-cljs\.shadow-cljs\builds\node-repl\dev\out\cljs-runtime\cljs\core.cljs:11623
  (let [e (js/Error. message)]
          ^
Error: boom
    at new cljs$core$ExceptionInfo (C:\Users\thheller\code\shadow-cljs\.shadow-cljs\builds\node-repl\dev\out\cljs-runtime\cljs\core.cljs:11623:11)
    at Function.cljs.core.ex_info [as cljs$core$IFn$_invoke$arity$3] (C:\Users\thheller\code\shadow-cljs\.shadow-cljs\builds\node-repl\dev\out\cljs-runtime\cljs\core.cljs:11650:1)
    at Function.cljs.core/ex-info [as cljs$core$IFn$_invoke$arity$2] (C:\Users\thheller\code\shadow-cljs\.shadow-cljs\builds\node-repl\dev\out\cljs-runtime\cljs\core.cljs:11653:16)
    at cljs$core$ex_info (C:\Users\thheller\code\shadow-cljs\.shadow-cljs\builds\node-repl\dev\out\cljs-runtime\cljs\core.cljs:11650:1)
    at Timeout.cljs$user$boom_BANG_ [as _onTimeout] (<eval>:3:25)
    at listOnTimeout (internal/timers.js:554:17)
    at processTimers (internal/timers.js:497:7)
The previously used runtime disappeared. Will attempt to pick a new one when available but your state might be gone.
cljs.user=> shadow-cljs - #13 ready!

thheller18:06:29

this is an async uncaught exception in a regular shadow-cljs node-repl

thheller18:06:38

so every is reported and the runtime is restarted normally

martinklepsch18:06:55

ah - i'm connected via nrepl and conjure (vim)

thheller18:06:47

(defn boom! [] (throw (ex-info "boom" {})))
=> #'cljs.user/boom!
(js/setTimeout boom! 1)

C:\Users\thheller\code\shadow-cljs\.shadow-cljs\builds\node-repl\dev\out\cljs-runtime\cljs\core.cljs:11623
  (let [e (js/Error. message)]
          ^
Error: boom
    at new cljs$core$ExceptionInfo (C:\Users\thheller\code\shadow-cljs\.shadow-cljs\builds\node-repl\dev\out\cljs-runtime\cljs\core.cljs:11623:11)
    at Function.cljs.core.ex_info [as cljs$core$IFn$_invoke$arity$3] (C:\Users\thheller\code\shadow-cljs\.shadow-cljs\builds\node-repl\dev\out\cljs-runtime\cljs\core.cljs:11650:1)
    at Function.cljs.core/ex-info [as cljs$core$IFn$_invoke$arity$2] (C:\Users\thheller\code\shadow-cljs\.shadow-cljs\builds\node-repl\dev\out\cljs-runtime\cljs\core.cljs:11653:16)
    at cljs$core$ex_info (C:\Users\thheller\code\shadow-cljs\.shadow-cljs\builds\node-repl\dev\out\cljs-runtime\cljs\core.cljs:11650:1)
    at Timeout.cljs$user$boom_BANG_ [as _onTimeout] (<eval>:3:25)
    at listOnTimeout (internal/timers.js:554:17)
    at processTimers (internal/timers.js:497:7)
The previously used runtime disappeared. Will attempt to pick a new one when available but your state might be gone.

thheller18:06:54

thats cursive nrepl

thheller18:06:21

maybe conjure is redirecting the output someplace or drops it or something?

martinklepsch18:06:30

and i have a slightly custom way of starting shadows node repl as well

thheller18:06:08

I don't think there is any setting that would control how this works so that shouldn't matter

martinklepsch18:06:32

yeah i guess it's maybe something between conjure and shadow

Olical22:06:43

Hmm I'm not sure about the issue right now but might need an issue raise on conjure with as much context as you can so I can reproduce it and dig into it. I'm guessing there's either an uncaught error or I'm catching it and not responding in a good way (i.e. it looks like a fatal thing to me but I shouldn't treat it that way)

thheller06:06:23

FWIW shadow-cljs is sending the messages as :err. eg.

;; ----------------------------------------
;; -- FROM  :client
;; ----------------------------------------
{:code "(js/setTimeout boom! 1)",
 :id "93653b42-8d31-464a-894d-9083ec171c61",
 :op "eval",
 :session "1b5a65b8-737e-4114-8f17-cd6c8c0bf121"}

;; ----------------------------------------
;; -- FROM  :target
;; ----------------------------------------
{:err "\n",
 :id "93653b42-8d31-464a-894d-9083ec171c61",
 :session "1b5a65b8-737e-4114-8f17-cd6c8c0bf121"}

;; ----------------------------------------
;; -- FROM  :target
;; ----------------------------------------
{:err
 "C:\\Users\\thheller\\code\\shadow-cljs\\.shadow-cljs\\builds\\node-repl\\dev\\out\\cljs-runtime\\cljs\\core.cljs:11623\n  (let [e (js/Error. message)]\n          ^\n",
 :id "93653b42-8d31-464a-894d-9083ec171c61",
 :session "1b5a65b8-737e-4114-8f17-cd6c8c0bf121"}

;; ----------------------------------------
;; -- FROM  :target
;; ----------------------------------------
{:err
 "Error: boom!\n    at new cljs$core$ExceptionInfo (C:\\Users\\thheller\\code\\shadow-cljs\\.shadow-cljs\\builds\\node-repl\\dev\\out\\cljs-runtime\\cljs\\core.cljs:11623:11)\n    at Function.cljs.core.ex_info [as cljs$core$IFn$_invoke$arity$3] (C:\\Users\\thheller\\code\\shadow-cljs\\.shadow-cljs\\builds\\node-repl\\dev\\out\\cljs-runtime\\cljs\\core.cljs:11650:1)\n    at Function.cljs.core/ex-info [as cljs$core$IFn$_invoke$arity$2] (C:\\Users\\thheller\\code\\shadow-cljs\\.shadow-cljs\\builds\\node-repl\\dev\\out\\cljs-runtime\\cljs\\core.cljs:11653:16)\n    at cljs$core$ex_info (C:\\Users\\thheller\\code\\shadow-cljs\\.shadow-cljs\\builds\\node-repl\\dev\\out\\cljs-runtime\\cljs\\core.cljs:11650:1)\n    at Timeout.cljs$user$boom_BANG_ [as _onTimeout] (<eval>:3:25)\n    at listOnTimeout (internal/timers.js:554:17)\n    at processTimers (internal/timers.js:497:7)\n",
 :id "93653b42-8d31-464a-894d-9083ec171c61",
 :session "1b5a65b8-737e-4114-8f17-cd6c8c0bf121"}

martinklepsch11:06:25

Hm. So I tried playing around with this with a plain shadow node-repl and Conjure and that seems to work just fine. Unfortunately I’m not sure how to trigger the same error as before.

Chris G17:06:37

hello folks, question 🧵

Chris G17:06:29

my team is attempting to leverage shadow-cljs to utilizing some npm packages from an internal resource, our app is compiling fine, but when i attempt to pull in the packaged lib as a dependency in a namespace i get an error:

Closure compilation failed with 8 errors
--- node_modules/@guaranteed-rate/shared-gr-react-components/dist/index.js:66
Illegal variable reference before declaration: a
--- node_modules/@guaranteed-rate/shared-gr-react-components/dist/index.js:66
Illegal variable reference before declaration: b
--- node_modules/@guaranteed-rate/shared-gr-react-components/dist/index.js:66
Illegal variable reference before declaration: e
--- node_modules/@guaranteed-rate/shared-gr-react-components/dist/index.js:66
Illegal variable reference before declaration: h
--- node_modules/@guaranteed-rate/shared-gr-react-components/dist/index.js:66
Illegal variable reference before declaration: i
--- node_modules/@guaranteed-rate/shared-gr-react-components/dist/index.js:66
Illegal variable reference before declaration: r
--- node_modules/@guaranteed-rate/shared-gr-react-components/dist/index.js:66
Illegal variable reference before declaration: t
--- node_modules/@guaranteed-rate/shared-gr-react-components/dist/index.js:66
Illegal variable reference before declaration: w
im unsure if there's something wrong with the way we are attempting to call the package or if there is something wrong in the package itself

Chris G17:06:28

here's how im requiring the package

["@guaranteed-rate/shared-gr-react-components" :as shared-gr-react-components]

thheller17:06:03

this is a problem in the JS code. the closure compiler is sometimes a little picky about some code

Chris G17:06:02

okay so it seems to be in reference to this?

thheller18:06:02

no, not at all

thheller18:06:15

that is very much different

thheller18:06:54

I mean if you control the JS code you can try to identify what exactly it has issues with and avoid that pattern

thheller18:06:06

must be something uncommon anyways since this error is quite rare

thheller18:06:24

unfortunately it is deeply in the closure compiler internals, so I cannot do anything about it from the shadow-cljs side of things

Chris G18:06:52

i see okay, thanks for you input 🙂