been watching it... just ditched boot from our toolchain and switched our cljs build over to shadow-cljs. i think moving the lein stuff over to deps.edn might be next

what was boot not providing you that you needed?

@U052SB76M we were only using boot for cljs builds (with less, dev http server etc) , and the shadow-cljs boot integration didn't look great, so we dropped boot and went with gulp for driving shadow-cljs

turns out gulp is awesome - i'd love to be able to define gulp tasks in cljs with lumo or something

I think we could probably use the node interop stuff like when you do cljs serverless builds on top of the underlying framework

yeah, probably... gulp tasks are just vanilla fns quite like ring handlers, so we could probably use gulp as a lib from a lumo script

zactly

As newbie, I tried both, but fell in with the deps.edn crowd and loving it 🙂

Took inspiration from juxt/edge and sean corfield dot repo

most side-projects only use deps.edn now

feels so much lighter than lein somehow

and love that I can use local dirs and git repos as an alternative to maven

the local dirs is a big win imo

Being able to use code straight from any git repository and specific commit would hopefully kill off any idea people have about creating mono-repos

Before you know it you're writing monorepos of tools to manage your monorepos.

cough https://github.com/lerna/lerna cough 😬

The heat death of the universe jumps a lot closer every time someone creates a mono-repo

We should write a satire program that manages infinite nested stacks of monomonomono...monomonorepos. Selling point is that you can put all of GitHub in that repo, then put all of GitHub, bitbucket and GitLab beside each other another level up.

Although I don't think that snark would go down very well with many people 😅

It might not go down very well with certain JavaScript focused devs... it does seem to be they who love the mono-repo... I think everyone else would love it 🙂

I wonder where that stems from, I guess the culture of breaking every single thing into it's own independent module. left-pad, I'm looking at you.

Yes, and I wonder how many people remember that pain... of if they have just buried their pain... in more mono-repos :rolling_on_the_floor_laughing:😂

as a JS dev I rather have all the stuff in a monorepo :P

i'm not a JS dev, but give me a sweet sweet monorepo every time

I spent way too much time opening n+1 PRs on different repos for the same feature, then cascading releases in CI, merging a few more PRs, releasing a few more things, etc. And in the end, I missed at least one dependency.

different requirements I guess ¯\(ツ)/¯

All of my work happens in one repo

all of mine too ;)

Haha!

I guess you could have a single project and a few build targets, and that's the same thing, you just offload that work to a different tool

but most of the JS build tools deal with a single target, so you need to have things like lerna

you could also have multiple "main" files and a "makefile" for each

Some of the issues around mono-repos are well define as there is a long history of this approach https://en.m.wikipedia.org/wiki/Monorepo

All the monorepos I have experienced over the years have been terrible to use. Maybe people are being more responsible in the way they are using them now, bit I have never had the pleasure to see this.

I figure that if those companies use monorepos for their huge codebases, then monorepos can't be all that bad 🙂

The arguments against monorepos have never come across as strong to me. I have made extensive research on the topic in order to justify the Edge design. Nothing was particularly convincing. Most of the points made are often true whether you use non-mono or mono repos.

@U09LZR36F is edge designed to contain multiple different projects? For example if my company builds 10 different Clojure projects from various areas of the business they will all be from the one Edge repository?

@jr0cket They can be. I think a monorepo should serve a purpose though. If there are hard social/technical boundaries in your company e.g. you'd never know they were using clojure, then there's reduced purpose in a monorepo. If it's overlapping teams, with overlapping communications, then the monorepo is more valuable.

At JUXT we tend to end up with an Edge repo per major client project.

Thanks for sharing. Yes a repo per major project makes sense, especially in a consultancy situation. That is not really the monorepo as I have experienced them though, as they have had all the major projects in there 🙂

we're a product company with one app - each component of that app gets a module in a monorepo - life is much easier than when we had a repo per component

There is definitely different levels of scale when people talk about monorepos. If you had 10 different apps in the one repository, that would make me cry and need a lot of hugs 🙂

monorepo per product is v different from company-wide monorepo

yes, I suspect the term has been used to mean different things in the discussion we have had. The wikipedia article does define a monorepo as more of a company wide repo, or major area of business in large enough corps. On that scale I have always found it difficult to get anything done and seen huge amounts of duplication, but I think that is as much the culture as the tooling.

I tend to hear it used as a per-project thing e.g. for microservices - each service in a separate repo or all services in a ‘monorepo’

Our monorepo has our OAuth2 server, our public API server, our Login server, and Billing apps and Chat apps and a few other bits and pieces. Essentially it's all our Clojure code. Our legacy CFML code lives in a separate repo (which had three apps, now only two).

it's also worth considering the company scale in that too. In smaller companies, I suspect a company-wide repo is fine, it will probably encourage code-sharing & common libs between you. In those situations it seems fine. Smaller is left intentionally ambiguous here, because I'm not sure where the threshold is. Eventually you would probably stabilize the common lib api and split it out into it's own repo & lifecycle. I definitely see monorepos as a bell-curve. Early days = monorepo, mid-size = multi-repo, max-size (google/twitter) = monorepo

a lot of teams/business areas at the old place had monorepos and … the experience was mixed

depends on your discipline within that repo on keeping things sensible and decoupled

I imagine this is the old peopleware curse: we blame technology, when the problems are sociological!

it's the same as microservices vs monoliths. It's mostly down to team discipline rather than some inherent advancement.

yes

the most disciplined teams tend to deliver better software more often, regardless of context

seen that in big teams and small, big companies and small now

I snuck it in almost accidentally one time when I needed a clojure scratchpad with dependencies. Put a deps.edn in a folder with {:deps {cheshire {:mvn/version "5.8.0"}}} to pull in cheshire and cider-jacked-in and everything seemed to work.

ah, now that is something I'm glad to hear (as part of it for me has been understanding if I'd need to do anything to CIDER)

minimal

Thx!