This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2022-07-04
Channels
- # announcements (10)
- # asami (6)
- # babashka (22)
- # beginners (44)
- # biff (1)
- # calva (8)
- # clj-kondo (13)
- # clojure (62)
- # clojure-art (1)
- # clojure-europe (27)
- # clojure-nl (1)
- # clojure-norway (19)
- # clojure-spec (19)
- # clojure-uk (2)
- # component (29)
- # datascript (1)
- # fulcro (9)
- # gratitude (2)
- # kaocha (6)
- # klipse (1)
- # luminus (16)
- # malli (9)
- # nbb (5)
- # off-topic (4)
- # reagent (5)
- # shadow-cljs (85)
- # spacemacs (1)
- # tools-deps (10)
- # vim (9)
- # xtdb (2)
How can I variable names in comment around? I often do some quick experimentation and define variables in comments to hold some results. However, due to the hot load mechanism, these variables will disappear. For example
(ns foo)
(comment
(def *a (result-of-some-http-req))
*a will disappear after add some change in other parts of the file. How can I disable this behavior?
I verified, js/foo.STARa_ still exist. It’s just the access of foo/*a gives the undeclared var error(ns foo)
(declare *a)
(coment
(def *a (....))
and it works. But I ’d rather move anything about *a to be inside the comment.I want to get a warning for that immediately and not at some arbritrary time later when I restart the build or something
But consider my use case, it is possible to tell shadow to not erase the declaration for vars beginning with a * ?
Then what’s your workflow regarding this? Hotload is great, but on the other hand, it breaks the interactive testing loop cycle.
After the tap, what’s the next step? How can you look into some nested data fields of the result? Some tools like portal?
One thing to mention, it does not has much to do with the REPL. I mostly perform evaluation in the comment block with the repl panel closed. It’s just things def-ed in the comment block are resetted.
thats a weird statement. I mean what do you care about it getting reset if you don't look at it anyways?
(comment
(def *a (some-stuff))
(def *b (:key *a))
)
I do look at it. But it’s the inline result not from repl.Btw, will the previously required names, e.g., (require ’[foo :refer [bar]), will the bar be kept around after a reload?
We are looking for ways to speed up the advanced compilation of our large CLJS codebase. I thought code splitting might help, so I tried it out by putting a couple of namespaces into my-module
. My example setup is main
+ my-module
that depends on main
. My expectation was that modifying a file within my-module
would only rebuild the my-module.js
file, but compile times were the same both for modifying files on main and my-module.
My question is: Does shadow skip advanced compilation for modules with no changes on the file system?
:advanced
is whole program optimization. :modules
just splits the final output into multiple files. it still needs to compile everything all at once.
hello, on Shadow I'm seeing a lot of reflection warnings when compiling, not sure the cause:
I guess you are running shadow-cljs in an embedded/repl context somehow that binds *warn-on-reflection*
to true globally? normally you shouldn't see those?
makes sense, gonna dig in, thanks!
Hello. I'm using :target :graaljs
and getting this error message, while trying to load the cljs into polyglot context:
shadow-cljs - failed to load module$node_modules$react_dom$cjs$react_dom_server_browser_development
shadow-cljs - failed to load module$node_modules$react_dom$server_browser
{:clojure.main/message
"Execution error (PolyglotException) at <js>/:anonymous (ssr.js:47696).\nReferenceError: TextEncoder is not defined\n",
:clojure.main/triage
{:clojure.error/cause "ReferenceError: TextEncoder is not defined",
:clojure.error/symbol <js>/:anonymous,
:clojure.error/source "ssr.js",
:clojure.error/phase :execution},
...
Steps to reproduce:
git clone --branch graaljs-ssr ; cd atemoia; npm install && clj -A:dev -X atemoia.server/dev-main
nothing to do from the shadow-cljs side. this is just graaljs being very limited and honestly I would strongly recommend to just use node instead
That limitations are by design (the don't want to implement it) or it just incomplete because it is in development?
seems that graaljs@node-mode has TextEncoder. Anyway thanks thheller. Now I know what to do https://github.com/oracle/graaljs/blob/f13548b2536971b58c185ba37dc50e6cc29fe968/graal-nodejs/test/parallel/test-whatwg-encoding-custom-interop.js
I haven't figured out how you can run the scriptengine with node mode enabled. so far it just seems to be available as a node
executable replacement
I don't follow graaljs much. so no clue what their plans are regarding more features
BTW, I just leaned about https://blog.cloudflare.com/introducing-the-wintercg/
Seems that a cool project could be WinterGC compliance to graaljs
.
It may turn graaljs into a nicer target for shadow-cljs 👀
@U05224H0W do you have a list of API's that shadow-cljs need to be able to have a REPL inside graaljs?
that entirely depends on how you use it. it is somewhat possible if you control the JVM side graal context and can just use the java side to eval stuff and so on
the JS side doesn't have any IO built-in so the REPL is pretty much a no-go purely from the JS side
I'm working on add fetch/websocket/other missing api's into graaljs 🙂 https://github.com/souenzzo/inverno/blob/fetch/src/test/br/dev/zz/inverno_test.clj#L27
Hey guys, whenever I setup a new shadow-cljs project, and I try to run the repl/watch the build, it gives me errors about transitive dependencies of the JS packages I have in my package.json. And it does not stop until I manually install them. Today it went as far as making me install packages like base64-js and the like manually. I think this should not be the case, so I'm most likely doing something wrong. Could anyone point me to what though? TLDR; shadow-cljs makes me add transitive deps manually, and I don't think that's the intended behavior.
@ahlawatkaran14 if you have packages in pacakge.json
you need to run npm install
without specifying a package to install them all. otherwise it only ends up installing whatever package you specified
I use pnpm, but I don't think that should have any effect?
since pnpm supports the same node_modules resolution to be npm compatible
it looks pretty similar tbh. Thanks though, will report back
I’ve had a similar experience using pnpm, in that not all the dependant libraries get installed as happens with npm. Without fully understanding what the issue is, I found that running pnpm i --shamefully-hoist
usually fixes this type of issue. The https://pnpm.io/npmrc:
shamefully-hoist
Default: false
Type: Boolean
By default, pnpm creates a semistrict node_modules, meaning dependencies have access to undeclared dependencies but modules outside of node_modules do not. With this layout, most of the packages in the ecosystem work with no issues. However, if some tooling only works when the hoisted dependencies are in the root of node_modules, you can set this to true to hoist them for you.
That did help, thanks 😄
This is what I'm talking about
can't say., which shadow-cljs version do you use? older versions didn't properly support symlinks and the node resolve rules fully. current version does but I never tried pnpm so no clue what else might be going on
The latest one that is on the npm registry, so 2.19.5
hm, using npm works just fine though. So I suppose it's a pnpm thing then
So I have this new webworker library I'm working on. It's basically the connection/communication/mesh logic ripped out of tau.alpha, so as to have a lower level lib to build a new version of tau (and other things) on top of. Figwheel uses different build IDs for each build, while Shadow uses modules. So, with Calva and Figwheel, I'm able to focus the repl on a particular set of repl clients, using the option "Select CLJS Build Connection." With Shadow I only have the one build, which is defaulting to the main/screen thread:
Is there any way to force Shadow to focus on a given module, with its respective clients, in Calva or otherwise?
And I see the docs reference https://shadow-cljs.github.io/docs/UsersGuide.html#_connecting_calva_to_the_build but not modules