►
Description
For more Continuous Delivery Foundation content, check out our blog: https://cd.foundation/blog/
Keynote: Why Monorepos - Jeff Cross, Co-Founder & Principal Architect, Nrwl
JW Grand Ballroom 7 - 8
Speakers: Jeff Cross
Monorepos have been getting a lot of attention recently in the JavaScript community. Is it just hype, or can monorepos fundamentally change how a software organization works? In this talk, Jeff will explore the tooling, nuance, and tradeoffs of monorepos vs other approaches, using resources from the informational site https://monorepo.tools.
A
Into
it,
I'm
going
to
talk
about
monorepos
today,
which
I'm
excited
has
gotten
more
awareness
lately
in
the
javascript
community
in
particular,
and
we
actually,
my
company
narwhal,
we
have
a
resource
called
monterey,
put
up
tools.
I'd
encourage
you
to
check
that
out,
because
we
actually
work
on
that
with
people
from
other
teams.
A
Other
companies
who
work
on
model
repo
tools,
monterey
book
tooling,
to
make
it
as
an
objective
of
a
resource
as
possible
about
why
monterey
opposed
the
philosophies,
other
approaches
and
the
tools
you
can
use
to
work
with
mono
repos,
and
I'm
going
to
talk
today
about
what
mono
repos
are
kind
of
how
we
got
here
and
how
you
might
think
about
using
them
so
again
shameless
plug
for
for
this
site,
and
unfortunately
I
don't.
I
didn't
remember-
to
include
pig
picks
in
this
presentation.
A
A
Where
an
organization
would
have
one
trunk
that
has
all
related
software
in
in
a
single
code
repository
anything
that
was
shared
or
used,
you
would
have
many
distinct
projects
and
they
they
would
be
in
a
single
trunk.
A
lot
of
times
managed
with
svn
was
kind
of
the
dominant
one
did.
Has
anyone
used
svn
here
trying
to
I'm
just
seeing
how
old
the
crowd
is,
but
yeah
so
svn
svn
was
great.
It
was,
I
mean
there
are
other
version.
Control
systems
there
still
are,
svn
is
still
used
or
other
ones
still
in
use.
A
That
was
the
dominant
player
then,
and
in
in
those
cases
svn
it
didn't
do
a
lot
to.
It
really
was
just
about
version
control.
It
didn't
do
much
to
help.
You
structure
your
repository
or
to
organize
things
in
a
certain
way.
It
was
very
most
teams
used
in
a
very
centralized
way
and
and
even
where,
when
you're
committing
you're
committing
directly
to
some
central
source
and
you're
pulling
from
that.
A
So
it's
a
lot
different
from
how
software's
developed
today,
but
by
the
way
software
was
developed
because
it
was
these
these
large
trunks,
with
many
related
projects
in
a
single
code
base.
There
were
some
problems
that
teams
struggled
with
like
the
boundaries
between
code
inside
those
repositories
was
not
very
well
managed.
A
You
kind
of
came
up
with
a
folder
structure
and
there
was
some
tribal
knowledge
of
who
owned
what
and-
and
that
was
about
all
you
had
and
as
the
repositories
grew,
if
you
added
any
kind
of
continuous
automation,
continuous
integration,
your
tests
and
builds
would
get
slower
as
the
code
base
grew
and
lack
of
ownership
of
different
parts
leads
to
dysfunctional
teams
who,
who
kind
of
do
things
in
different
ways
in
the
repository
there's?
No
consistency,
there's
poor
communication,
and
that
is
kind
of
the
impetus
for
why
teams
started
to
do
things
differently.
A
But
there
are
actually
three
three
things
that
happened
in
the
the
space
that
also
accelerated
a
different
way
of
developing
software.
The
first
one
was
the
rising
popularity
of
continuous
integration
so
having
automation
in
in
your
environment,
so
that
you're
not
doing
tests
locally
testing
was
also
growing.
A
The
second
thing
that
happened
was
git
and
github,
so
get
introduced
a
more
lightweight
way
to
manage
version,
control
or
source
code
control.
Where
you
don't
have
to
commit
remotely
every
time
you
can
do
local,
forks,
local
branches.
Do
your
commits
clean
up
things?
Then
push
them
integrate
lots
more
powerful
ways
of
rebasing
and
interacting,
and
along
with
that,
github
was
developed.
So
so
there's
this
new
way
of
managing
source
code
and
the
service
to
go
with
it.
That
makes
it
easy
to
create
many
repositories.
A
Many
lightweight
repositories
easily
and
the
third
thing
that
happened,
particularly
in
the
javascript
community
and
outside
javascript
community
package
managers,
have
also
gotten
more
popular
but
npm
and
semver.
So
having
a
first
class
package
manager,
there
was
originally
just
node
but
then
became
the
standard
for
the
web
as
well.
Having
that
to
where
you
could.
Actually,
you
could
have
many
repos
and
publish
them
to
their
own
packages,
and
there
was
a
versioning
scheme
to
where
you
could.
A
You
could
actually
publish
these
and
version
them
and
say:
okay,
I
can
set
my
my
constraints.
Constraints
to
say
depend
on
stable
versions
depend
on
like
I
can
do
patch
updates
with
without
needing
to
explicitly
update
it.
So
these
things
made
it
where
it
became
a
lot
easier
for
teams
to
separate
their
repositories
out
into
into
separate
repositories
and
the
I
call
this
poly
repos.
I
have.
A
A
So
so
those
things
led
to
led
to
that
big
shift
in
poly
repose
to
where,
instead
of
having
a
single
truck
trunk,
that
has
a
bunch
of
somewhat
loosely
defined
pieces
of
a
project
together,
you
would
have
these
more
concretely
defined
repositories
that
had
relationships
based
on
dependencies.
It
could
look
something
like
this,
but
another
thing
that
changed
in
addition
to,
and
so-
and
this
was
nice,
so
it
enabled
more
team
autonomy.
A
team
has
a
repository.
They
tend
to
stick
with
that
repository.
They
know
everything
that's
going
on
there.
A
They
can
set
up
their
own
testing,
their
own
ci,
their
own
docs,
their
own
publishing,
whatever
they
want.
They
can
do
it
there,
but
it
came
at
some
costs,
so
one
of
them
was
that
in
reality,
instead
of
where
originally
with
trunk
based
development
or
if
we
just
had
poly
repos,
where
you
would
be,
depending
on
source
of
your
code
and
depending
on
head
all
the
time
and
have
somewhat
evergreen
repositories
now
repositories
depend
on
version
snapshots
of
other
code,
and
because
of
that,
you
would
have
late
integration
of
changes.
A
So
an
app
that's,
depending
on
a
shared
library,
is
going
to
integrate
those
changes
when
the
app
decides
to
which
could
be
six
months
from
the
time
a
change
was
made
and
which
leads
to
problems
of
like
you
don't
validate
changes
as
quickly
you,
you
are
less
likely
to
make
changes
in
that
shared
repository.
If
you're
on
that
app
team,
because
you
know
it
might
be
six
months
before
you
get
that
change.
If
your
tech
lead
isn't
going
to
update
it
so
it
so.
It
leads
to
this
late.
A
Integration
there's
also
a
high
setup
overhead
per
repo,
so
the
autonomy
is
great,
but
you
have
to
set
up
your
own
ci.
You
have
to
set
up
your
own
publishing.
You
have
to
set
up
your
own
documentation
and
if
you've
got
an
organization
that
wants
consistency,
then
you
have
to
have
follow
some
standards
to
do
this
across
different
teams,
and
it's
also
difficult
for
developers
to
contribute
outside
the
repo
and
because
you
don't
know
the
tooling
of
the
other
repository
unless
there
is
some
strict
standard
and
the
overall
complexity
increases
because
of
versioning.
A
So
because
you
have
shared
libraries
that
can
publish
in
different
versions-
and
you
may
have
a
transitive
dependency
depends
on
different
versions
of
that
library.
You
have
to
figure
out
how
to
avoid
issues
that
can
come
with
having
two
transitive
dependencies
of
two
different
versions
of
a
package
which
leads
teams
to
creating
fewer
of
these
shared
libraries.
To
avoid
that
complexity,
so
you
have
still
a
bunch
of
small
monoliths.
A
Oops
went
the
wrong
direction,
so
some
of
the
outcomes
of
this
were
that
you
have
significant
duplication
of
code,
because
there's
overhead
to
creating
shared
repositories,
overhead,
to
contributing
to
other
repositories
and
effort
to
integrate
from
other
repositories,
teams
tend
to
just
write
the
code.
Again,
if
you
have
a
common
component,
you
might
just
say:
okay,
I've
got
to
meet
deadlines.
A
It
also
introduces
inconsistency
of
ui
across
teams,
because
every
time
it's
implemented
a
little
bit
differently,
even
if
there's
a
good
design,
spec
and
naturally,
teams
become
more
siloed
if
they're
operating
most
of
the
time
in
a
repository,
that's
cut
off
from
everyone
else
so
recently,
because
of
this
we've
seen
a
few
things
have
happened
to
to
shift
back
to
looking
at
modern,
repose
or
like
somali
pose
is
a
key
word.
I
would
say,
to
put
it
a
different
way:
more
structured
repositories,
so
consolidating
more
work
and
more
structured
for
repositories.
A
So
teams
are
wanting
more
cross
collaboration
across
teams
more
like.
Let's
do
do
this
component
once
let's
do
these
services
one
place,
so
we
have
to
maintain
it
one
place.
We
create
it
in
one
place
and
we've
got
the
consistency
that
that
our
customers
can
enjoy
and
product
owners
want
the
more
consistency.
A
A
We
didn't
set
out
to
make
a
monorepo
tool,
but
I
came
from
google,
which
has
a
big
model
repo
and
when
we
left
google
and
saw
how
people
were
developing
software
and
wanted
these
things.
My
my
partner
victor-
and
I
we
we
said
okay
like
we
need
to
make
something
where
we
can
enable
these
teams
to
have
better
workflows
around
monorepos
and
that's
how
nx
came
about.
There
are
some
other
great
tools.
A
Lorna
we
actually
just
took
over
stewardship
of
which
has
has
been
another
big
tool
in
the
mod
in
the
javascript
space,
for
a
different
kind
of
philosophy
of
monterey
pose
it
still
kind
of
has
this
polyurethane
mindset
of
several
packages,
but
you
can
co-locate
them
together
and
actually
learn
an
nx
collaborate
or
work
together,
pretty
well
and
there's
another
new
entrant,
turbo
repo,
that's
focused
on
performance
optimizations
like
caching
and
bazel,
is
a
google's
tool.
That's
very
mature.
A
It's
also
a
lot
of
like
we
love
bazel
nx
is
actually
inspired
heavily
by
bazel
it's,
but
it's
a
lot.
It
requires
a
lot
of
knowledge
to
set
it
up
properly,
but
it
is
very
powerful
and
very
mature,
especially
for
java
c
plus
python,
anything
that
google
develops
with
there's
great
support
for
in
bazel
nx.
So
in
particular
we
solve
these
challenges
that
you
need
to
solve.
If
you're
going
to
move
more
teams
and
more
code
into
a
same
repository,
it
needs
to
be
fast.
A
So
so
you
we
have
things
in
nx
that
inside
your
your
repository,
one
of
the
things
that
drove
people
from
a
trunk
based
development
to
poly
repos
is
test
and
automation.
Timing
we
have
with
bazel
and
x
and
and
a
couple
of
other,
monitor
tools.
Now
you
can
have
your
projects
organized
and
have
clear
boundaries.
Clear
encapsulation
of
projects
within
a
monorepo
and
tools
can
actually
see.
A
To
say,
I
want
to
be
able
to
create
a
project
that
that
someone
else
can't
depend
on
unless
I
want
them
to
so
that
I'm
not
having
to
support
a
public
api
that
I
didn't
want
to.
I
can
still
have
this
autonomy
in
my
team
to
experiment
and
to
do
things
in
isolation
but
easily
contribute
across
other
pieces
of
my
code
base.
A
I'm
going
to
go
through
a
couple
of
examples
to
show
kind
of
what
that
looks
like
in
practice
and
again.
This
is
not
tool
specific
to
nx,
but
is
about
monterey,
pose
in
general
and
how
the
experience
changes.
So,
let's
say
we
have
a
design
language,
so
narwhal
we've
defined
a
design
language.
It's
got
blue
in
it
because
we're
ocean
themed,
of
course,
and
we've
got
this
button.
It's
got
a
border
if
we
had
two
repositories
and
two
teams
who've
decided
to
implement
this
themselves.
A
You
may
end
up
with
something
like
this
and
you
know
buttons
are
a
little
bit
easier
to
get
right,
but
with
any
design
system.
If
it's
specified
but
implemented
many
places.
You
inevitably
end
up
with
this
kind
of
ux
inconsistency,
and
why
is
that?
Because
they
live
in
their
own
repository.
The
design
spec
left
some
room
for
interpretation.
A
It
would
take
too
much
work
to
create
a
common
button
repository.
Maybe
no
one's
championed,
setting
up
a
design
system
team
with
its
own
repository
or
all
the
organizational
overhead
to
do
that.
I'd
have
to
do
all
these
things,
to
set
up
a
separate
library
and
then
there's
an
offer,
awkward
life
cycle
of
me,
making
this
change
in
the
design
system
and
then
incorporating
it
into
my
app.
It's
a
lot
easier.
I've
got
deadlines
to
meet.
A
A
But
if
the
team
had
a
monorepo,
it
might
have
something
like
this:
where
they
have
multiple
apps.
All
they
have
to
do
is
create
a
separate
project
in
their
monterey,
poke,
called
common
components
or
even
the
project
for
the
button
itself,
and
it
uses
the
same
ci
there's
an
obvious
place
for
it
to
go
and
when
the
button
needs
to
change.
I
just
agree
with
every
with
someone
else
on
how
it
needs
to
change,
and
that's
that's
what
I
call
a
good
tension
that
you
you
want.
A
Some
things
to
have
some
friction
you
want
to.
You
want
to
be
forced
to
be
thoughtful
about
things
instead
of
having
too
much
independence.
Sorry,
this
slide
got
moved
out
of
place.
Let's
look
at
another
example.
So,
and
if,
if
anyone
uses
angular
you'll
know,
these
versions
are
pretty
old
from
this
graphic.
A
But
let's
say
we
have
two
separate
apps
with
separate
who
depend
on
separate
versions
of
angular,
so
they
they're
built
in
isolation.
They
depend
on
just
slightly
different
versions
of
angular,
but
when
we
have
a
common
common
library,
that
is
hard
is
bound
to
a
specific
version
of
angular.
It
can't
work
with
the
home
page,
app
or,
but
it
can
work
with
the
customers
app.
A
So
and
that's
in
addition
to
the
performance
downsides
of
having
a
larger
bundle.
So
so
this
is.
This
is
an
issue
so
again,
poly
repos
make
it
easy
to
do
the
wrong
thing.
One
philosophy
of
a
monorepo
that
makes
life
a
lot
simpler
is
a
single
version
policy,
and
so
what
this
is
is
inside
of
repository.
A
All
of
your
first
party
code
depends
on
source
of
the
other
code,
but
you
also
agree
on
third-party
versions
of
code
that
everyone
in
the
repository
will
standardize
on
and
that
does
it
takes
some
work
to
say:
okay,
we're
going
to
be
on
the
same
version
of
bootstrap
or
the
same
version
of
low
dash
or
whatever
date
functions,
moment.js,
whatever
libraries
you're
using
to
do
that
and
it's
upgraded.
It
does
take
some
coordination,
but
you're
you're,
taking
your
you're,
basically
paying
upfront
for
something
you
would
have
deferred
the
payment
for
and
paid
interest
on.
A
If
you
were
doing
it
in
a
more
distributed
environment
where
you
had
several
repositories,
we
had
to
update
this
in
many
places,
wait
to
integrate
your
shared
dependencies
later.
So
it's
so
it's
all
about
trade-offs
and
I
think
the
trade-offs
tend
to
air
in
favor
of
a
single
version
policy,
because
of
how
easy
it
makes
makes
it
to
collaborate
across
teams
and
guarantee
compatibility
about
everything
in
your
domain
and
let's
look
at
a
third
example
of
fixing
a
bug
in
a
shared
library
compared
with
a
pi
repo
and
a
mono
repo.
A
So
let's
say
we
somebody's
reported
a
bug
in
our
home
page
and
we
figured
out
the
bug
lies
in
our
common
component
library.
So
the
workflow
would
look
something
like
this
in
a
poly
repo.
I
write
some
kind
of
test
to
confirm
the
bug
I
fix
it
test
pass,
merge
it
tag
it
a
week
later,
someone
in
the
homepage
app
sees
that
I
bump
to
the
version
and
they
they
update
it
and
the
tests
fail
like
they.
A
We
write
our
own
integration
tests
and
see
that
they
didn't
actually
fix
the
test,
and
so
this
is
because
the
test
could
pass
locally
without
actually
verifying
it
in
in
the
integration
in
the
app
itself,
because
we
don't
live
in
the
same
repository
and
it's
kind
of
cumbersome
to
for
me
as
someone
who
works
on
the
common
ui
to
to
set
up
to
be
able
to
test
within
the
app.
If
I
don't
know
that
repository
well
so
by
the
time
the
app
has
realized
that
they
didn't
actually
fix
it.
A
It's
already
been
tagged,
released
the
developers
probably
gone
home
for
the
weekend
and
they've
forgotten
all
about
the
change.
They've
lost
all
the
context.
It
requires
a
lot
more
work
for
them
to
fix
the
issue
then
than
it
would
have
if
they
would
have
caught
it
or
early
on.
So
if
we
look
at
the
same
scenario
but
in
the
but
both
projects
exist
in
the
same
repository,
we
have
a
flatter
workflow
like
this.
The
the
homepage
test
creates
its
own
integration
test
in
in
its
project.
A
The
the
common
component
maintainer
will
create
their
own
intent
test
to
verify
the
behavior.
They
see
the
test
fail
right
away
before
they.
They
don't
even
need
to
update
the
pr
they
can
run.
The
test,
see
that
the
the
regression
test
fails.
They
fix
it
immediately
test
pass,
they
merge
it,
no
publishing
required.