["marked" :as marked]

[:app] Build failure:
Failed to inspect file
  /home/chrism/dev/yt-transcript.com/node_modules/marked/lib/marked.cjs

Errors encountered while trying to parse file
  /home/chrism/dev/yt-transcript.com/node_modules/marked/lib/marked.cjs
  {:line 2247, :column 17, :message "'identifier' expected"}

["marked/marked.min.js" :as marked]

package marked had exports, but could not resolve ./marked.min.js
{:package #object[java.io.File 0x3550d766 "/home/chrism/dev/yt-transcript.com/node_modules/marked"], :require-from nil, :rel-require "./marked.min.js"}
ExceptionInfo: package marked had exports, but could not resolve ./marked.min.js
	shadow.build.npm/find-resource-in-package (npm.clj:807)
	shadow.build.npm/find-resource-in-package (npm.clj:793)
	shadow.build.npm/find-resource (npm.clj:923)
	shadow.build.npm/find-resource (npm.clj:847)
	shadow.build.resolve/find-npm-resource (resolve.clj:123)
	shadow.build.resolve/find-npm-resource (resolve.clj:94)
...

is there a stacktrace for the first error?

No that's all that is printed in the terminal. Is there something I can do to get one?

which shadow-cljs version do you use?

the closure compiler is choking on this line

parse = this.#parseMarkdown(_Lexer.lex, _Parser.parse);

but I thought that was supported nowadays, so maybe you are just on an old verison?

> which shadow-cljs version do you use? "version": "2.25.3"

unfortunately that is often that the relevant info

do you use deps.edn or project.clj?

["marked/lib/marked.umd.js" :refer [parse]] > JS reload failed Error: Package subpath './lib/marked.umd.js' is not defined by "exports" Is there a way to tell it to ignore "exports"?

npx shadow-cljs info

there is, but umd is not a supported package format

it also uses the same exact syntax, so it would choke the same

Info attached.

I guess it isn't supported yet then

If I use ["marked/lib/marked.esm.js" :refer [parse]]`` I get the same error.

All good I can use a different markdown renderer lib.

they all use the same syntax, so trying different files won't do anything

Ah ok.

you could search&replace the file and just replace .# with .

ugly but easily done is one line bash or so 😛

blame JS people for adding breaking syntax stuff all the time

Ah ok so it's closure not supporting the new syntax. Understood, thanks.

Yes I do. At night as I fall asleep I whisper curses against their names.

This was a big issue with Python too - continuously introducing cool new syntax that turns every stack into a giant house of cards every time you upgrade any package by one version.

Thank you for maintaining shadow-cljs in the midst of this madness.

https://github.com/google/closure-compiler/issues/2731#issuecomment-1431917034

yeah still work in progress I guess. unfortunately not something I can influence or work around from the shadow-cljs side

All good thanks for your help.

I downgraded marked one version and it now imports.

might be possible yes, I think the assumption was that the client waits for the done before sending the next eval

you can send multiple forms at once and they'll queue correctly

I tested a bit more and I think it is not necessarily a speed thing always

Clojure evaluation is sequential by definition atm not parallel right

But nrepl ops can be parallel

CLJS involves a whole lot of async, so its tough to make things truly sequential

not impossible of course, just didn't bother since waiting for the previous result is usually what you want

I think sometimes I'm not certain that the reason is but waiting for the done, I thought it was sorted but now I can't see a pattern when "done" is returned and when it isn't

Sorry that last message was a mess

I don't think it's happening just when the client doesn't wait for a done, I'm also seeing it when I do want

Wait

there is a nrepl-debug tool in shadow-cljs if you want to make sure what actually goes over the wire

Nice, in the web portal?

npx shadow-cljs --force-spawn run shadow.nrepl-debug 5000 .shadow-cljs/nrepl-port while another shadow-cljs is running

then connect your editor to port 5000

it creates a logfile in target/nrepl-debug thats basically just a dump of all messages

I ran this: npx shadow-cljs --force-spawn run shadow.nrepl-debug 5000 44475 it created 20 nrepl-20.log.edn files but they all seemed to be empty, it also logged stuff like this: in the terminal output: 3] [java.io.PushbackInputStream read "PushbackInputStream.java" 136] [nrepl.bencode$read_byte invokeStatic "bencode.clj" 87] [nrepl.bencode$read_byte invokePrim "bencode.clj" -1] [nrepl.bencode$read_token invokeStatic "bencode.clj" 239] [nrepl.bencode$read_token invoke "bencode.clj" 237] [nrepl.bencode$read_bencode invokeStatic "bencode.clj" 257] I didn't understand what you meant by connecting my editor to 5000, I tried a browser to localhost:5000 that didn't work

your nrepl client that you usually connect to the shadow-cljs port

Oh so it's opening another nrepl port there, got you, when I get back I'll connect to that and see what it says

I got back to connecting to this REPL, but am not sure what I should do with it once I am connected

it is just a proxy that logs all nrepl messages going over the wire

you do whatever else you were doing and get a full log of all messages going between shadow-cljs and your nrepl client

if you want me to debug an nrepl issue I need such a log

it probably is just what you showed above in the screenshot, but I need the full log

Is the log in the edn, the terminal or the repl output? None seem to be recording events from the (existing) repl in my first process, it just looks like a connection log of (itself)

it only logs what you send over it. it writes everything to the logfile. it doesn't log anything that doesn't go over the connection, so if you are connecting your REPL to the original server then that is not logged.

there is no setting to make the compiler do that no

Is that something that might be welcome in? I might attempt the implementation if so

that would need to happen in the clojurescript compiler itself, not something shadow-cljs can easily influence

I vaguely remember opening a similar ticket myself and eventually not caring anymore due to source maps

but that was like 10 years ago 😛

Naming anonymous fns to improve stack trace is a good tip I hadn't thought of, thanks for this!