Fork me on GitHub
#shadow-cljs
<
2024-02-15
>
agorgl10:02:54

Quick question: I'm making a fullstack project (pedestal + reframe) and so far I've been using the same repl that npx shadow-cljs watch app spawns to run my clj stuff (in a different nrepl session than the piggybacked cljs one). Where does this repl picks its deps / source paths from? If I want to add an additional source path, should I switch to moving all my deps in an alias in deps.edn and use it with :deps [:cljs] in shadow-cljs, or I can somehow define further (:dev) aliases to be used from deps.edn in shadow-cljs.edn?

thheller11:02:20

it entirely depends on your preference what you do. everything in deps.edn, clj in deps.edn, cljs in shadow-cljs.edn, all works

agorgl11:02:34

(i have already read this section of the guide, I'm just asking if this is the only way)

agorgl11:02:03

So for starters where does the repl of shadow-cljs pick its classpath and source paths from?

thheller11:02:10

if you want ONE repl that handles CLJ and CLJS I recommend moving everything to deps.edn

1
thheller11:02:23

that depends on which choice you have made

thheller11:02:32

if you set :deps true it takes them from deps.edn

thheller11:02:41

if you set :lein true it takes them from project.clj

thheller11:02:49

if none of those it takes them from shadow-cljs.edn

agorgl11:02:44

Yeah I've already moved my deps / paths to deps.edn

agorgl11:02:16

So my last question is, with :deps [:alias-1 :alias-2] in shadow-cljs.edn you can use multiple source paths from multiple aliases

agorgl11:02:33

Is there a way to do this without moving dependencies and source paths to deps.edn?

thheller11:02:01

I do not understand that question

agorgl11:02:11

yeah sorry, its kinda confusing

thheller11:02:27

with :deps set, :source-paths and :dependencies in shadow-cljs.edn are not used and can be removed

agorgl11:02:39

lets say I have a shadow-cljs.edn with :source-paths and :dependencies inside

agorgl11:02:02

is there a key to use additional :source-paths from a deps.edn alias

agorgl11:02:09

or I should migrate to :deps key

agorgl11:02:15

ok that answers all of it

thheller11:02:23

since it only launches one JVM it can only be defined in one place

agorgl11:02:23

Thanks for the clarification!

agorgl11:02:41

Yeah seems reasonable

agorgl11:02:25

I'll just keep using the :deps [:cljs :dev] key in my shadow-cljs then

agorgl11:02:14

Another minor cross check: I suppose when defining the :deps vector in shadow-cljs.edn it also uses the default deps and paths from the root of the deps.edn right?

thheller11:02:17

:deps {:aliases [:cljs :dev]} that would be 😉

😃 1
thheller11:02:41

all this does is control how shadow-cljs launches a JVM

thheller11:02:13

so with deps it will call exactly clj -A:cljs:dev -M -m shadow.cljs.devtools.cli watch app if you do npx shadow-cljs watch app

agorgl11:02:28

crystal clear

thheller11:02:47

the rest is then completely up to clj 🙂

cap10morgan17:02:38

I'm curious why Node targets in shadow-cljs default to advanced optimizations. This page: https://clojurescript.org/guides/quick-start#running-clojurescript-on-node.js ...says: "Note: Under Node.js there is little reason to use advanced optimizations. ... For Node.js, simple or none optimizations suffice."

thheller17:02:37

because I think that :advanced is still very useful. you are free to set it to :simple, but I disagree with that statement

cap10morgan18:02:53

OK simple enough! 👍

cap10morgan19:02:16

have you documented what you find useful w/ node + advanced? no need to elaborate here if you haven't. just curious if I can go educate myself on my own time somewhere.

thheller19:02:36

same reasons why you want :advanced in the browser really

thheller19:02:58

much smaller code, lots of other code optimizations

thheller19:02:47

still relevant in node, just not as important as in the browser

thheller20:02:46

https://www.npmjs.com/package/shadow-cljs the package is 237 kB, with :simple it'll be considerably larger

thheller20:02:49

important no, but still worth optimizing

cap10morgan20:02:01

makes sense. thanks!

cap10morgan20:02:56

Any reason the :target :esm :modules {:name {:exports ...}} construct couldn't support :exports-var instead like the :node-library target? I'm building both from the same codebase and it would be great if I could point both of those at the same var w/ my exports. May have to deal w/ keywords vs. symbol keys, I guess.

thheller20:02:16

in CommonJS module.exports = some.ns.foo; is valid, while ESM export some.ns.foo is not

thheller20:02:14

there is no equivalent to "exports everything from this object"

cap10morgan20:02:01

hmm... not sure I follow the implications there fully. I have the same data structure repeated in two different places mapping keywords to fully-qualified vars in one place and unqualified symbols to the same fully-qualified vars in the other. would like to DRY that up if possible. but it sounds like it's complicated so happy to leave it at that if so.

thheller20:02:38

its not complicated, it is impossible. ESM just cannot do that

thheller20:02:15

I assume you are talking about (def these-are-my-exports #js {:foo "whatever"})

cap10morgan20:02:56

seems odd that it would be impossible since it's basically the same data structure in both places. just symbol keys in one and keywords in the other.

thheller21:02:20

that is exactly what I mean

thheller21:02:56

this is not currently possible and would require changing the CLJS compiler

thheller21:02:32

as I cannot get that vars value from the analyzer data

thheller21:02:00

for :node-library it literally just emits module.exports = fluree.crypto.js_exports;

thheller21:02:17

but as I said there is no equivalent thing for ESM exports

cap10morgan21:02:28

makes sense now thanks 👍