This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2023-10-25
Channels
- # announcements (22)
- # babashka (9)
- # beginners (33)
- # biff (12)
- # calva (17)
- # cider (64)
- # cljdoc (3)
- # cljfx (16)
- # clojure (125)
- # clojure-bay-area (14)
- # clojure-europe (15)
- # clojure-norway (64)
- # clojure-uk (2)
- # clojurescript (7)
- # conjure (1)
- # core-async (4)
- # cursive (6)
- # data-science (14)
- # datahike (8)
- # datomic (6)
- # defnpodcast (4)
- # emacs (5)
- # events (1)
- # hyperfiddle (15)
- # leiningen (17)
- # lsp (8)
- # membrane (27)
- # off-topic (25)
- # podcasts-discuss (4)
- # polylith (6)
- # portal (21)
- # reagent (11)
- # releases (1)
- # shadow-cljs (36)
- # slack-help (2)
- # sql (1)
- # squint (131)
- # testing (12)
- # xtdb (7)
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:
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
Is it possible to let webpack (or anything else) build the JS code for specific packages only?
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.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?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
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
I understand. Thank you very much for your prompt response!
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
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:
That was all that was needed. What the hell. ๐
I appreciate your help alot. Thanks!
there's no way to double bundle when targeting :esm
, is there?
ah, cool. didn't know about the :import
provider. thanks!
Hello, is there a way to configure the dev-http-proxy to work with self-signed certs (i.e. a :proxy-insecure true option)
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.
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.
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 ๐
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)