This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2023-01-31
Channels
- # announcements (22)
- # asami (19)
- # aws-lambda (4)
- # babashka (42)
- # beginners (43)
- # calva (28)
- # cider (1)
- # clerk (79)
- # clj-kondo (12)
- # clojure (47)
- # clojure-berlin (1)
- # clojure-brasil (1)
- # clojure-dev (12)
- # clojure-europe (40)
- # clojure-nl (2)
- # clojure-norway (5)
- # clojure-uk (3)
- # clojurescript (56)
- # clr (12)
- # conjure (8)
- # cursive (4)
- # datomic (78)
- # dev-tooling (6)
- # exercism (1)
- # fulcro (9)
- # hoplon (3)
- # jobs (3)
- # jobs-discuss (4)
- # lambdaisland (3)
- # leiningen (1)
- # london-clojurians (1)
- # lsp (125)
- # malli (32)
- # matcher-combinators (3)
- # nrepl (1)
- # off-topic (6)
- # pathom (39)
- # re-frame (13)
- # releases (2)
- # remote-jobs (3)
- # sci (7)
- # shadow-cljs (117)
- # sql (6)
- # squint (7)
- # tools-build (15)
- # tools-deps (12)
Good morning, does anybody know how shadow-cljs figures out which JDK to use? It's pointing to an no longer existing version on my disk and it doesn't seem to be the alias or JAVA_HOME.
it doesn't figure anything. it executes java
, whereever that leads is up to your system
Ah you're right... it must be vscode then.
I guess you can check via node -e "require('which').sync('java')"
in the project dir
Got it, thank you 🙂
I always start VS Code from a terminal where the environment is what I want it to be. Starting apps from the GUI has a tendency to start them in some weird environment.
What does this mean - does it indicate a syntax error, or a missing resource?
[2023-01-31 14:41:59.327 - INFO] :shadow.build.npm/js-invalid-requires - {:resource-name "node_modules/@automerge/automerge-wasm/nodejs/automerge_wasm.js", :requires [{:line 4, :column 37}]}
I'm trying to read this to understand a little better: https://github.com/thheller/wasm-pack-cljs
What I'm trying to do is migrate to the new automerge 2.0 project: https://automerge.org/blog/automerge-2/
maybe if you go through webpack via https://code.thheller.com/blog/shadow-cljs/2020/05/08/how-about-webpack-now.html#option-2-js-provider-external
@thheller Thank you so much for your detailed response! I will take a look at that webpack thing ... is it possible to use it just for one library?
@thheller So if we use the :external
js provider like that, is it still possible somehow to use shadow-cljs for interactive development (like with hot reloading and stuff)? Because if I understand the order of operations correctly, first we invoke shadow-cljs, which generates a js file, which then we feed into webpack, and then we have our index.html
load both files ...
Is the idea that if I don't change the js requirements often, we don't actually have to do the webpack step very often, and we can just sort of use shadow-cljs like normal?
yes, the only part that changes is that you can't dynamically change JS dependencies
Ok. I'm learning this stuff very slowly and I will give it a try. Is there any hope for more seamless support for WASM eventually, or is that really just dependent on the dust settling in the WASM ecosystem?
@thheller I sort of got it working (the build with webpack), but even after getting it to load the wasm and stuff, I seemingly can't resolve anything in the automerge package itself. Any further suggestions for debugging?
I suppose the concrete issues I'm seeing are not being able to use anything from automerge (like calling Automerge/init
doesn't work - it can't find it), but also I think something about the build related to my inclusion of io.github.nextjournal/markdown
didn't work, because I get this error upon loading:
so I suspect you might be loading some outdated files. might be cache, might just be outdated files when you changed filenames or something
No, I get exactly the same issue and error. I'm wondering if maybe some js or something is bundled in the nextjournal markdown project which is then somehow not visible to webpack.
All I am doing in terms of procedure is a shadow-cljs compile of my build, and then npx webpack
(with a suitable config just telling it what to read from and where to write to) ...
Yeah. I am going to try to see if I can make it work with bare cljs, just to have some info from that perspective, with a new barebones project that just pulls in Automerge 2. If I manage to make THAT work, maybe I'll bug you about shadow-cljs.
I'm happy to take a look at a repro that is failing, just need something to look at :P
Thank you very much for that - my company won't let me share what I am doing directly, but maybe I can make a simple repro case.
I'm using shadow-cljs with :js-options :resolve
:
"user-gql-query" {:target :global :global "UserGqlQuery"}
"all-gql-queries" {:target :file
:file "dist/all_gql_queries_bundle.js"}
My all_gql_queries_bundle
is generated from a JS file that does import * as UserGqlQuery "user.gql" window.UserGqlQuery = UserGqlQuery
and uses webpack to "compile" gql files into js files.
my cljs namespace imports both "all-gql-queries"
and "user-gql-query"
when the namespace tries to load, it fails with shadow-cljs - failed to load module$users_gql_queries
Inspecting the browser, I am able to access window.UserGqlQuery
without issues (it returns the value that I expect)
but shadow$provide
returns an empty object. then shadow$provide.module$users_gql_queries
returns undefined.> but be careful with running secondary bundlers, it may lead to duplicated packages
this is just for import .gql
files directly into JS bundle
Tomorrow I will try to access the globals directly. Maybe even add the external script src=
and leave the cljs build way cleaner.
I don't know what .gql
files are, but webpack in the process of bundling them might include npm dependencies
@thheller any thoughts on checking peerDependencies in addition to the other two here? https://github.com/thheller/shadow-cljs/blob/master/src/main/shadow/cljs/devtools/server/npm_deps.clj#L157-L159
I had a project where I included something from src/deps.cljs
in peerDependencies, and found that shadow would try to install it every time.
The problem was that the npm install
call that shadow issued would destroy any npm link
calls I had run, to get npm
to look at local versions of one of the dependencies I was working on
same with devDependencies, right?
@thheller you use npm link
when you have an npm dependency like mathbox
, and you want to develop against local copy of it
I was working a library that declared mathbox as a peerDependency
it means “required but you bring your own version”
it actually DOES install by default
wait, sorry, let me be clear
if I declare a peerDependency in my own project, it is definitely installed.
if someone then depends on me, npm install
actually WILL install my declared peerDependencies; but usually it’s like a JVM “provided” dependency. It means “consumers have to have SOME version of this but I want to force you to declare it on your own”
“npm link” replaces the node_modules
entry of a library with a symlink to a local path. the problem is that shadow-cljs is calling npm install
inappopriately, since its is-installed?
filter is not catching things I have in peerDependencies
; and that npm install
call blows away my npm link
symlinks
say more
then how do I ship libraries like https://mafs.mentat.org/, https://jsxgraph.mentat.org/ etc…
I want it to install dependencies!
I just want it to realize that I’ve already installed stuff in peerDependencies
it’s great, I think it would be a sad experience to have to tell users to manually install the npm deps my libraries are building on, especially multiple levels deep; users shouldn’t be manually resolving dependency trees
I develop, then I ship…
so you during development can skip the automated install entirely, especially if you are doing npm link and whatever
the end user can still install everything normally, without any of your custom things going on?
ah, I see what you’re saying
but doesn't seem like that would totally prevent this from accidentally nuking your custom setups
yeah, you’re right that it would still nuke them the first time, until the deps.cljs
entries had made it into package.json
so this is good to know for sure
but you are a developer of a library, should not be dependent of transfering your OWN npm dependencies out of deps.cljs if you ask me
I even go so far as having an entirely separate package.json file for published packages
> but you are a developer of a library, should not be dependent of transfering your OWN npm dependencies out of deps.cljs if you ask me
I agree but this happens automatically if you include a src/deps.cljs
in your classpath
it comes in via my :deps
dependencies
I’m not sure what problem I solve by excluding it? I basically don’t want to care at all about npm
after declaring the dep, so it actually feels like the right thing to do to get my deps in via deps.cljs
what if I forget to add something new to it, or update a version
I mean I totally trust you that deps.cljs
is causing trouble, you’re the expert here… maybe I’m too used to the status quo to imagine other solutions
in regular CLJS (:require ["clojure.string" :as x])
is valid, which I consider a bug
but I'd assume that the ["mafs" :as m]
is treated as a self-require and would error out?
sorry looking now
@thheller I had asked here a while ago and it sounded like it was supported; `“mafs” here is an npm dependency
@thheller I should probably rename the cljs namespace mafs.core
> but I’d assume that the ["mafs" :as m]
is treated as a self-require and would error out?
I have only tried it with shadow, where it works fine… I should get a proper vanilla build going
yeah, you’re probably right. I should change it and folks can always alias