I've noticed in my shadow-cljs project that when there is an error I don't get any useful line number -- just a bunch of references to browser.cljs. Is this a shadow-cljs limitation or a Clojurescript one, and is there something I can do about it?

I keep hearing that CLJS has very well-engineered source maps, but it's pretty frustrating to get a basic arity error or something of that nature and have zero idea where it's coming from. I'm hacking on a small project with Clojure right now, but if it grows searching around blindly until I figure out what section of the code an error came from definitely isn't going to be maintainable

Oh and this is running in watch-mode, if that has anything to do with it

@mail985 you need to be a bit more specific. I have no clue what your problem is. make screenshot or something that shows what you are talking about.

I can't seem to get css reloading working. I have a hiccup-generated page loading a css file at "/css/view.css", which on the fs is at resources/public/css/view.css. I'm not using :dev-http so I have {:target :browser ... :devtools {:watch-dir "public" ...} in shadow-cljs.edn. does that look right? maybe I'm missing something in deps.edn? shadow command is server

@kevin842 shjould be :watch-dir "resources/public"

hm.. I swear I had already tried that but I just tried it again and it worked. thanks :P

maybe I was thrown off by the loading spinner that pops up on the HUD when shadow-cljs.edn is edited, but didn't restart the server

I have a problem with (:require ["docx4js"]) with :target :react-native, it works, but with :target :browser it throws

[:app] Build failure:
The required JS dependency "/node_modules/docx4js/lib" is not available, it was required by "shadow.js.shim.module$node_modules$docx4js$lib$props.js".

Dependency Trace:
        r8/contree/styled_system.cljs
        node_modules/docx4js/lib/index.js
        node_modules/docx4js/lib/openxml/docx/document.js
        node_modules/docx4js/lib/openxml/document.js
        node_modules/docx4js/lib/document.js
        shadow.js.shim.module.js

ah. of course there are npm files that have $ in their name ... why wouldn't there be 😛

due to https://clojure.atlassian.net/browse/CLJS-3235 that is now a special char. guess I'll have to disable that functionality for node_modules ...

😅 can I quickfix this somehow, short of webpacking that lib?

no clue if you are even on a version with that feature yet. don't have time to look into the issue right now but it'd be my guess that its $

in which case you can only "fix" it by renaming the file and requires thereof

ok, thanks!

I have a .cljc file which uses a namespaced keyword in a :clj branch. When trying to evaluate that in a CLJS REPL, it barfs:

(cljs.core/load-file "/Users/lilactown/Code/amperity/app/service/web/web-ui/src/amperity/web/mx_segment/core.cljs")
------ ERROR -------------------------------------------------------------------
 File: /Users/lilactown/Code/amperity/app/service/segment/segment-core/src/clj/amperity/mx_segment/folder.cljc:52:20
--------------------------------------------------------------------------------
  49 |    (do
  50 |      (pc/defresolver list-resolver
  51 |        [{:keys [tree] :as env} _input]
  52 |        {::pc/output [{::all config-keys}]}
--------------------------^-----------------------------------------------------
amperity/mx_segment/folder.cljc [line 52, col 20] Invalid keyword: ::pc/output.

--------------------------------------------------------------------------------
  53 |        (d/chain
  54 |          (list tree)
  55 |          (fn [seg-list]
  56 |            {::all seg-list})))
--------------------------------------------------------------------------------

the namespace only exists in the :clj branch as well, so if the reader is trying to interpret it it makes sense why it would barf. I would just expect it skip it since it’s in a reader conditional

full offending code:

#?(:clj
   (do
     (pc/defresolver list-resolver
       [{:keys [tree] :as env} _input]
       {::pc/output [{::all config-keys}]}
       (d/chain
         (list tree)
         (fn [seg-list]
           {::all seg-list})))


     (pc/defresolver get-resolver
       [{:keys [tree] :as env} {:keys [::id] :as input}]
       {::pc/input #{::id}
        ::pc/output [{::node config-keys}]}
       (d/chain
         (get tree id)
         (fn [node]
           {::node node})))))

@lilactown either branch of the code must still be readable and as such must have that alias. not anything shadow-cljs can do anything about.

you can fake whatever alias you want but it must exist regardless

would need to be fixed in clojure and tools.reader if you want to take that on 😉

alright 😄 thanks

it’s pathom, so it is cljc. I’d rather not include all of pathom in my bundle if not necessary tho

do you think pathom would get :knife: if I require it but never refer it?

like I said .. only the alias needs to exist. doesn't matter what it points to (:require [clojure.string :as pc])

(I can check this myself just thought I would ask if you know off hand)

yeah that’s true!

Regarding aliases, may I direct your attention to https://clojure.atlassian.net/browse/CLJ-2030 and https://clojure.atlassian.net/browse/CLJ-2123

another question: I recently updated to 2.10.21. I’m now receiving an error on release:

--- amperity/web/stitch/report_v2/viz.js:1
Cannot import Closure files by path. Use either import goog:namespace or goog.require(namespace)

this file is an es module - I remember rewriting it from a goog module to es syntax

did the ES module require-by-path get removed?

or is there some way that I need to signal that it is in fact an es module, and not a goog module? (other than use import and export, which it does)

I haven't looked into this yet but there have been other reports

Not sure if that will answer your question, but I'm adding node modules in a separate source folder and make them available as package.json dependencies: "local-package": "file:./local-package-src"

not nothing should have changed in that regard. but it bumped closure which tends to change stuff ...

@bendlas I think this particular aliasing problem warrants a new issue. given that the code is immediately discarded anyways it shouldn't attempt to resolve it.

is there a known good version I can downgrade to w.r.t. es module issue, that’s better than going back to what I was on (2.8.61 😅 )

since I don't know what the issue is I cannot possibly answer that

k

I’ve narrowed it down to being introduced in 2.9.7

ostensibly https://github.com/thheller/shadow-cljs/commit/22b078a77444cc99ba22a87277f82286f0f90437

thanks. I'll see if I can figure it out.

@bendlas your issue should be fixed in 2.10.22.

@thheller at my new job we are doing a lot of serverless stuff so I end up having to jump into cloudwatch and copy and pasting edn a bunch. I am wondering if there is a way I can leverage tap> from within the AWS lambdas and point it at a kind of IRC Bouncer/inbox style thing and then pick the tap>ed values up on my local machine using shadow inspect

in theory yes. the code isn't written in practice though 😉

hmm don't the lambdas die after they have done their work?

tap> never actually transfers the full value so that would be a problem

you could automate the EDN copying. if you get it to your shadow-cljs instance you can just tap> it from CLJ

The lambda's do die after

I was under the impression that it actually sent a message

But I guess the bouncer thing could handle that

hmmmm

Gonna have to poke around with tap I guess

After I moved to an Electron app, I began getting this async-dispatch-N error when I shadow-cljs watch renderer . It happens non-deterministically, and usually mentions @material-ui/icons . The build is `

:renderer {:target :browser
                     :output-dir "resources/public/js/compiled"
                     :asset-path "js/compiled"

                     :modules {:renderer {:init-fn athens.core/init}}

                     :compiler-options {:closure-warnings {:global-this :off}
                                        :closure-defines {re-frame.trace.trace-enabled? true}}

                     :devtools {:preloads [devtools.preload
                                           day8.re-frame.trace.preload]}}

@tangj1122 only guess I have is that you maybe have a bad core.async version

make sure it matches the version shadow-cljs needs

check other possibly dependency conflicts while you are at it 😛

but could be a simple overload. @material-ui/icons adds thousands of files to your build. I fixed something to that extent in some version. can't remember which.

hmm cljs.core.async is not a dependency in this project

check lein deps :tree for conflicts

or maybe just try upgrading. could just be the overload issue I fixed not too long ago

ok, trying to upgrade from 2.8.110 to 2.10.22

(no conflicts in deps tree)

I don't seem to be getting the error anymore, after running it 5 times. The probability is in my favor. Thanks @thheller ❤️