Fork me on GitHub
#shadow-cljs
<
2018-11-20
>
richiardiandrea18:11:57

Hi all, hi Thomas! I am looking into https://github.com/thheller/shadow-cljs/issues/407 and would like to ask how to apply :exclusions to the shadow dependency if I am using it through package.json. I tried a couple of things to no avail

thheller18:11:06

I thought you were using deps.edn?

thheller18:11:21

can't apply exclusions to shadow-cljs itself in shadow-cljs.edn

richiardiandrea18:11:28

well I am using deps.edn but not for shadow, cause the automatic detection of server mode is not working unless I have it in package.json. Am I right?

thheller20:11:01

@richiardiandrea no that has nothing to do with it. it just looks for .shadow-cljs/http.port file which is written when the server is started

richiardiandrea17:11:10

is this configurable? If so in a monorepo I could start yarn shadow-cljs server from the parent and all the child projects could connect to it

richiardiandrea17:11:14

@U05224H0W yes I do not care in CI but I could potentially care and shed off 3 seconds per sub project 😄

thheller17:11:55

the time you spent thinking about ways to get rid of 3sec startup time already accounts for about 1000 project starts

thheller17:11:13

and no you cannot share a server instance between projects. they are isolated on purpose

richiardiandrea17:11:11

Ah ah I wish it was like you said, also this shaving off is way more important for my team than my time spent thinking about it apparently. That's why I am trying hard to improve things 😄

thheller18:11:46

so what is the workflow of your team?

thheller18:11:00

do they run a shadow-cljs server at the start of the day and leave that running?

thheller18:11:41

that is pretty much the only thing that matter

richiardiandrea18:11:54

No they cd into the lamdba project and start a watch

thheller18:11:56

IF that is running in the project you have zero startup time for any other command

thheller18:11:07

ok that starts a server instance as well

thheller18:11:29

and its a problem that this takes 5sec or so?

thheller18:11:37

when done once a day?

richiardiandrea18:11:59

Give me a sec will be back

richiardiandrea18:11:12

so they start a server instance in the project of the lambda they want to work on

richiardiandrea18:11:31

and the following commands are correctly avoiding startup time

richiardiandrea18:11:56

but sometimes you want to run commands in two lambdas, now you need two JVMs

thheller18:11:06

well you can always combine the projects and just have one project for many lambdas

thheller18:11:11

that would take care of that

richiardiandrea18:11:44

my boss does not want to do that, he says that the tool should be smarter 😄

thheller18:11:56

:source-paths ["lambda1/src/main" "lambda2/src/main"] and just create a combined config

richiardiandrea18:11:42

Yeah I can do that. Would you be open to adding some sort of magic that helps with this kind of setup (monorepo) so that the merge is done automatically?

thheller18:11:01

the problem is :dependencies

thheller18:11:07

those can't be merged easily

thheller18:11:24

otherwise I would have done this ages ago

thheller18:11:39

but clojure can't load 2 versions of the same dependency

richiardiandrea18:11:38

Yep but in a monorepo is in general what you want, so you can just error out (like you already do for transitive node_modules...nice touch btw)

thheller18:11:41

merging build configs is easy enough

richiardiandrea18:11:01

I am actually manually keeping Clojure deps.edn in sync making sure I have the same version everywhere

richiardiandrea18:11:08

it's painful 😄

richiardiandrea18:11:40

something that does this for me would be awesome...now - this probably would be better in a separate lib

richiardiandrea18:11:06

but shadow-cljs could wrap the lib and provide a fully fledged solution for monorepos

thheller18:11:00

I don't think shadow-cljs needs to do anything

thheller18:11:10

isn't the point of the monorepo to keep everything in one repo?

thheller18:11:33

if everything is already in one repo and we already have namespaces to separate everything ...

thheller18:11:36

why split it further?

thheller18:11:48

or why not keep the shadow-cljs config one level up?

thheller18:11:10

repo/lamba1/shadow-cljs.edn + repo/lamba2/shadow-cljs.edn OR repo/shadow-cljs.edn

thheller18:11:21

leave the sources where they are .. doesn't really matter

thheller18:11:53

just add :source-paths ["lambda1/src" ...] and in the builds just use :app-dir "lambda1/output"` or whatever

thheller18:11:20

what is the point of separating everything if combining it is actually what you want?

thheller18:11:31

it doesn't even make sense to do this in JS ...

thheller18:11:49

just write a shell script that takes the nested shadow-cljs.edn files .. extracts the builds and rewrites the paths

thheller18:11:06

FWIW if you can create a "demo" monorepo that demonstrates your setup I can maybe think of something to do

thheller18:11:27

but right now it just feels like you are shooting yourself in the foot for "reasons"

richiardiandrea19:11:17

yeah sometimes you have to take decisions you don't agree with...but thanks for trying to find solutions.

thheller20:11:03

doesn't matter how

thheller20:11:48

but I thought you didn't care about server-mode in CI anyways

richiardiandrea20:11:52

well there was a reason we discussed and we ended up deciding not to use deps.edn....if there is no reason I can think about moving 😉

thheller20:11:45

but anyways the SERVER can be started any way you like

thheller20:11:59

you only need the shadow-cljs npm package to actually talk to it

thheller20:11:35

so clj -m shadow.cljs.devtools.cli release your-build is totally fine for CI

thheller20:11:59

as well as clj -m shadow.cljs.devtools.cli server to start the dev server

thheller20:11:28

still don't actually recommend using deps.edn but if you want to tweak stuff for CI thats your best option currently

thheller20:11:40

(apart from actually just enabling caching)

richiardiandrea20:11:15

ok that's cool I can tweak that then - thanks for clarifying