Monorepos: Please don’t

#1

Post by louis-paul » Wed, Jan 02, 2019, 6:57 PM UTC

Re: Monorepos: Please don’t

#2

Post by superasn » Wed, Jan 02, 2019, 7:52 PM UTC

The biggest advantages monorepos have offered is development of tools like lerna(1) or yarn workspaces.

Before that there used to be a node_modules folder with GBs of [useless] data in all my projects. Now there is just one folder on top and that's it. Also if you're developing lots of modules or plugins it makes it super to work without committing changes since they are symlinked.

(1) https://lernajs.io

Re: Monorepos: Please don’t

#3

Post by erik_seaberg » Wed, Jan 02, 2019, 8:12 PM UTC

I wish this had touched on polyrepos' ability to pin known-good versions of dependencies; that tends to be the Achilles' heel of monorepos.

Re: Monorepos: Please don’t

#4

Post by muro » Wed, Jan 02, 2019, 8:33 PM UTC

erik_seaberg wrote: post #3

I wish this had touched on polyrepos' ability to pin known-good versions of dependencies; that tends to be the Achilles' heel of monorepos.

Yet who unpins them or updates when a new good version is available?

Re: Monorepos: Please don’t

#5

Post by pbiggar » Wed, Jan 02, 2019, 8:33 PM UTC

Alternate title: monorepos - ideal for teams under 100 devs

Re: Monorepos: Please don’t

#6

Post by erik_seaberg » Wed, Jan 02, 2019, 8:38 PM UTC

muro wrote: post #4

erik_seaberg wrote: post #3

I wish this had touched on polyrepos' ability to pin known-good versions of dependencies; that tends to be the Achilles' heel of monorepos.

Yet who unpins them or updates when a new good version is available?

There's a cost for being out of date, but there's also a cost for learning the hard way whether a new version breaks prod. Pay it down like any other tech debt.

Maybe I could test literally every release version of each of my dependencies, but that isn't really my job.

Re: Monorepos: Please don’t

#7

Post by sterlind » Wed, Jan 02, 2019, 8:41 PM UTC

Could you get the best of both worlds by having a monorepo of submodules? Code would live in separate repos, but references would be declared in the monorepo. Checkins and rollbacks to the monorepo would trigger CI.

Re: Monorepos: Please don’t

#8

Post by nomel » Wed, Jan 02, 2019, 8:49 PM UTC

pbiggar wrote: post #5

Alternate title: monorepos - ideal for teams under 100 devs

The title should have been "Monorepos: Please don't, at scale", but I suspect it was made intentionally controversial.

Re: Monorepos: Please don’t

#9

Post by towaway1138 » Wed, Jan 02, 2019, 9:04 PM UTC

My polyrepo cautionary tale: Two repos, one for fooclient, one for fooserver, talking to each other over protocol. Fooserver can do scary dangerous permanent things to company server instances, of which there are thousands.

Fooserver sprouts a query syntax ("just do this for test servers A and B"), pushed to production. Fooclient sprouts code that relies on this, pushed to production. A bit later, Fooserver is rolled back, blowing away query syntax, pushed to production. "Just do this for test servers A and B" now becomes "Do this for every server in the company". Hilarity ensues.

Re: Monorepos: Please don’t

#10

Post by joeblau » Wed, Jan 02, 2019, 9:08 PM UTC

pbiggar wrote: post #5

Alternate title: monorepos - ideal for teams under 100 devs

At Uber, both of our iOS and Android teams are over 100 contributors each and we have a Monorepo for each app platform. I'm not on the ops team but being in a Monorepo here has been one of the best development experiences in my career.