►
From YouTube: Nrwl NX - Zenande Godongwana
Description
Nx is a set of extensible dev tools for monorepos, which helps you develop like Google, Facebook, and Microsoft.
It will allow you to develop multiple apps both frontend and backend which reside on the same repo and can share the same library code, the same assets, and the same models.
It works well for large apps with large teams for effectively managing their shared dependancies, complete with a visual display for your depenancy graphs.
Nx will even go further to recompile and re-run the tests for app the apps the are affect by a change in dependancy, making working in a large team more efficient and less prone to errors.
This talk was recorded at the Jozi.JS meetup group on 19 September 2019.
https://www.meetup.com/Jozi-JS/events/263939320/
Disclaimer: The opinions in this talk are those of the individual and do not necessarily represent those of this channel, the meetup group, or its sponsors.
A
Right
so
preparing
for
your
next
energy
upgrade
guys
so
imagine
you're
a
new
developer
that
you've
just
joined
the
company
and
and
you're
a
new
developer
and
you're
not
yet
quite
familiar
with
the
system.
Yet
so
what
you
have
to
do,
the
first
thing
you
have
to
do
is
get
clone.
Obviously
the
project
that
you're
going
to
be
working
on.
But
what
happens
when
what
you
get
cloning
is
not
just
one
project,
but
it's
multiple
projects
spread
across
it,
spread
across
the
same
namespace.
It's
the
same
app
but
different
different.
A
We
have
different
repositories
for
each
of
the
components
of
the
app,
so
you
can
have
one
front-end
for
the
users,
one
front-end
for
the
admin,
one
back-end
for
for
four
simple
service,
and
you
have
you
have.
The
entire
structure
is
built
on
a
micro
service
based
architecture,
which
everyone
should
be
doing
right.
So
then,
when
you
get
there,
you
have
to
clone
all
right.
I
have
to
clone
my
first
front-end
all
right.
That's
awesome,
then
I
cloned,
my
second
front-end,
then
I
cloned,
my
third
front-end
and
I
have
no
idea.
A
What's
going
on,
then
I
told
my
back
end
and
then
it
complains
about
a
missing
complains
about
a
missing
back-end
and
it
did
I
need
to
run.
Then
I
need
to
clone
that
configure.
That
and
I
have
to
do
all
this
process
and
it's
such
a
huge
process
to
deal
with,
because
you
have
to
keep
track
of
each
and
every
repo
that
you
work
on,
which
brings
us
to
today's
talk,
which
is
going
to
help
us
manage
that
kind
of
separated
dependencies.
A
But
before
we
talk,
but
before
we
get
to
the
talk,
I
have
to
introduce
myself,
it's
customary
I
am
Iron
Man,
at
least
that's
what
I
want
to
be
and
I
am
that
developer
that
I
just
described
I?
Am
the
person
struggling
to
find
out
the
different
kind
of
apps?
That
are
that
that
we
were
that
we
are
working
on
in
our
company,
which
brings
us
to
now
Ln
X.
Now
an
X
helps
us
manage
mono
repo.
So
a
mono
repo
is
just
one
repo
where
you
store
your
entire
code.
A
For
example,
if
you,
if
you
have
a
team,
that's
working
on
a
web
app,
for
instance,
you
want
to
ensure
that
the
experience
feels
the
same
on
mobile
and
it
feels
the
same
as
well
on
on
a
tablet
version
that
way
we're
using
the
same
components.
That
way,
when
you
switch
from
your
web,
when
you,
when
you
switch
from
your
web
page
and
you
download
the
app,
the
experience
feels
the
same
when
you
are
on
mobile
or
when
you're
on
tablet
or
when
you
are
on
a
desktop
application.
A
So
let's
talk
about
the
project
structure
when
we're
going
to
deal
with
a
mono
repo
generally,
the
idea
of
a
monolith
means
that
you
have
one
app
and
it
has
a
bunch
of
dependencies
that
you
have
to
manage
a
modular.
A
modular
monolith
means
that
I
still
have
that
same
app,
but
now
I
can
swap
out
different
modules
about
different
libraries
and
interchange
them
with
other
other
modules.
A
A
So
what
we
want
to
talk
about
is
a
shared
library
as
a
separate
package
and
a
separate
repo,
which
is
what
usually
happens
yeah.
So
we
usually
have
the
third
module
as
a
dependency
of
each
of
the
two
apps
that
it
uses,
which
brings
us
to
NX
workspaces.
Now
in
NX,
workspaces
introduces
the
concept
of
a
mono
repo,
so
being
a
mono
repo
means
that
we
have
all
of
our
apps
on
one
repo,
all
of
our
libraries
on
one
repo
that
way.
A
So
some
of
the
pros
and
some
of
the
pros
of
using
a
mono
repo
would
be
having
unified
versioning.
So
I
know
that,
when
I'm
on,
when
I'm
in
my
version
of
the
app
I
know
that
everyone
is
on
the
same
release
on
the
same
version,
every
we
know
that
everything
when
a
particular
commits
will
work
right
so
nobody's
going
to
push
any
commits
that
I
pulled.
A
It's
easy
to
split
libraries
into
modules
that
I
can
reuse
over
again
and
it's
easier
to
manage
the
dependencies
across
the
different
apps,
because
it's
just
one
dependency
for
each
app.
So
this
app
has
this
dependency,
and
these
are
the
apps
that
are
using
set
particular
dependency.
There's
one
pull
setup
and
code
IDE.
Is
our
workspace
aware,
meaning
that
when
you
create
a
NX
workspace,
it
is
aware
that
it
is
an
NX
workspace
and
it
knows
how
to
handle
that
particular
workspace
and
there's
a
consistent
developer
experience
across
all
your
app.
A
Imagine
if
you
had
five
apps
in
your
company
and
it
feels
like
just
one
developer-
wrote
that
app.
That
would
be
amazing
what
a
night,
so
some
of
the
cons
of
using
a
mono
repo
would
be
upgrading.
It
would
be
when
you're
upgrading
a
library,
it
requires
a
change
on
all
the
apps
that
are
affected,
and
sometimes
you
may
not
have
permissions
to
a
particular
part
of
the
repo,
but
that's
about
all
the
Yukons
that
you
can
have
for
using
a
mono
repo
or
more
doesn't
matter.
A
A
So
if
we
talk
about
generators,
for
instance,
when
I
talk
about
generators,
I
mean
that
what
I
can
I
can
use
the
angular
CLI
to
generate
portions
of
map,
for
instance,
if
I
do
create
an
X
workspace,
it
creates
code
from
it
also
generates
code
for
me
where
it
separates
the
apps
and
the
libs
and
the
different
tools
that
I'm
going
to
be
using,
and
it
writes
out
all
the
writes
out
all
the
code
that
I'm
going
to
need.
A
set
up
and
then
when
I
and
I
do
an
ng
generate
my
app.
A
A
And
then,
when
you
do
like
an
NG
generate
UI
components
say
now:
you
have
two
apps,
you
have
my
app
and
you
have
new
app
and
you
want
to
use
this.
Your
this
new
UI
components
that
you're
doing
right.
What
what's
going
to
happen
is
now
this
new
UI
components:
module
is
going
to
be
shared
throughout
through
both
of
the
apps
that
you're
using
nice
and
neatly
down
on
the
nips
folder,
and
then
it
automatically
gets
imported
to
the
module
40s
file.
A
And
then,
if
you
want
to
create
a
if
you
want
to
create
a
normal
library
file
that
isn't
a
module,
so
instance,
you
want
to
create
an
interface
or
you
want
to
create
a
model
or
your
to
create
something
that
isn't
necessarily
linked
to
the
UI,
something
that
can
be
used
on.
Both
the
back
end
and
the
front
end,
you
can
just
use
the
generator
pretty
simply
to
to
create
the
the
the
library
itself
and
then
it
automatically
gets
added
on
the
TS
file.
A
So
what
we
mean
is
it
uses
the
angular
CLI
Wow,
so
NX
is
built
on
top
of
the
angular
CLI,
meaning
you
don't
have
to
download
a
new
CLI
for
n
X.
You
can
use
the
existing
angular
CLI
and
it's
going
to
manage
your
apps
for
you,
as
you
can
see,
for
instance,
now,
when
you
want
to
when
you
want
to
generate
a
new
components,
it's
the
same
generate
from
angular.
We
just
have
an
extra,
an
extra
argument
that
says
it's
on
app
UI
components.
A
So
when
I,
when
I
do
that
generates,
it
automatically
puts
the
button
on
UI
component,
meaning
now
that
button
I
can
use
it
on
both
of
my
apps
right
and
and
we
automatically
import
the
UI
components
module
on
the
app
that
modules.
Yes
well,
I
am
going
to
demo
some
of
this
at
the
end,
so
no
need
to
look
at
too
much
of
the
code.
A
A
So
when
you
download
the
the
NX
from
NPM
ins
using
NPM,
install
you're
going
to
come
with
a
default
linty
which
is
TS,
lint,
I,
think
and
when
you
have
TS
lint,
you
ensure
that
all
your
developers
are
writing
code
that
actually
works,
and
then
once
you
make
sure
that
your
should
it
developers
are
writing
correct
code.
You
can
get
a
code
formatter,
so
you
make
sure
that
your
shitty
developers
are
not
putting
space
are
not
putting
tabs
instead
of
spaces.
A
A
When
you
run
unit
tests,
it
knows
which
which
of
the
apps
are
being
affected,
and
it
just
runs
unit
tests
for
that
particular
app
instead
and
there's
obviously
more
that
I'm,
not
mentioning
that
I'm,
not
mentioning
that
NX
can
do
like
it
can
manage
dependence,
you
can
you
can
manage
all
your
dependency
injections
with
ng
rx.
It
can
simplify
fetching
of
data.
It
can
help.
A
A
A
All
right
so
here
I
have
an
example
project
where
I
have
two
apps,
namely
the
products
app
and
the
cart
app.
One
of
the
apps
is
written
in
Java.
One
of
the
apps
is
written
in
angular
and
the
other
app
is
written
in
react,
as
you
can
see
right
over
here,
so
react
app
and
the
other
app
is
written
in
an
angular.
A
As
you
can
see
over
here
now,
what's
great
about
this,
is
that
we
can
define
components
on
our
on
our
lips
folder
and
we
can
use
them
across
our
two
apps,
even
though
they
are
separate
frameworks.
So
even
though
I
have
a
react
framework,
and
even
though
I
have
a
angular
framework
when
I
come
here
to
my
labs
and
I,
look
at
shed,
for
instance,
for
my
let's
take
Styles,
for
instance,
I
know
that
my
Styles
are
now
shared
in
both
of
my
glow.
A
A
A
It
has
a
dependency
on
the
cards
page
up
and
also
a
dependency
on
some
of
the
shared
assets
like
if
I
trace
the
dependency
here,
and
if
I
am
going
to
look
at
this
shared
header,
it
just
means
that
only
my
cart
option
uses
this
header
and
it
doesn't
neccessarily.
It's
not
necessarily
shared
with
it's,
not
necessarily
shared
with
my
products.
Page
my
products,
app
sorry,
I'm,
gonna,
look
at
my
shed
assets.
I
can
see
that
on
my
app
yeah.
Sorry,
are
you
talking
about
the
shed
header.
A
A
You
can
you
can
toggle
the
apps
that
you
want
to
see.
You
can
toggle
the
apps
that
you
want
to
see
because,
usually,
when
you
have
a
lot
of
apps,
then
the
dependency
graph
can
actually
get
really
messed
up.
So
you
can
yeah
you
pretty
much
you
pretty
much
can
and
when
you
want
to
build
it
comes
with
it
cut
it
comes.
It
literally
comes
so
you
don't
have
to
type
on
your
terminal
anymore.
It
just
knows
the
correct
I
just
knows
the
correct.
A
A
We
can
just
see
that
it's
it's
just
a
it's
just
a
normal
element
30s
far,
and
we
have
all
of
our
code
for
the
header
there
and
we
have
all
of
our
CSS
for
the
header,
and
we
can
definitely
assure
you
that
if
we,
if
I,
come
here
and
look
at
my
products
and
I,
look
at
my
homepage
just
open
my
home
page
I
use
sorry,
not
this
one.
I
use.