Fork me on GitHub
#shadow-cljs
<
2021-11-15
>
pez11:11:27

If I use [:js-options :js-package-dirs to tell shadow about an npm module that a sub project (a :local/root deps.edn dependency) needs. Do I risk to be using the wrong version of some subdependency that my main project and the subproject both bring in?

thheller17:11:50

kind of yes

pez17:11:46

I am using yarn to initialize node_modules in all projects. Does that make a difference? Or rather, I should ask what makes this risky.

thheller18:11:41

say your main project uses dependency B which also uses X v1

thheller18:11:00

then you have the sub project using dependency C which uses X v2

thheller18:11:14

but since js-package-dirs resolves in order it'll get v1

thheller18:11:23

which may blow up

thheller18:11:16

but why not have the sub project declare its :npm-deps and manage them in the main project as well

thheller18:11:26

that at least makes the dependency conflicts visible

pez18:11:05

Yes, sound safest! Will that work with yarn as well?

pez09:11:21

> that at least makes the dependency conflicts visible Meaning, that I might still end up with my subproject using X v1?

thheller18:11:46

depends on how yarn resolves or handles the conflicts

thheller18:11:23

gonna have to ask yarn. shadow-cljs is only interested in what it finds in node_modules. it does not care how it got there

thheller18:11:17

don't overthink it too much though. worst case either means your build breaks immediately or you end up including two version of the same dependency

thheller18:11:55

the break you'll notice and the duplicates you can identify via build reports

pez13:11:11

Thanks so much for all this info, @thheller! It looks like we’re going with :npm-deps now. I notice that it just works with yarn. Is this something shadow-cljs does or is it the clojurescript compiler that does it? I wonder if I need to somehow make sure it is my yarn.lock file that is updated…

thheller18:11:13

shadow-cljs will call yarn add <npm-dep>@<version> for declared :npm-deps if they are not already in package.json if a yarn.lock file is found

thheller18:11:28

otherwise it'll run npm install

pez18:11:59

Awesome. Thanks again!

roman01la16:11:55

@thheller is there a way to get deps graph from shadow build? I’ve seen some references to /api/graph endpoint in shadow’s server code, but couldn’t figure out if it’s something that actually works

thheller17:11:09

@roman01la define deps graph? /api/graph is for EQL graph queries but its not used much. what specifically are you looking for and at which point? you could easily extract it from the build state via a build hook for example

roman01la08:11:31

I see. I’m interested in getting dependency graph including application code, cljs deps and npm deps. For build hook: at which build stage the graph is available in the build state?

thheller18:11:16

I still don't know what you mean by "dependency graph". there is no graph of such kind. the information to construct it is there but shadow-cljs itself maintains no such graph.

thheller18:11:57

:compile-start and everything after has all the info

thheller18:11:14

in the build state you'll find a :build-sources vector. those are resource-ids sorted in dependency order

thheller18:11:24

each id you can find in the :sources map

thheller18:11:03

there each will have a :provides set or namespace symbols and a :deps vector

thheller18:11:49

:provides is a set since closure lib sources can provide multiple things per file

thheller18:11:01

for CLJS sources its just #{that.ns}

thheller18:11:44

you can use

:build-hooks
   [(shadow.build/tap-hook)]
in your build config

thheller18:11:04

it'll just tap> the build state on :flush so you can inspect it via the UI

thheller18:11:24

there are other ways to get all this data so I don't know if a build hook is the best choice for whatever you intend to do

roman01la09:11:16

I’ll give it a try, thanks! 🙏