Fork me on GitHub
#shadow-cljs
<
2023-10-25
>
Shako Farhad15:10:51

I am trying to get React Three Fiber and React Drei to work. But for some reason I am getting this error that i haven't seen before:

thheller15:10:11

thats an error from the closure compiler. usually some code it doesn't understand. if you are on the latest shadow-cljs version there is unfortunately nothing to do

thheller15:10:24

except letting webpack (or other JS tool) build the JS code

Shako Farhad15:10:09

Is it possible to let webpack (or anything else) build the JS code for specific packages only?

Shako Farhad15:10:27

When I added this line to the shadow-cljs.edn, I get this error instead.

:js-options {:resolve {"three-stdlib" {:target :npm :require "three-stdlib/index.js"}}}
The index.js does exist. And this used to work fine in an earlier version of shadow-cljs. I managed to build this.

thheller15:10:48

shadow-cljs now follow "exports" in package.json, this package has one

thheller15:10:26

you can set :js-options {:ignore-exports true} in the build config

thheller15:10:33

don't know why you are doing that though ๐Ÿ˜›

Shako Farhad15:10:27

Hmmm.. Not sure if I understand. The part that causes all the issues is this:

["@react-three/drei" :as react-drei]
Whenever I try to use this, I have to jump through hoops. All the other stuff seems to work fine. Do I need to add something to my packages.json?

thheller15:10:04

then that package does stuff that the closure compiler doesn't like

thheller15:10:15

there is nothing to set or do, except not use the closure compiler

thheller15:10:57

not something I can influence from the shadow-cljs side either unfortunately, the closure compiler has been lagging on some features the JS world widely adopted

thheller15:10:05

so we can only wait ๐Ÿ˜›

Shako Farhad15:10:26

I see. Ok. That sucks. I fixed some closure compiler warnings for that package and it did work before, but seems like a new version of shadow-cljs makes it unusable again. Or maybe there is something else going :x

Shako Farhad15:10:46

I understand. Thank you very much for your prompt response!

thheller15:10:29

as I said you can set :js-options {:ignore-exports true} in the build config. that will revert back to the old behavior, so your previous hacks might work

Shako Farhad15:10:23

I tried it but then it gives me this:

[:app] Build failure:
The required JS dependency "buffer" is not available, it was required by "node_modules/ktx-parse/dist/ktx-parse.cjs".

Dependency Trace:
        darts_monitor_client/core.cljs
        darts_monitor_client/views.cljs
        node_modules/@react-three/drei/index.cjs.js
        node_modules/three-stdlib/index.js
        node_modules/three-stdlib/loaders/KTX2Loader.js
        node_modules/ktx-parse/dist/ktx-parse.cjs

Searched for npm packages in:
        /home/dev/src/mono/darts-monitor-client/node_modules

See: 

thheller15:10:08

npm install buffer?

Shako Farhad15:10:29

That was all that was needed. What the hell. ๐Ÿ˜‚

Shako Farhad15:10:38

I appreciate your help alot. Thanks!

Ben Lieberman20:10:13

there's no way to double bundle when targeting :esm , is there?

thheller06:10:39

no need for double bundle when you can just run the output through other tools?

Ben Lieberman13:10:51

ah, cool. didn't know about the :import provider. thanks!

ghaskins23:10:29

Hello, is there a way to configure the dev-http-proxy to work with self-signed certs (i.e. a :proxy-insecure true option)

thheller07:10:04

uhm in what context? I mean where is the problem without any setting?

ghaskins21:10:01

Our development deployments use a self-signed TLS cert by default. If I wish to develop the UI with the shadow-cljs dev-proxy as the basis of rapid iteration, I find that something breaks with the self-signed TLS enabled. It does work fine when the backend has a real cert, ala LetsEncrypt, in production, and it works fine if I reconfigure the deployment to disable TLS. So, as a workaround, when I need to do UI dev, I disable TLS. I was just curious if there is a way to configure the dev-proxy so I donโ€™t need to do this dance.

ghaskins21:10:20

FWIW, I do install the self-signed cert into my OSX KeyChain access and mark it as trusted, which satisfies some of the clients in the dev-flow, but not shadow-cljs dev proxy.

thheller07:10:37

could you specify what the actual problem is? like error messages or whatever? I don't really know what the problem is, so I don't know how to fix it ๐Ÿ˜›

ghaskins12:10:59

oh, sure. Let me set up another run

ghaskins17:10:16

This is an example error

Oct 27, 2023 1:26:46 PM io.undertow.server.handlers.proxy.ProxyHandler handleFailure
ERROR: UT005028: Proxy request to / failed
java.nio.channels.ClosedChannelException
	at io.undertow.client.http.HttpClientConnection$5.handleEvent(HttpClientConnection.java:192)
	at io.undertow.client.http.HttpClientConnection$5.handleEvent(HttpClientConnection.java:171)
	at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
	at org.xnio.StreamConnection.invokeCloseListener(StreamConnection.java:80)
	at org.xnio.Connection.writeClosed(Connection.java:117)
	at io.undertow.protocols.ssl.UndertowSslConnection.writeClosed(UndertowSslConnection.java:150)
	at io.undertow.protocols.ssl.SslConduit.notifyWriteClosed(SslConduit.java:604)
	at io.undertow.protocols.ssl.SslConduit.closed(SslConduit.java:1057)
	at io.undertow.protocols.ssl.SslConduit.close(SslConduit.java:1155)
	at io.undertow.protocols.ssl.SslConduit.doUnwrap(SslConduit.java:836)
	at io.undertow.protocols.ssl.SslConduit.doHandshake(SslConduit.java:664)
	at io.undertow.protocols.ssl.SslConduit.access$900(SslConduit.java:68)
	at io.undertow.protocols.ssl.SslConduit$5$1.run(SslConduit.java:1121)
	at org.xnio.nio.WorkerThread.safeRun(WorkerThread.java:612)
	at org.xnio.nio.WorkerThread.run(WorkerThread.java:479)

thheller19:10:18

hmm. nothing else?

ghaskins19:10:21

no. I see those in the shadow-cljs dev proxy window, and the browser remains blank

ghaskins19:10:47

I interpreted the behavior as balking at the self-signed cert, but I admit that is a guess